Introduction
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.
Fundamentals
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.
Terminology
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 ABC. Similarly 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
Benefits
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:
- The Snowman architecture is cheaper to build.
- The Snowman architecture is more likely to be delivered on time.
- The Snowman architecture is more likely to satisfy the business when delivered.
- The Snowman architecture is easier to adapt to the changing needs of the business.
- The Snowman architecture is more amenable to Agile Development.
- The Snowman architecture is easier to debug.
- The Snowman architecture is more secure.
- The Snowman architecture is more resilient to failure.
- The Snowman architecture is easier to recover when system failure occurs.
- The Snowman architecture makes more efficient use of the Cloud.
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 http://www.objectwatch.com/subscriptions.html.
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!
------------------------------
Notes
[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?
Acknowledgements
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!
9 comments:
In real world scenario, very often there is data that lies somewhere in the 'gray area' whether which system or systems should have the ownership of it. Exchanging messages/data between the Snowmans might not be a simple case or efficient thing to manage as the amount of data and Snowmans increased. Can you highlight how to overcome the challenges of maintaining the complexity at a constant rate for data exchange/messaging between different 'Snowmans' as the amount of data and 'Snowman' increases?
Sze Siong Teo,
That is a great question. Dealing with the data partitioning is one of the biggest challenges in The Snowman Architecture. But there are a number of patterns that can help. The most obvious is "ask and you shall receive" in other words, send a message to an ABC asking for the data you want.
Another useful pattern is "subscribe and publish", that is, an ABC regularly publishes information that it thinks others might find interesting and those that want it subscribe to the publications.
Yet another is "central data heap", that is an ABC whose responsibility it is to maintain read-only copies of up-to-date enterprise data that can be easily queried.
With the Snowman Architecture, we do tend to end up with copies of data. But unlike the traditional relational "third normal form" we don't worry about having copies of data, we only worry about making sure those copies are kept consistent.
This seems to suffer from the same problem that SOA suffers from. You have data on the other side of the technology from the business, instead of being derived from the business. This suggests that the data architecture will be based on the technological architecture.
This is exactly the flaw that results in the issues raised above.
You can't have a message-based system if you haven't previously addressed what the messages contain. If the sender and receiver send a message but the meaning understood by the sender is different from the meaning understood by the recipient, things will "go south" quickly.
This means a model is required to decode the structure of the business data. This model will cross applications. It will not be based on technnology. Doing this precedes setting up the SOA architecture.
I Agree Dave.
TOGAF uses Business -> Information -> Technology.
I think it is the difference between the thinking model and the physical model.
You think in BIT architecture.
You work in BTI architecture.
Johan Theunissen
When you think, technology is a means to information, and information an means to business.
When you actually are working, the business must have acces to technology to acces the information. So the information is behind the technology.
Using pub-sub to address the data issue can be effective if the messaging model is canonical, and specifically if the canonical message model is aligned to the business' view of their information. (Typically the information model).
This leads to interesting side effects, but there are several canonical patterns to consider when adopting this model, Including Russian Doll, Venetian Blind and Salami Slice..
We are using a canonical message approach to solve this exact problem (as well as others). Its early days yet, but the so far the approach is holding up well. In our implementation, the only way data is allowed to move between "snowmen" (actually s/w fortresses structured very similarly to snowmen) is via the pub-sub system which enforces the use of canonical messages.
Dave, Nigel,
Given that the torso of the snowman (the technical architecture) is a projection of the head of the snowman (the business architecture), and that the arms of the snowman (messages) directly implement business dependencies, it is hard for me to see how there is a disconnect between the business and technical perspectives on the data.
As Nigel points out, this is very similar to the software fortress architecture that I proposed a number of years ago. I think of this as an update incorporating what I have learned about complexity since then.
Hi Roger.
Nice article (i've read part 2 also)
What you are describing, to my mind, however, is an extremely effective way to think about *solutions* architecture, and also a great paradigm for quick and effective M&A work.
As an *EA* methodology however, i'd want to know a lot more about how all these snowmen hold hands in the field where they are sat.
Presumably you'll address that in parts 3 and 4?
But it's a nice thought model to deal with a set of business capabilities and needs, and the data/information/application value chain which supports them...
Reading it, i must say, i started to laugh as i considered a mental picture of shared data sources and coupled capabilites being dually addressed by two snowmen, who now had to get... umm... intimate...
Especially as snowmen are known to be frigid:)
Have you looked at the Domain Driven Design by Eric Evans along with extensions like CQRS pattern promoted by Greg Young and Udi Dahan?
Hey I my friends I tell you something can you give me answer please Many of your business owner clients have a depth of knowledge and expertise in their own businesses but must rely on an integrated group of trusted advisors such as lawyers, accountants, financial advisors, insurance professionals, investment bankers and others. Many of your clients undoubtedly end up frustrated and angry at mounting legal and accounting expenses. What many business owners do not understand is that often the causes of seemingly out-of-control third party bills originate in their own shop and have to do with their own inadvertent mismanagement of external advisors.
architecture or business blogs
Post a Comment