SIP and TOGAF: A Natural Partnership

If you have ever heard me talk, you know the standard three-tier architecture is a bad approach for large complex IT projects. It has poor security. It is difficult to modify. It is highly likely to fail.

Instead, I recommend the Snowman Architecture. This architecture is great for large complex IT projects. It has excellent security. It is easy to modify. And it is highly likely to be delivered on time, on budget, and with all of the functionality the business needs.

I often show pictures contrasting these two different architectures, such as this:

The classic three tier architecture is generated by standard IT methodologies, such as TOGAF¹. The Snowman Architecture is generated by the methodology known as SIP (Snowman Identification Process.)

From this discussion you might assume that traditional methodologies such as TOGAF are in conflict with SIP. But this is not the case. The ideal architecture comes not from SIP instead of TOGAF, but from an intimate dance between SIP and TOGAF².

To see how this dance works, let me take you through the steps needed to define a Snowman Architecture and point out where SIP takes the lead and where TOGAF takes the lead.

The starting point for a Snowman Architecture is identifying the business functions. These are the smallest granular functions that are still recognizable to the business analysts. SIP drives the identification of these business functions.

The second step is the partitioning of these business functions into closely related groupings. We call these groupings synergy groups. SIP includes very precise mathematically based algorithms for identifying these synergy groups and it is critical to the project that this partitioning be done correctly.

The third step is the definition of the strong vertical boundaries that will separate the snowmen from each other. This again is SIP functionality. And now SIP takes a break and TOGAF takes over.

To review, these first three SIP lead steps are shown here:

Next we gather the requirements for the business architecture. The business architecture is the head of the snowman. From the SIP analysis, we know which functions are in each head, but we don't know much about their requirements. TOGAF has good processes in place for requirements gathering.

The fifth step is defining the technical architecture. TOGAF has been doing this for years, so SIP has nothing to add here.

The sixth step is defining the data architecture. Again, TOGAF does a great job. We don't need SIP for this.

These three steps, then, are the heart of the TOGAF contributions and are shown here:

The final two steps (seven and eight) involve tying the Snowmen together. First we define the business dependencies between synergy groups. While TOGAF has some information about how to define business dependencies, the SIP defined synergy groups are critical here because they greatly reduce the number of dependencies that will need to be implemented.

Once the business dependencies have been identified, then we are back to TOGAF to translate these business dependencies into a service oriented architecture. These last two steps are shown here:

As you can see, SIP and TOGAF complement each other. SIP depends on TOGAF to fill in the SIP defined Snowman structure. TOGAF depends on SIP to scale up to projects larger than one million dollars. Put the two together and we have a highly effective solution to building large, complex IT systems. The best of all worlds.

Footnotes

(1) TOGAF stands for The Open Group Architectural Framework. It is a trademark of the OMG.

(2) While SIP works well with TOGAF, SIP is  agnostic about which methodology is used to drive the non-SIP parts of the analysis. If your  organization is using some other architectural methodology rather than TOGAF, you can replace TOGAF in these diagrams and discussions by your favorite methodology.