SAPA stands for Simple As Possible Architecture. The driving idea behind the SAPA paradigm is that simplicity reigns supreme. Complexity is the enemy. It drives systems cost, increases system failures, and greatly adds to the lifetime cost of an IT system.
There are a number of stages to building a SAPA. I think of the stages as follows:
Stage 1: Capability Mapping. Here we are trying to understand how the high level business processes that will be supported by the IT system are broken down into simplest possible set of capabilities (groups of business functionality.)
Stage 2: Business Architecture. Here we are taking one of the capabilities identified in Stage 1 and specifying the the simplest possible implementation of that capability in terms of business processes and dependencies.
Stage 3: IT Organization. Here we are identifying the simplest possible collection of IT systems necessary to support the business architecture identified in Stage 2 and documenting the dependencies between those systems.
Stage 4: IT Architecture. Here we are designing the simplest possible architecture for each of the IT systems identified in Stage 3.
Stage 5: IT Implementation. Here we are implementing the IT system as simply as possible following the architecture created in Stage 4.
Each of these stages follows the basic SAPA pattern:
- Understand the immediate problem you are tying to solve
- Design the simplest possible solution to that problem.
- Validate that there is no simpler solution.
My recent work in the SAPA paradigm has focused at stages 1-3. For a good example of my work in these three stages, see my "anti-complexity patent." You can read about it here.
SAPA builds on the paradigms that come before it, especially Service-Oriented Architecture (SOA). But while SOAs are a natural way to realize a SAPA (stages 4-5) SOAs are in no way required for SAPA.
SAPA is a key enabler for many desirable features of IT systems. SAPA systems are easier to test, implement, and make secure. They perform better and are more reliable. They are cheaper to build and easier to maintain.
SAPA has something for everybody. For those interested in business/IT alignment, SAPA systems are highly aligned with the business processes they support. For those interested in cloud deployment, SAPA systems are well designed for life in the cloud. For those interested in Agile development, SAPA systems are a necessary prerequisite to effectively scaling up Agile approaches.
If you care about improving the organization's bottom line through more effective IT investments, you should care about SAPA. The reason is simple. As Simple As Possible!
................................................
Would you like to keep up to date with Roger's blogs, white papers, newsletters, books, conference appearances, and webinars on SAPA and Complexity? Subscribe to the ObjectWatch alerts. Instructions here.
2 comments:
Heartily endorse your perspective to drive to simplest possible solution (have your book). I run into a glitch on my current project, though, at addressing your first point: "understand the immediate problem you are trying to solve".
What if the customers just can't converge on what problem they are trying to solve?
I am struggling with a model I have successfully subscribed to for years: either give me a specific user with a bounded problem, or give me a vision and some constraints. Either one I can work with --- because if we define the problem right, we can choose between multiple solutions.
This time, the vision is too fuzzy, the problems too many, the goals of the organization too unsettled; and there is little experience with leadership outside of rushing into the breach to solve some technical glitch (I'm in engineer-land, if you hadn't guessed.)
Scarily, the new steering committee chair sees us spending more money on pilots and demos than on requirements.
The stakeholder leadership would probably agree with the following:
+ Simpler designs are better (robust, cheaper, faster to do)
+ The clearer and more focused the goal (e.g., uses and context), the simpler the design can be
+ A clear goal requires making choices about what without knowing how
But they are completely unwilling to consider goals framed as value propostions; their discomfort seems to be based on them not knowing how to achieve it.
Yet, they would not expect to know all the "hows" of doing their complex products.
So.... any ideas for communicating the value of having clarity at the conceptual level, so one can then figure out how to do it most simply?
Lisa,
It is a great question!
Communication and achieving common vision can be hampered by a number of issues.
There may be political issues. For example, a particular business function may have high status and everybody wants to own and guide that business function.
There may be trust issues. For example, in many organizations IT and business stakeholders have a history of blaming each other for past failures.
But whatever other factors may be contributing to the rancor (if that isn't too strong a word to describe what you are experiencing), complexity is almost certainly exasperating the problem.
So the best way to overcome these problems and drive consensus is to first of all get everybody focused on their common enemy: complexity. People need to understand why complexity is bad and how working together under the guidance of the SIP approach can help.
Once people have this common understanding, it is time to start the first stage discussed above, that is, defining the capabilities that will effectively partition up the project into subprojects.
The key is that this step can be accomplished before you have fully agreed on the problem being solved. Capability partitioning is not a matter of solving the problem, it is a matter of figuring out the best way to partition the problem into smaller problems.
You are likely to run into issues in the partitioning process. Say, for example, the business function Pay-Claim is considered high prestige. You may have numerous groups arguing as to why its functionality should be part of their capability.
This is where synergy analysis comes in. We never decide on which business functions are assigned to which capabilities based on what you think or what I think. We base this decision on the "mathematical" results of synergistic analysis. So instead of various groups competing for ownership of business functions, we have various groups working together to try to feed the right information into the synergistic algorithm.
It can be quite amazing to see the change this has on people. They typically move from confrontation ("That function belongs to us!") to collaboration ("Where does synergistic analysis place the function?")
Once you have the capabilities established, then you can start working on common vision, goals, and, eventually, specifications. This will be much easier because you have not only partitioned the business functions into capabilities, you have partitioned the stakeholders into capabilities.
So now instead of everybody trying to agree on everything, you have small groups trying to agree on very specific business processes.
So in summary, don't try to reach too much understanding too soon. Focus first of all on reducing complexity, which means using SIP to break down the problem into smaller problems, each of which is as simple as possible and has as few dependencies on others as possible.
In other words, divide, then conquer. Don't try to conquer, then divide!
Good luck! Let me know how it works.
Post a Comment