Blog

David Linthicum may very well have coined the term “SOA Rage” in his recent posting. His posting had to do with resistance to change that can easily occur with SOA efforts. David says that, “I guess there is a certain amount of rage that’s going to be a part of any change; it’s your job to minimize it.” My issue is that David and others posting on the same topic do not provide any substantive suggestions on how to identify and minimize potential change issues. There are ways to do that. Take a look at Chapters 8 and 9 in Web Services and Service-Oriented Architectures: The Savvy Manager’s Guide. You will find a discussion on how force-field diagrams could help you identify and minimize resistance to change. By the way, I wrote those chapters in 2002. To my knowledge, no other SOA-related book discusses change to the degree I do in that book.

Establishing the design context is very important. The context determines what is in and what is external to the system being designed. I think the technique you use to determine context is irrelevant. It just needs to be a technique (and diagrams) that everyone involved in the design can understand.

What I like to do is assemble a group of people with domain knowledge (users, mangers, technical folks, etc.) in a room. I then draw a single large circle in the center of a whiteboard and ask people to tell me what is in the system (inside the circle) and what is outside the system. I use words, stick-figures, boxes, or whatever makes sense at the time and place them either inside the circle or outside the circle.

Having a group of people do this is helpful because they often disagree as to what is inside or outside a system. The challenge is to facilitate the group towards agreement.  It is important to work through these issues at the outset of a design rather than find you have disagreements later in the design process.

Once the group has an initial idea as to what is in the system being designed, I then ask what flows (you can use a different verb if you prefer) into the system from a given external entity and what flows out of the system to a given external entity. I draw arrows between the edge of the large circle and the external entities with a label for the flow. (Note that no arrows are drawn inside the large circle.) Often, adding flows will make people readjust what is in the system. I believe it makes them think more deeply about design issues.

I then use the in/out flows as the inputs and outputs for the Decomposition Matrix that is available on this site. Note, that at this point, no arrows are used for anything inside the circle. That will be determined by the Decomposition Matrix. The matrix requires that the group go one step further with the inputs and outputs. They need to indicate which inputs and outputs relate to each other. That often uncovers more inputs or outputs. It can also result in a better delineation of inputs or outputs, resulting in the separation or combining of some inputs and outputs. This process sometimes makes people once again adjust what is inside the system and what is outside the system.

Next we generate a diagram based on the Decomposition Matrix. This diagram is the first-level decomposition of the design context. The first diagram generated often does not make sense when the group reviews it. Usually the problem can be traced to either missing inputs or outputs — or missing relationships between existing inputs and outputs. So, further changes are made to the design context and/or the Decomposition Matrix.

By the time the group agrees on the Decomposition Matrix, a first version of the design context is clearly established. Why do I describe it as a “first version?” Some reasons:

1. People will “sleep on” this exercise and suggest improvements the next day.
2. A critical team member could not make the initial meeting and has useful suggestions.
3. Someone reviews the generated diagrams based on the Decomposition Matrix and finds something that does not make sense.

Ideally, I like to reconvene the group the next morning to see if there are any further changes to the design context. If so, we continue with this iterative process. With each iteration, the design context becomes better and the diagrams generated from the Decomposition Matrix become more useful.

More on using the Decomposition Matrix this can be found in the Wiki on this site.

This site is an experiment in two ways. First, it is an attempt to advance the quality of software design decomposition by providing a free tool to help designers work through the decomposition process. Second, it is an effort to build a community to help advance the understanding of software design decomposition. Because it is an experiment, I expect this site to be a continual work-in-progress.