SAPA Paradigm for IT Architecture

This blog is intended to give a basic introduction to the SAPA paradigm. SAPA is a new approach to designing, building, and delivering IT systems.

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.

This common SAPA pattern has a number of implications that cut across stages. First, there must be some way to compare two solutions to see which is the simplest. Second, there must be a  methodology you can use to test a solution to see if it can be simplified. And both of these imply that there must be some rational way of measuring complexity.

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.