Processes that cannot be decomposed or factored further are used to construct composite services of appropriate granularity. How many times have you read a statement like that related to the design of a service-oriented architecture? How many times have you been given a rigorous definition of atomicity – that condition where processes cannot be decomposed further? My guess is your answer to the first question is something along the lines of "too many times to count" and your answer to the last question might very well be "rarely or not at all." This column will provide a rigorous definition of atomicity and a way to determine the correct granularity of services based on atomic processes.
Here's a rigorous definition of atomicity: Software atomicity occurs when each input to a process is used to create one or more outputs from the process. This definition, based in mathematics, has been around a long time. One way to use this definition is to construct a matrix with inputs as rows, outputs as columns, and then mark the inputs used by each output. An atomic process will have all cells of the matrix marked.
Although a matrix is an easy, back of the envelope, way to determine atomicity, you can end up fooling yourself using this approach. It is easy to rationalize marking all the cells of the matrix after you have completed what you think is the correct decomposition. So, even if using a matrix for atomicity provides a rigorous definition, it has a practical or psychological flaw that limits its usefulness.
In the 1980s, Mike Adler, a colleague of mine, addressed this flaw by inverting the use of the matrix. Mike used the matrix to create the decomposition instead of using it to check the decomposition. In order to create the decomposition, Mike developed a specialized algebra that acts on the matrix.
In recent years, I have revisited Mike's research as it has become increasingly obvious that people are struggling with less rigorous definitions of atomicity – and even more difficulty with common definitions of granularity. Mike's decomposition algebra, however, is a bit obtuse and difficult to use with pencil and paper. So, I decided to program his algebra – with some enhancements – and you can use it for free at Design Decomposition. At that website, you can complete a matrix that will then generate either business process or data flow diagrams. The latter is used to represent services in an SOA.
I've found several accidental benefits that are derived by starting with the matrix rather than a diagram. First, it allows another way for non-technical people to get in on design process. This appears to be particularly true for business process diagrams. People who understand their jobs can usually decide if a matrix cell should be marked based on whether or not a given input occurs before or concurrently with a given output. They do not need to be able to read, for example, BPMN diagrams. Such diagrams can be challenging for some people. Second, for folks in IT, it is a way to manage understanding complexity because you need to make only one binary decision at a time: does a given input affect a given output in a single cell of the matrix. Finally, sometimes people are surprised by the suggested decomposition. I've come to think we, as designers, tend to repeat what has worked for us before and can sometimes be blind to an alternate decomposition.
So, to get back to the definitions, I'm going to use the following figure that was generated from a matrix using the decomposition algebra. [CLICK TO ENLARGE] You can see the matrix and other details at Design Decomposition Blog. This is essentially a visual depiction of the definitions. All the processes in this figure are atomic. The decomposition algebra guarantees that.
To construct composite services from this figure, you need to determine which of the external flows are used by atomic tasks in your business process diagram (or its equivalent). For illustrative purposes, let's say the top layer of processes relate to different tasks in a business process diagram. Each of these becomes a service. The shared processes in the figure below the top layer would most likely be more efficiently implemented in some way other than as services. Nevertheless, at some later time, should a business task need to access a lower level process as a service, that process could then be factored out as a service. By following this pattern, services always have the appropriate granularity to go with the business process diagram.
This technique provides atomicity for a design and a visual way to determine the granularity of services. It should work with most methodologies since all it does is suggest a decomposition that a designer can choose whether or not to use. I am still tinkering with the decomposition algebra and its implementation, so I invite anyone who tries the website to give me feedback.
About the author
Douglas K. Barry is the Principal of Barry & Associates, Inc. He specializes in enterprise architecture with an emphasis in service-oriented architecture, database systems, and object technology.