Remembering the Future

The trick is to design services so that they can be actors in a wide variety of groupings (business processes).

This is tough. It requires a lot of experience and the ready availability of serious domain knowledge.

Good service boundaries do not "drop" out of decomposing discrete IT systems. They drop out of decomposing the "social network" that underlies a family of business processes. Decomposing the social network is mostly an empirical science:

• You need to put in probes and monitor traffic flows as they are, not as some ex-post facto Visio diagram claims they are and not as users (each of whom have their own complexity-reducing simplified mental models) tell you they are


• You need to hunt for simple repeating patterns in the apparent chaos of cross talk. I find it useful to do this anthropomorphically in terms of speech acts


• You need to find the feedback loops. They exist in any complex system and are the key to unlocking any underlying simplicities that are key to tractable implementation


• You need to find the key "nodes" in the power law distribution that governs (trust me) the connect-ness of the services network. In fact, I'd go so far as to say that if you do not get a power law distribution staring back at you from your analysis, repeat the analysis.


• Finally, you need to be lucky. The more detailed your emperical analysis is, the luckier you will be with your final services decomposition :-)

Topics: SOA | Architecture | Design