Showing posts with label SOMF. Show all posts
Showing posts with label SOMF. Show all posts

Monday, February 09, 2009

Hypothetical Business Models

Robin Meehan (Smart421) asks a question about modelling time sequence dependencies in EA modelling tools

"I often want to model ‘what if’ scenarios, i.e. what the various architecture domains would look like if we proceeded with Option A, or B etc ... [but] I don’t want my various different options to ‘bleed’ into each other in the model. ... The only way I’ve found round this in the past is to duplicate parts of my model to keep them separate (in different packages etc) - which is a bit ugly."

Of course, the problem Robin identifies is more than just time sequence dependencies. Sometimes we have to explore the differences between A-followed-by-B and B-followed-by-A, but there may be many other permutations to explore. If you have to duplicate parts of the model for each permutation, this severely limits the number of permutations you can compare.

Many architects will try to solve this kind of problem by abstraction - coming up with a model that abstracts away from the differences between the options, so that the model supports all the possible options and all the possible permutations between the options. However, the standard model isn't then much good for comparing the options. In some cases it may be worth building a flexible capability that can support both A and B, but how do I tell whether this is one of those cases?

(Michael Bell's SOMF modelling approach does allow AS-IS and TO-BE to be shown on a single diagram, but I don't know how practical it is to put multiple alternatives on a single diagram.)

What Robin highlights here is that the standard modelling tools and notations aren't always very helpful at supporting choice, especially when the choices get at all complex. Often it seems that the tools only really work for documenting the architectural and design choices that have already been made, rather than for making the choices in the first place.

The best answer I can give Robin is to use the available tools, but to adopt a different modelling style. But I need a good case study to work on. Contributions welcome ...

Sunday, January 25, 2009

SOA and Holism

Wikipedia's definition of holism traces back to Jan Smuts
Holism ... is the idea that all the properties of a given system (biological, chemical, social, economic, mental, linguistic, etc.) cannot be determined or explained by its component parts alone. Instead, the system as a whole determines in an important way how the parts behave.
To what extent does this concept apply to SOA? My own view is that SOA needs to be understood from the Systems-of-Systems Engineering paradigm rather than from the Systems Engineering or Software Engineering paradigm. This helps us to deal with a range of system level phenomena including Feature Interaction.

In my writings I've drawn on the recent work of Christopher Alexander, from A New Theory of Urban Design to The Nature of Order, where Alexander talks about something he calls structure-preserving transformations.

According to the New Theory (or at least my interpretation of it, which I call Organic Planning) each act of transformation should be a step within a larger and open-ended evolutionary development, and should have three aspects.

  1. Produce something at some level
  2. Complete something (larger) that was already part-developed - typically by linking smaller (lower-level) things and peer (same-level) things that already existed, or were created in previous steps.
  3. Create new opportunities - Alexander calls this hinting-at.
For example, an information service called Product Catalogue might (1) establish a single point for accessing product information, (2) linking together data from multiple legacy data stores and third-party feeds, while (3) hinting towards a new business process (yet to be fully specified) in which the product catalogue becomes a dynamic object, using some kind of real-time business intelligence.

I published a very simplified version of this in the CBDI Journal in 2004, suggesting that the service designer needed to look in four directions (upwards, downwards, sideways, inwards). I understand that this was picked up and referenced by the ArchiMate people, for example in a 2005 book called Enterprise Architecture at Work, and it has been implemented in the Telelogic tool. My colleague Tony Bidgood has recently published an article on ArchiMate, with some further examples.

Here's how I intended the four directions to map to the New Theory of Organic Planning

1. Inwards: Functional correctness
2a. Downwards: Integrating and composing smaller stuff
2b. Sideways: Interoperability
3. Upwards: Larger whole

Organic Planning is described in my 2001 book on the Component-Based Business, and there is a short version on my website, but I didn't make this explicit in my 2004 article.

My expectation has always been that a series of transformations (whether structure-preserving or otherwise) would be expressed as a series of model pairs, in which the nth TO-BE becomes the (n+1)th AS-IS. But some alternative modelling notations (such as Michael Bell's SOMF) allow both AS-IS and TO-BE to be expressed in a single model, so it would be very interesting to see how a series of transformations could be expressed and analyzed.



 
 See also SOA and Holism 2 (February 2009)

Wednesday, January 30, 2008

SOMF

An article has just appeared on Wikipedia advertising something called The Service-Oriented Modelling Framework, based on a new book by one Michael Bell. Advertisements are usually excised from Wikipedia fairly speedily, so the article may not last long.

According to the article, Bell has invented a modelling process and language for SOA that is both anthropomorphic and holistic. If this is true, it is a remarkable achievement. Most modelling languages are materialist and reductionist - they describe certain aspects of the system-of-interest by reducing them to objects. Whereas an anthropomorphic model would ascribe human characteristics (e.g. personalities and desires) to the system-of-interest.

I guess I need to read the book when it comes out. Perhaps the publishers would care to send me a review copy?