Saturday, September 1, 2012

Snowman Architecture Part One: Overview


This is the first of a three part blog. The parts will be laid out as follows:
  • Part One: Snowman Overview. The basics of the Snowman Architecture and why I claim it is critical for enterprise architects.
  • Part Two: Snowman Benefits. Validation for the claimed benefits of the Snowman Architecture over traditional architectural approaches.
  • Part Three: Snowman Apologetics. The arguments against the Snowman Architecture and why they are wrong.
As Enterprise Architects, there is no lack of problems deserving of our attention. We need to ensure our organizations are well positioned for the Cloud, can survive disasters, and have IT systems that can chassé in perfect time with the business. 

And then there is the whole area of IT failures. Too many of our systems go over budget, are delivered late, and end up depressing rather than supporting the business. If you have been reading any of my work, you know all about this.

But what if there was one approach to architecture that could meet most of our needs and solve the lion's share of our problems? I believe there is. I believe there is a single architectural style that is so important, I consider it a fundamental enterprise architectural pattern. I call this the Snowman Architecture.

In my last blog, I talked about Radical IT Transformation, a transformation that redefines the relationship between the business and IT. The Snowman Architecture is the IT side of this radical transformation.


If Snowman Architecture sounds too informal to you, feel free to refer to it by its formal name: Vertically Aligned Synergistically Partitioned (VASP) Architecture. Figure 1 shows the four main segments of a VASP architecture.

Figure 1. Basic Vertically Aligned Synergistically Partitioned (VASP) Architecture

With a little imagination (or with the help of Figure 2) you can see why I refer to a VASP architecture as a Snowman Architecture. 

Figure 2. Snowman Architecture

Now your first reaction to the Snowman Architecture is probably, "Hey, that looks just like a services-oriented architecture (SOA)." A typical SOA is shown in Figure 3. And you can see that all of the components of the Snowman Architecture also appear in an SOA.

Figure 3. Typical SOA

Snowman: SOA with Constraints

The best way to think of the Snowman Architecture is that it is an SOA with some very tight constraints. It is these constrains that are critical to addressing all of the issues I mentioned earlier, so let's go through them.

Constraint 1: Vertical Alignment.

The contours of the business architecture (Snowman head) define the contours of the technical, services, and data architecture.  

In other words, there is a close relationship between the business, technical, services, and data architectures. Let's take these one by one.

At the technical level, there is package of technical systems (Snowman torso) that implements the package of business systems (Snowman head.) The technical package is complete with respect to the business package, that is, it fully implements the business package and doesn't implement anything other than the business package.

This vertical alignment is respected down to the data level (Snowman bottom.) In other words, there is a package of data that meets the needs of the package of technical systems (Snowman torso). This package of data fully meets the needs of the business package and doesn't meet the needs of any other package.

At the Service level, each messaging relationship supported at the services level implements one dependency at the business level. Further, all messaging relationships can be traced back to a business level dependency.

Constraint 2. Synergistic Partitioning.

The functions in the business package (Snowman head) are synergistic with respect to each other. 

Since the contours of the business package (Snowman head) define the contours of the lower level packages, it is important that the "right" functions be  located together. The overall choice of which business functions should co-habitat with which others should be directed to minimizing the overall system complexity. Elsewhere1 I have shown that the least complex overall system is attained when the choice as to co-habitation is based on the mathematical concept that I call synergy

While the concept of synergy has a precise mathematical definition, it also has a pragmatic definition. For those who don't care about the mathematics, just think of synergy is "closely related." That is, two functions are synergistic if they are closely related to each other, like deposit and withdraw. For those who do care about mathematics, see my White Paper1.

Given these two constrains, you can see why I call this a Vertically Aligned Synergistically Partitioned Architecture. And given the complexity of that description, you can see why I prefer the term Snowman Architecture.


I use the term capability to refer to the closely related packages of business, technical, service, and data architecture. This is somewhat similar to the way the term capability is used in various enterprise architecture methodologies, although most don't include anything other than the business architecture in the notion of capability. So if I am being precise, I will refer to one related grouping of the four package types as a capability. When I am being informal, I will refer to that same  grouping as a  Snowman. So I might say the Checking-Account capability or the Checking-Account Snowman. Either of these would mean the business processes that deal with checking accounts, the technical systems that support those processes, the data that feeds those technical systems, and the services that provides interoperability with the outside world.

When I want to be clear that I am talking about my understanding of a capability rather than somebody else's, I will use the term autonomous business capability (ABC) . The word autonomous reflects the synergistic assignment of business functions and the word business refers to the central role of the business layer in defining the overall capability structure.

When I am discussing the business architecture of the ABC, I will refer to the business level of the ABCSimilarly I will use the terms technical, services, and data level to refer to those respective architectures. 

So the business level of the ABC contains some collection of business functions that are synergistic with respect to each other. The technical level of the ABC provides the technical support needed by those functions. The data level of the ABC provides the data that fuels the technical level. And the services level of the ABC implements dependencies between ABCs.

Relating this back to the Snowman Architecture, the business level of the ABC is the head, the technical level of the ABC is the torso, the data level of the ABC is the bottom, and the service level of the ABC is the arms. 

Scaling Up

Since the Snowman architecture is a subset of an SOA, creating larger and larger systems is easy. We just add more Snowmen (or ABCs, if you prefer) into the mix and make sure they are connected through messages as shown in Figure 4.

Figure 4. Scaling Up the Snowman Architecture


Let's go back to my original claim, that the Snowman architecture solves many of the problems that plague the enterprise architect. Now I should inject a caution here. I consider the problem space of the enterprise architect the delivery of large (say, greater than $1M) systems2. If all we are building are small systems, then many of these claims don't apply. For that matter, there should be no need for an enterprise architect. 

Given this caveat, I make the following claims about the Snowman architecture in comparison to a traditional SOA or any traditional architectural approach:
  1. The Snowman architecture is cheaper to build.
  2. The Snowman architecture is more likely to be delivered on time.
  3. The Snowman architecture is more likely to satisfy the business when delivered.
  4. The Snowman architecture is easier to adapt to the changing needs of the business.
  5. The Snowman architecture is more amenable to Agile Development.
  6. The Snowman architecture is easier to debug.
  7. The Snowman architecture is more secure.
  8. The Snowman architecture is more resilient to failure.
  9. The Snowman architecture is easier to recover when system failure occurs.
  10. The Snowman architecture makes more efficient use of the Cloud.
There are a number of other benefits I could claim, but this should be sufficient to make the point. And I think it is fairly obvious that if all of my claims are true, it will be a compelling argument in favor of the Snowman Architecture.

In Part Two of this blog, I will validate each of these claims. Then in Part Three, I will discuss all of the arguments against the Snowman Architecture and show why they are wrong.

If you would like to be notified when the next installments are ready, you have two choices. If you just want to know about new blog posts, you can use the email signup on the right. If you would also like to know about my white papers, webshorts, and seminars, then use the ObjectWatch sign-up system at

Either way, stay tuned!

Workshop Announcement: 
Radical IT Transformation with Roger Sessions and Sarah Runge
For my New Zealand and Australia followers, I will soon be doing a workshop with Sarah Runge, author of Stop Blaming the Software. We will be spending two days discussing our work in Radical IT Transformation, a better way to do IT.
Auckland: October 11-12 2012
Sydney: October 15-16 2012
Cairns: October 18-19 2012

Check out our Agenda or Register!


[1] See for example my paper, The Mathematics of IT Simplification at

[2] In passing, I also note that I consider the problem space of the Enterprise Architect the delivery of the maximum possible return on IT investment. Many enterprise architects disagree with this job description. See for example the extensive discussion in LinkedIn on the subject of What is EA?


The two Snowmen pictures are by (in order of appearance) jcarwash31 and chris.corwin on Flickr, both are licensed under Creative Commons.

A Note on Comments

I welcome your questions/comments on this blog and I will try to respond quickly. A word of caution: I am not interested in comments along the lines of "This is not EA, this is EA-IT" or "EA is not concerned with delivering more value from IT." If you would like to have that conversation, I suggest you contribute to one of the discussions on LinkedIn, such as What is EA? Comments here are reserved for the topic at hand, discussing the Snowman Architecture, its claims, and the arguments against it. Thank you!