Dust Off Those Patterns Books

With the growing popularity of Event-Driven Architectures (EDA) and Complex Event Processing (CEP), patterns such as the blackboard and observer patterns will become important again (not that they ever really ceased being important).

The blackboard pattern is used in systems that deal with problems that don't have a deterministic approach to reaching a solution, mainly AI systems. The pattern consists of a common space (the blackboard) where data is posted to be shared. Independent knowledge agents listen for data of interest from other agents and post partial solutions to the blackboard for consumption by other agents. The data posted to the blackboard represent the current state of the system. Control agents monitor the state of processing and determine when a solution is sufficient and processing can stop. The blackboard pattern was made popular when it was described in Buschman et al's book on software architecture patterns. A lot of EDA's today are implemented using messaging systems. The blackboard pattern can be applied to such architectures--the messaging bus becomes the blackboard and the knowledge and control agents are publishers and subscribers to the bus.

The observer pattern is a very simple pattern that's often used in GUI applications as part of an MVC framework. The pattern consists of a subject that may emit events and observers that are interested in those events. The observers register themselves with the subject for events that they are interested in and when those events occur, the subject notifies the registered observers. The observer pattern is the basis from which EDA's are built. This pattern is documented and described in many places but most people probably learned or read about it from the Gang of Four's design patterns book.

EDA, CEP, design patterns

Business Process Patterns

In my work with various clients, I'm starting to take note of the common scenarios I'm seeing of how people are using SOA to improve their business processes. I'm sure others are starting to notice some recurring scenarios as well. By capturing these scenarios, we can develop a set of patterns that can be used to address them. What sets these apart from the other types of patterns we see in software such as design patterns or implementation patterns are that these are analysis patterns. Years ago, Martin Fowler wrote a book called Analysis Patterns which I still find to be a very useful book today. The patterns in that book however are finer-grained and more domain specific. What I am referring to are a broader set of analysis patterns that help you to analyze and decompose complex business processes which can be applied to any domain. The relevance to SOA of course is that business process analysis is one of the critical initial steps to any SOA initiative. Having such a set of common process analysis patterns will help to create a much more definitive SOA methodology which I think we are still lacking.

Here's one example of a recurring scenario that I see: Multiple Variant Processes to Perform a Common Function. In a large organization with multiple subsidiaries, there are often common functions that each of those subsidiaries perform but with their own slightly unique processes for doing so. For example, a lot of large organizations have subsidiaries that have their own unique processes for procurement. Often times the parent organization will want to integrate with the processes of the subsidiaries or it will want to integrate the subsidiaries’ processes together. So how do you go about analyzing all the subsidiaries’ processes to figure what/where to integrate? This can be pretty overwhelming if there are a lot of subsidiaries and the processes are complex.

An effective way to analyze the variant processes is to abstract a common process out of them. This is analogous to extracting a trend line from a scatter plot graph. In a scatter plot, trying to look at the individual points to understand and draw relationships out of the data is very difficult, thus, you generate a common trend line out of those points.

With process analysis, it is very easy to get caught up in all the details of the individual processes and lose sight of the relationships across the processes that are important for integration. Thus, you should abstract a common process out of the individual processes and use that common process to direct your analysis of the individual processes.


soa, patterns, bpm

Where are the Coads, Fowlers, Rumbaughs, Boochs, Jacobsons of the SOA world?

Back in the 90's when someone wanted to be a better OO developer, they would pick up some books from these fellows. With SOA being all the hype these days, developers need similar guidance on how to do good Service Oriented Analysis and Design (SOAD). As SOA is relatively immature (though some claim they’ve been doing it for years), there is less guidance and accepted principles on how to come up with good service models (analogous to object models in OO) such that they are loosely-coupled, reusable, agile, etc. Really, the only advice that people give today is to make services coarse-grained. In the SOA world, there is currently a lack of commonly-accepted structured methodologies that prescribe the proper approaches for coming up with good service models. IBM has started to do some work in this area but they themselves state this is just a beginning and there is much work that still needs to be done. Another interesting area to keep an eye on is the upcoming book by Lublinsky and Manolescu on SOA patterns.

SOA, object-oriented