Returning to classes and packages, the following matrix shows a view of some of the core classes of the Spring framework:

In this typical package DSM the packages are listed on both axes. If a package has dependencies on another package, the number of dependencies is listed at the intersection. The package that has the dependency is on the top, the package that it depends on is on the left. In the example above the matrix shows that there are seven dependencies from the beans.propertyeditors package to the core.io package.

The first, and most obvious, issue that can be spotted in a DSM is a cyclical dependency. Most tools (more on those at the end of the post) try to arrange the matrix such that all dependencies are shown in the lower left triangle. A cyclical dependency makes this impossible and one “half” of the dependency will be shown in the upper right triangle.

In the following matrix, which shows a package view of the Jetty server, we can see that jetty.webapp has six dependencies on jetty.handler but the latter also has a single dependency on the former.

Another design concern is that of cohesion and coupling, very well explained here. Applying this to a package level and DSM it is good to see dependency numbers arranged in squares, showing cohesion between related packages, but rows or columns filled with numbers are often a concern. A row filled with numbers signifies a package that many other packages depend on. This can be acceptable, as in the util package in the Spring matrix above, but often it is a sign of a lack of cohesion. Conversely, a column filled with numbers represents a package that depends on many other packages, which is usually a sign of bad coupling and the possible presence of god classes and feature envy.

These patterns become even more apparent when looking at larger systems. The following matrix is a zoomed out version showing most of the Spring framework.

There is a good cohesion, shown in pink, in many of the subpackages, but there are also some classes that invite a large number of dependencies, shown in blue, as well as a couple of classes that have unfocussed dependencies, shown in green.

At this point I should probably mention that I think that the Spring framework is fairly well designed, and that I’ve seen quite different matrices in the wild.

I hope I have convinced you that DSMs are worth a look, and luckily there is now widespread support for DSMs, in IDEs, e.g. IntelliJ, and in tools, e.g. Structure 101, Lattix, .NET Reflector. The screenshots in this post were created with Structure 101 for Java.

Despite its complexity a service-oriented architecture is high on almost every project’s wish list. I have been involved in eight projects over the last year, sometimes directly delivering working software, sometimes reviewing or advising, and out of these eight projects six were, according to the respective architects, building a system with a service-oriented architecture. On these projects I have come across two recurring uses of language around SOA that I found noteworthy.

Firstly, SOA used to, and still should, stand for an architecture that is service-oriented, with “architecture” being the noun. What I have found, though, is that more and more often people use “SOA” as an adjective and then add it to a more or less random noun, such as “approach” or “model” or even “architecture” again. Yes, I have heard people talk about an SOA Architecuture more than once.

This use of language highlights a problem. Sticking the three letters “SOA” onto a random noun, without pronouncing what the letters stand for, makes it easy to forget what this was all about in the first place. In fact, it seems that “SOA” is now put in front of words such as “approach” simply to make something sound contemporary; as in: “How’s your project?” — “Oh, we follow an SOA approach.” Given my experience, chances are that the project’s architecture is not service-oriented. It might use WS-* standards, though.

Secondly, there are people who are referred to as SOA professionals or similar. It usually sounds like it’s their job to build SOAs. But what does that really mean? Shouldn’t developers built software according to a service-oriented architecture? Are the SOA professionals merely advising teams on how to build service-oriented architectures correctly?

In my experience the SOA professionals have a different agenda, and that is to sell SOA. Unfortunately, in the words of my colleague Jim Webber, there are two things money can’t buy: love and an SOA. Again, using the three letters one might think “why not?” but spelled out, would anybody argue you can buy a service-oriented architecture? Or any architecture for that matter? So, what is really being sold is usually a set of products, software and/or hardware, that may or may not help a team implement a service-oriented architecture.

The key problem in this case is that when you “buy SOA” the success criteria shift. It seems that success is defined based on whether something that can be labelled “SOA” is in place, and not whether actual business value is delivered. What is often completely forgotten is an evaluation of the suitability of the architecture, but that’s a topic for another post.

The diagram above only shows one of the content services, which for the sake of this article is a service that provides contact details for a person.

Based on conversations with the project sponsors I began to suspect that at least the introduction of the ESB was a case of RDD, ie. Resume-Driven Development, development in which key choices are made with only one question in mind: how good does it look on my CV? Talking to the developers I learned that the ESB had introduced “nothing but pain.” But how could something as simple as the architecture in the above diagram cause such pain to the developers? Was this really another case of architect’s dream, developer’s nightmare?

Often a picture says more than a thousand words, but at the same time traditional architecture diagrams simply do not provide enough information. (I’ve argued this before, here and here for example.) The answer to my questions, and the anxious project sponsors’ question whether the project would deliver on time, lay in a different picture.

The picture should not only show the layering of the system in more detail than the architecture diagram but it should also visualise the complexity introduced by the ESB. It’s often possible to produce more detailed diagrams automatically from source code, configuration, or runtime inspection but in this case I couldn’t find a way to do that, which is which I drew the following:

In the centre column this diagram shows the layers involved, from the Struts action that needs to look up details by an ID down to the back-end that provides a “RESTful” service to retrieve the details. The top box contains the front-end layers while the box in the middle represents the ESB. The layers labelled in italics are frameworks or infrastructure software, the rest is project-specific code.

Key to this diagram are obviously the coloured representations of data travelling up and down the stack. Primitive types are grey, Java objects are purple circles, XML documents are shown as turquoise hexagons, and HTTP messages as green blobs. Mule messages, which are Java objects, are shown in dark purple. If one representation is wrapped in another it’s displayed inside the wrapper.

The diagram highlights that it’s a simple piece of data that travels all the way down the stack (actually further until it hits a relational database at some point) and, equally, that the data needed by the action is available in the right form from the service. All that the intermediate layers are doing is wrapping and unwrapping the data in various ways. In fact, out of the four layers of project-specific code three layers do nothing but wrapping. No wonder the developers felt some pain.

As a side note: the diagram also makes it obvious that the wrapping is asymmetric between the WsToRestHandler and the RestServiceWrapperImpl, which makes the point of this layer boundary even more questionable.

This diagram made people more interested in the cost of what had just been a simple, innocuous line in the architecture diagram; which was the point of the exercise. So, what would this diagram look like without the ESB? Easy:

Apart for the obvious simplicity the diagram highlights that every layer has a purpose and there is only one wrapping, which is not undone either. Would it surprise you if I told you that the project went live without the ESB?

Footnotes

1) This article is by no means implying that any of the mentioned technologies are useless or harmful. Their use was harmful in this case.

2) The pattern of wrapping and unwrapping the same data through multiple layers is not new, it was also quite common in early 3-tier architectures. (In fact, some people called their architectures n-tier; I guess to show that the number of tiers was somewhat arbitrary but large.) We had a term to describe this pattern: the wormhole pattern.

3) This project is not an isolated incident of a Wormhole ESB. I have personally seen several in the past years.

About a year ago, in a discussion about architects, rather than trying to define what an architect is or does, we looked at what he or she should know. We expressed our ideas as mini-essays, strictly limiting ourselves to one per essay, and it turned out that, at least to my surprise, there was a lot of agreement; maybe because we hadn’t come up with hard and fast rules but with ideas and guidelines.

Luckily Richard Monson-Haefel was part of that discussion and he had the resolve and means to make our thoughts more widely available. Our list of the 97 things every architect should know was collected and refined on this wiki, and is available under a creative commons license. For a more convenient read it has now also been published as a book by O’Reilly. As expected, the discussions have begun.