Archive for March, 2009

The Difference between Architecture and Design

My favorite analogy to describe the difference between architecture and design is to use the analogue of highway / street maps. I you were driving from New York to Los Angeles, you might approach mapping out your route the way we (should) approach architecture and design. At the most abstract level (the architecture), we understand that we have states, cities and within states, and interstate highways. To start, all we really need to know is which states we want to go through, and what interstates we want to take to optimize our time. This is an architectural approach. At this level of abstraction, all interstates can be treated much the same and while we know that the road systems within each city are different, that level of detail is not important (at this point in time).

Once we understand the basic path from NY to LA and approximately where we want to stop, we zoom-in to each specific area, focusing on its specific design and how to get from the Interstate to the points of interest, hotels, etc. and back again. Many cities even follow a similar pattern, where there is a “ring road” that encircles the city and interconnects to the highway system, but not all fit this pattern. Many small towns fit the pattern of having a “Main Street” that serves as its thoroughfare. Patterns help us understand the city / town road systems, as they give us a degree of familiarity, even in an unfamiliar place.

In this analogy, architecture and design are clearly related. Architecture is more abstract, focusing on the whole to gain perspective, and on the patterns that underlie similarities in the parts. Design focuses in on one or more parts and lets the broader picture “fade into the background”, so to speak.
This analogy works pretty well to distinguish the concepts of architecture and design as long as we recognize that the delineation is really just a “Point of View”. In other words, the fact that we have treated the city / town road systems as design elements is only really based on the fact that our scope in the example was the whole United States and we drew out patterns between cities and towns in different states.

If we reset our scope to a single city, for example we could just as easily talk about the “architecture” of the city’s road system, with more detailed elements being boroughs and districts within the city.

The important point to recognize is that architecture focuses on the whole to gain perspective, by abstracting away detail in order to draw higher level relationships. Architectural patterns capture “what is the same” about groups of elements within the architecture. Design, on the other hand is about the detail. In order to get the necessary detail, you zoom in, allowing elements beyond your “design scope” to fall outside “the field of view”. To put these in perspective with other design elements, we can think of “zooming-out” to the architecture level, moving to a different part of the map and “zooming back in” again.

At the risk of confusing rather than clarifying and to mix metaphors: Architecture is about the forest. Design is about the trees.


Communicating Architecture through Diagrams

If you are an enterprise (technical) architect, then you will have definitely come across the case where you have masterfully explained how your system is put together, and why, only to realize some time later how misunderstood you have been.

You could throw up your hands in disgust with boisterous outrage as to how stupid everybody is (except for you of course) and how you cannot possibly expect to get anything done in this environment!

Or you could get very introspective and try therapy (if you think it will help).

Or you can just accept the fact that almost every technology problem we face today is just plain complex, and the words we use to describe our brilliant and less-than-brilliant approaches are not precise to get the point across. And even if you do reach some the audience, the bulk of what you have said may not survive a night of sleep.

They say “a picture is worth a thousand words” and where technology architecture is concerned, the old adage is pretty much true. I have often sat in discussions where one technical person described in detail how a system worked, while the other nodded in agreement, both absolutely sure they knew what each other was talking about.

That is until I went up to the whiteboard and drew out my interpretation of what both said only to see head nods and head shakes, but at different times.

“People do not communicate”

The conclusion, I reached (as well as others) is that a good diagram is much more expressive and precise when it comes to expressing technology architecture and design than any words can be. When I looked around at what people were using to create diagrams, the number of styles, ideograms and metaphors used was astounding. The same person would even use different styles in different documents. While better than words, it was still not good enough.

Think about two people speaking to each other using words where they have not a priori agree the meanings. If this were the case, communication, while expressive, would be fraught with imprecision and misinterpretation (kind of what happens now in I.T.)

Luckily, there are a few diagramming styles that are fairly widely used, fairly well defined, extensible and flexible. One of these is the UML (Unified Modeling Language). The specification (in multiple parts) is managed by the OMG (The Object Management Group). UML, while very, very useful is actually targeted primarily for the process of systems design rather than architecture and as such tends towards more detail. To use UML in the architecture process, we amust bstract away certain details in order to draw higher level parallels and patterns.

My favorite analogy to describe the difference between architecture and design maybe found here:” Blog: The difference between architecture and design”.

In order to use UML effectively for the purpose of diagramming architecture, we therefore need to be very clear about what we really mean when we use UML design elements. The clearer, more precise and more descriptive we are, the more information we carry in a single diagram.

To this end, I’ve posted a “style guide” for using UML for the purpose of describing Logical (Functional) Architecture here:
There are accompanying Shapes for Microsoft Visio that may be downloaded from here:

The style guide with accompanying shapes provide a fairly complete way of describing Logical Technical Architecture through diagrams, using only three of the thirteen diagram types in UML 2.0.
This style guide only covers “Logical (Functional) Architecture”. It does not cover: Information Architecture, Physical Architecture or Business Process Architecture


Is 2009 the Year for SOA?

I read a lot about Service Oriented Architectures (SOA) and most of the articles start off the same way: “Most companies fail and here are 10 reasons why they fail”. Personally, I would rather focus on “How to succeed at SOA without really trying”, but the truth of the matter is that most companies do fail at SOA and they fail for the same reason, which is that they treat SOA as another technology implementation project and it’s not

So if SOA is not about technology, then what is it? Before answering that vital question, it is useful to first look at why companies even bother with SOA. If we set the stage with a business context, I think some of this makes more sense.

Many companies, either through acquisition or through the independent actions of independent divisions produce a complex technology landscape of independent silos. This accretion process often happens haphazardly driven by expansion.

The first pressure on the architecture is usually for integration. In other words, as independent business units drive their respective technology silos forward, they invariably see features and functions in another silo that they want. They have the choice of either duplicating the function in their silo, or integrating with the existing technology silo which already has the feature / function. Depending on the ease of integration, different decisions may be made.

This brings us to the next pressure on the architecture, which is to provide agility or time-to-market. This is simply the ease of the business to react quickly to a market demand and put a new feature out quickly. Obviously, Agility and Integration are somewhat correlated, because if the infrastructure supports easy integration, then an existing feature may be cross-fertilized from one product to another relatively quickly.

But to truly get agility, software needs to release quickly. No matter what development methodology you employ and how many outsourced resources you have access to, the only tried and true way of getting software to release quickly is to have less of it and to have fewer integration points.

This drives you down the road to the final driver on the architecture, which is to increase leverage or reduce duplication. By separating out the technology that is common to and duplicated amongst all those technology silos and build them once, you gain leverage. By increasing leverage you also reduce the amount of money you spend on duplicated functions, theoretically allowing you to spend more on business differentiating functions.

This brings us to the three main benefits of a Service Oriented Architecture (SOA)

  1. Increase Agility – Providing improved time to market (By far the most important)
  2. Increase Leverage – Providing reduced overall cost and complexity of the technology
  3. Increase Integration – Providing consistency and uniformity of feature sets between products at reduced cost

There are two side benefits of a well implemented SOA that are also worth mentioning:

  1. Improved Quality –Because there is less technology with fewer touch-points.
  2. Facilitated Removal of Legacy – Most companies have a difficult time removing legacy infrastructure and this legacy technology can be like an anchor weighing down the ability to innovate. An SOA with well-defined coarse grained service interfaces has fewer touch-points allowing legacy to be more easily migrated at the appropriate time.

You will notice that at no time in this entire discussion did I ever mention the words “Web Service” or “Enterprise Service Bus” and that there is nothing up my sleeve and at no time did my hands ever leave the end of my wrists. I point this out simply to confirm that for a service oriented architecture to succeed, the entire process of translating business initiatives into technology actions and operation must be adapted. Thinking it’s just implementing a few bits of technology is why most companies fail.
This is because the SOA technology really only provides integration. Integration, while certainly important is completely overwhelmed by the other two business drivers, which are: gaining time-to-market through agility and reducing cost through leverage. Technology alone cannot achieve these goals.

What is a Service Oriented Architecture?
Now that we have some business context for why companies need service oriented architecture, let’s be clear about what one is. Additional detail may be found in: quickly review, the technology landscape, particularly for large companies tends to evolve from technology silos. In these silos, there are generally large amounts of duplicated, overlapping and inconsistent technology choices and complex, arcane business processes that make products difficult to integrate, slow to migrate and costly to maintain.


As the above diagram attempts to show (grey areas representing interfaces and colored rectangles representing functional business logic), by moving to a Service Oriented architecture, removing duplication and integrating the shared services, we can gain agility, leverage and integration. Sounds great, doesn’t it?

A Service Oriented Architecture (SOA) is: a collection of shared services that communicate with each other and with consuming applications to minimize duplication of business logic across autonomous units.

A Service is: a coarse grained, self-contained, autonomous, single-instance, operational set of software modules that perform a well defined set of functions through well defined interfaces.
Services are independent of the applications using them, but inclusive of the computing platforms and all other resources necessary in order to operate. Services are re-used by being called through their exposed interfaces. They are scaled up/out to handle load (i.e. not through the creation of a new instance).

Once again, you may notice that the definitions of SOA and Service never mentioned the words “Web Service” or “Enterprise Service Bus (ESB)”. In fact, you can easily have an SOA with neither web services nor an ESB, just as you can have both an ESB and web services and not have an SOA.

So if a Service Oriented Architecture is not about technology, what is it about?
Well it is about technology, it’s just not only about technology. In fact the technology is the easy part. The hard part is: “making the next right decision”.

When you have an SOA, you have Services, but more to the point, you have “shared” services. While it is nice to share, in a big company it is also hard to share and this tends to be where you either succeed or fail.

Let me explain: When two applications require independent feature enhancements on the same shared service and they both need it urgently and immediately (when has that ever happened?), you have a decision to make. One business unit is generally going to get what they want (maybe) and the other is generally going to wait.

A company either succeeds or fails in its SOA strategy in making the correct decisions as to which products drive the architecture, which wait and which go ahead in a tactical manner.
I use a few rules of thumb when I am involved in these decisions.

  1. It is 2.5 times as costly to make something reusable as not (mostly due to support costs) so don’t do it unless it’s worth it.
  2. It is 7 times as costly to do something tactically as to wait, if you have to then undo it, redo it and clean up the mess. So while there are always tactical and strategic activities going on choose the right ones. Don’t just act because you are bored.

Another interesting issue that companies run into is the misallocation of resources. It goes something like this. Product development group asks service development group for a new feature. Service group is overloaded and cannot get to it right away. Product group says “My business unit is breathing down my neck, so I am being forced to do the wrong thing and act tactically”. Service Development Group says “Tell your business group to wait”. Meetings happen, revenue would be lost; the decision is made to act tactically. The technology sprawl gets worse.

My solution: If the product development group has the resource to do the work, then clearly the resource exists in the company to do the work. So they should “lend” the resource to the Service Development group for the duration of the project so that it is done correctly. The service groups own the responsibility for covering the extra cost of reusability and all is satisfied. All except for the tendency to say “Mine!”

Okay, maybe I am a bit naïve. Or maybe not.