When you think about it, a project in solution architecture is a nightmare waiting to happen. Your task is to build a working solution out of separate, often pre-existing components, integrating them along the way. You may have to work within environmental, contextual, and other constraints, and some of your methods and tools may be forced on you. In a typical information technology environment, most solutions rely on several existing applications, products, or services, each of which is owned by a different team and may have different roadmaps and release cadences. Building a workable solution in this environment requires a lot of juggling and negotiation.
This mixture of existing solutions is not limited to information technology. Solution architecture is rooted in the much older discipline of systems engineering. Systems engineers are responsible for all of the complex systems that exist today, anything that requires the skills and knowledge from multiple technical disciplines.
I first learned about systems engineering watching people design the high level structure of new missiles. A missile system is an interesting combination of tactical requirements, operability, reliability, delivery, cost, and most of all, weight and size. A typical missile consists of a surprisingly few subsystems: guidance, propulsion, weapons, and launch. All of these have to work together to create a unified whole, and they have to fit under the wing of an airplane and be delivered when and where needed without putting the crew in jeopardy. This is no easy task. A new commercial airliner is even more complex. Modern business solutions are getting more complex, too, but are nowhere near the level of an airliner.
Trouble is, we information technologists generally do a very poor job of engineering workable solutions. The successful integrated solution is a rare exception. Here, success takes the architect’s meaning: The solution delivers the benefits requested.
Over the past 30-odd years, I have seen and built a lot of integrated solutions. The one thing that stands out more than any other is that business problems, from a new application to a new missile, have a basic shape, and similar problems have a similar shape, to the point where we can begin to identify patterns. As a profession, we have focused on the patterns of solutions, not problems, so we do not yet have a catalog of named problem patterns. Such a catalog would be very useful.
A second, closely related observation is that the most frequent cause of solution failures, in terms of not delivering the business benefits, is a mismatch between the problem’s pattern and that of the solution. Put another way, we continually solve the wrong problem. This is the solution architecture equivalent of pounding a square peg into a round hole. I suspect this continual pattern mismatch is partly the result of not having a problem pattern catalog so we don’t recognize the type of problem we’re trying to solve. These problem patterns deserve to be studied more deeply, and will be the subject of future musings. Mostly, though, this problem-solution pattern mismatch is the result of a failure on the part of the architect, engineers, and the business sponsor to recognize the problem they are trying to solve.
One of my calculus teachers used to give 90% credit on a story problem if we managed to capture the right calculus equation. He said that if you don’t solve the right problem, you have no hope of success. So it is with solution architecture.
I will start our problem pattern catalog at the beginning. Three very basic patterns in software-based systems come from the fundamental purposes of the solutions. Business systems model information about things, hence the term information technology. A typical business application captures data about some set of business entities so that users can track the states of those entities as they travel through the business. In business systems, the primary source of complexity comes from the operational context, the source of nonfunctional requirements.
Scientific applications form the second pattern. Such systems are dominated by mathematical models of how things behave in the real world. That is, a scientific solution models the behavior of a real-world object, not information about its state. These systems form a different pattern because the primary source of complexity in the system comes from the mathematics, not the number of entities or transactions on those entities.
Real-time control systems form the third basic pattern. These systems perform real work and have to operate within the real world on the world’s terms. Complexity in such systems comes from the constraints in the world, mostly timing and concurrency.
In all cases, the problem to be solved determines the class into which the solution must fall. Within each of these classes there are more detailed patterns. Not all business problems are exactly alike, after all, and the same applies to scientific and real-time control problems. I have begun to catalog problem patterns, but only just.
Another development is driving solution architecture from a slightly different direction. Service oriented architecture (SOA) allows us to build loosely coupled collections of basic operations, data entities, and user interfaces that can be gathered and re-gathered through orchestration and choreography. We are no longer constrained to build huge, tightly integrated applications but I’m sure we will continue to do so until we figure out how to live without them; the transition is similar to the one we made between procedural and object-oriented development.
While SOA is not a silver bullet, it does free up solution architects by providing the operational context, tools, and many of the basic components to easily and quickly mash together workable solutions. In a mature SOA environment, nearly all of the data entities and basic services required to automate some business process step will likely already exist. What is required, then, is to decide which services need to operate on which data entities, in which order, to perform the required functionality. This concept deserves deeper study, too, and will also be the subject of future musings.
Scott Whitmire
Iasa Fellow