Nigel Bakker's SOA Soapbox

Part 1: Software Fortress Architecture

In recent months I’ve been involved in helping companies move toward a practically implemented SOA Infrastructure. I’ll not bore you with the standard change management and political challenges that come with the territory; there are numerous blogs and articles on that particular topic.

What I have been doing is looking at what these companies have been doing with services, and trying to find a way to add additional practices and disciplines that will make it easy to evolve what they are doing toward where they want to go, namely a fully SOA enabled environment.

Apart from their use of services, typically web services, I have found the usual clutter of systems integrated using a variety of technologies, ranging from flat files to queues and direct database integration. What is clear is that no overall plan has been applied to their systems architecture as a whole.  Pieces are sometimes well architected within their domain, but from an enterprise perspective, there has not really been consistency. There is no obvious plan.

So, when faced with “accidental” architecture of this nature, where do you start? I chose to start by trying to establish some order within the apparent chaos. This is where the Software Fortress ideas come in.

For those not familiar with the Software Fortress idea, I strongly suggest getting your hands on Software Fortresses: Modeling Enterprise Architectures – (Roger Sessions: Addison Wesley).

The central problem that software fortresses attempt to address is architectural complexity. The kind of complexity that is typical of an accidental architecture. Sessions uses the term “urban sprawl” to describe this type of architecture. Sadly, this is an apt description and all too often this is what you find in many enterprises, both large and small.

Sessions describes a single Software Fortress as:

“..a conglomerate of software systems serving a common purpose and typically owned by a cohesive group of individuals. These software systems work together in a tight trust relationship to provide consistent and meaningful functionality to a hostile outside world.”

This is perhaps explained better through example. Imagine if you will a business that uses a home grown system for online retail and customer service. It is likely that this system has a database server, an application server of some description, a web server and possibly other pieces. This system has a number of users within the organization, as well as external users. This system is integrated with several other systems, managed or owned by other departments.

If we build logical walls around such a collection of systems and control access in and out, then we have a software fortress. This approach will help us transform the urban sprawl into a well organized and managed metropolis. This so-called Software Fortress Architecture (SFA) ends up looking quite familiar.

Despite this being a serious topic, I cannot help but smile each time I read Sessions’ definition of SFA:

“…an enterprise architecture consisting of a series of self-contained, mutually suspicious, marginally cooperating software fortresses interacting through carefully crafted and meticulously managed treaty relationships.”

When I first encountered the phrase “self-contained, mutually suspicious, marginally cooperating” I thought he was describing a typical large corporation (or government). Turns out that there is good reason for that; If  one considers this to be a fairly accurate description of the departments within an enterprise, then, in my experience, one could pretty easily map the various software “empires” onto the departments since the department boundaries often coincide with application boundaries.

Going back to the central problem that Sessions is attempting to address, that of complexity, you should be starting to get the picture. He goes further however by describing a formal approach to modeling enterprises using software fortresses as the central idea. The notion of a “fortress” is a metaphor of course, but the metaphor is extremely rich. If you follow the theme, you end up talking about guards, envoys, treaties, drawbridges, (castle) walls and other medieval ideas. I find this rich metaphor very useful for explaining the concepts to non-technical audiences. There is of course a formal (boring) notation for when we get down to the serious business of modeling our fortress architecture.

Sessions describes a Software Fortress Model as:

“…a methodology consisting of specific algorithms, categories of technologies, and documentation techniques that together can be used to model and build enterprise systems as software fortress architectures.”

Some important points about software fortresses

There are some important points that Sessions emphasises about software fortresses, (taken from chapter 15) my top points are:

“The software fortress is a trust boundary. Everybody in the fortress trusts everybody else in the fortress, and nobody in the fortress trusts anybody outside the fortress.”

I have found this to be the single most important aspect of SF, it highlights the autonomy of each fortress and the key notion of “trust nobody” outside the fortress. Within SFA, this fortress autonomy is central.

“The software fortress consists of many close-knit systems, machines, and processes. These systems, machines, and processes work together to solve a significant business problem, such as accounts payable.”

When combined with other SF ideas, it begins to become clear that at an enterprise level, the specific technologies matter less. If one department has a system or systems built on Java technologies, and another uses Microsoft technologies, this should not have any significant impact on the overall approach. Technology boundaries and trust boundaries tend to coincide.

“Every fortress has one or more places where fortress-critical data is stored. These are collectively referred to as data strongboxes.”

This has a profound impact on the way we view “enterprise” data. What Sessions is advocating, and I agree with, is that each fortress has responsibility for any and all data related to the function it performs. What happens when core entities within our domain cut across fortresses? Surely logic tells us this should be centralized!  (Think customer, account, product…)

Let me ask you this; when last did you encounter a single centralized data view that actually made it off the paper into live systems? The only time I have seen this work is when the model defines the messages exchanged between systems. Actually getting different parts of the business to agree to a common view of each enterprise entity is a problem in itself. Getting one of them to take ownership is another.

What this idea is formalizing is something we’ve understood, but perhaps failed to accept for ages. It’s not only ok to have multiple copies of the “same” data in different applications, it’s desirable. (But what about synchronization? I hear you asking… – well what about it? Does it ever really work the way we want it to?). I’ll explore this again later in the series and talk about how I believe this should be handled.

The idea of a common data model is one I definitely subscribe to. What I don’t buy into is that there should be only one (physical) source.

“Every fortress is protected by one or more systems that prevent communications from being received from the outside world except through approved channels. These protective systems are collectively referred to as walls.”

The immediate impact of this attribute of SFA is that it cleans up communication lines. The first things that tend to go are direct-to-database and file based integrations that bypass regular security. As a rule of thumb, if your system has a “service account” type user so that another system can gain direct access to some part of your fortress, then this is being violated.

“Fortresses always regard each other with suspicion, but sometimes they must work together despite this suspicion. Fortresses that work together to accomplish a mutual goal are called allies” and “Ally relationships are defined by all-encompassing agreements called treaties”

For me the key thing here is that when systems must co-operate, it is critical that we define the rules of engagement in a clear and unambiguous way – we specify a treaty. This goes way beyond service interfaces, and includes things such as security, transformation rules, business rules and anything else that provides mutual protection. Treaties need to be enforced by technology wherever possible.

“When one fortress makes a request of an ally, it does so over a formal communications channel known as a drawbridge. A request passing over a drawbridge is referred to as an infogram.” and “When a fortress wants to communicate with an ally, it does so using an internal system called an envoy.”

What these two points promote is a message based system, and more importantly, asynchronous messaging wherever and whenever possible. Let’s not forget our scope which is inter-system, not intra-system. When exchanging messages between fortresses, asynchronous messaging is more reliable, scales better and importantly, promotes the loose coupling which we strive for.

“When a fortress receives a communication from an ally, that communication is subjected to inspection and possibly other security measures (such as auditing) by a specialized system called a guard. The guard decides whether to accept the request on behalf of the fortress.”

The notion of a guard for me is of singular importance. Without getting into the “how we implement it” yet, what stands out for me is that we have moved some of the decision making about what we are prepared to accept from external agents to a “third party” that has a single purpose; Protect the fortress inhabitants at all costs. The guard can also take on responsibilities such as decryption of encrypted messages, translation (transformation) of messages, inbound validation and other gatekeeper type responsibilities.

Wrapping Up Part 1

The notion of Software Fortresses fits so well with the ideas espoused by SOA and yet is not nearly as well known. This is a pity since it provides such a well structured approach to architecting your enterprise systems in what is explicitly a technology independent manner.

I used more space than I intended on this topic, but since it underpins the overall architecture approach I wish to explore, I believe it is space well utilized. If nothing else, I hope that it gets you to look deeper into Software Fortress as another power tool in your EA toolbox.

There is a growing trend amongst the developers I work with to take a “service oriented” view of what they are doing. They frequently refer to their efforts as being SOA development. I find this quite disturbing, since they are not actually engaged in SOA.

SOA, like many terms and acronyms in the world of software and computing is heavily overloaded. I thought I’d offer a few perspectives on SOA in an attempt to clarify the differences.

Let’s start by expanding the term SOA as Service Oriented Architecture. It could also be expanded as Service Oriented Applications, but I find this overload to be confusing. For the purposes of this discussion, SOA refers to Service Oriented Architecture.

Scope

First off, there is the question of scope. SOA is intended as an Enterprise Architecture approach. By definition this means that it recognises the existence of all applications and business domains. It is primarily concerned with enabling business processes across these applications and / or domains.

When using service orientation as an approach to application design, an approach I prefer to call Service Oriented Application Design (SOAD), we are generally confining ourselves to a single application, and by implication, the single business domain for which the application is intended. Obviously, some applications do cross business domain boundaries, but the fact remains that the focus is very much at the application scope.

When we apply SOA design principles at an application scope we tend to make tradeoffs that favour the application scope more than the enterprise scope. In his seminal work, SOA: Principles of Service Design, Thomas Erl classifies services in models. These models map (loosely) to layers and form a natural hierarchy. The names he uses are Task Services, Entity Services and Utility Services. Task services encapsulate business process logic. Sometimes these services cut across business domains and applications. This type of task service is often implemented using some form of orchestration technology (such as BEPL). These orchestrated task services, a.k.a. parent business process services or parent task services span application domains, and are squarely in our sights from a SOA perspective.

Service Orientation as an application design approach

If our focus is at the application level and we are applying SOA design principles, then surely we are “doing” SOA? The problem I have with this is that when using the term SOA in this context we are dragging in a bunch of enterprise architecture concepts that may not be appropriate.

Service Orientation at the application level is not new (Inversion of Control frameworks such as Spring tend to be service oriented), only today there are other, more powerful technologies (such as WCF) that make service oriented application development much simpler and more mainstream.

But is this SOA? In my view not directly – purely because the scope is at the level of the application. It does however make it much easier for a business to leverage the functionality of an application when we implement business processes that include its domain. SOAD is a means to service enable new applications from the ground up. This tends to make them first class citizens in a SOA, as opposed to typical legacy applications that may require significant effort to service enable.

Service Orientation as a business process enablement approach

In an enterprise where you have service enabled applications, it becomes common practice to begin leveraging those applications in more complex, cross domain business processes. Several things drive this, including replacing point-to-point integration, eliminating manual recapture of data and of course, supporting new or improved business processes.

At this level we are clearly in the domain of inter-application (or inter-domain) business processes, being processes that cut across more than one area of the business. This is also the domain of EA and therefore of SOA.

When working at this level, we would typically be using business process modelling to define our processes, followed by implementation of the automated sections of the process via some form of orchestration such as BPEL. This tends to result in composite services which use BPEL to implement some or all of their service logic.

Interestingly, these cross domain services tend to be less time sensitive than services within a particular application domain. In order to promote service loose coupling, these services are often implemented as business event sinks, consuming these events as subscribers, and publishing events in their own right where required.

Synchronicity

One of the observations I have made is that the lower down the hierarchy of services one goes, the more likely it is that the service is consumed in a synchronous fashion. Business task services are often not that time sensitive, since typically they involve some form of processing in response to a business event.

For example, if a customer calls into your call centre to update their address, the most likely situation is that the CRM system will be used to capture the changes. The actual process of updating the details is confined within the domain of the CRM application. Once the update is complete, this becomes a business event which other domains may care about. The billing system for example, probably cares about contact details, since it needs to be sure that the bills are sent to the right place. For this to happen, the billing application needs to be told about the change. Does this need to happen while the client is on the phone with our call centre agent? Probably not. We could simply publish the event, and let all interested applications consume and process the event at their leisure.

Within the CRM application itself, things are a little different. Assuming we have implemented CRM using a service oriented design, there would likely be an entity service responsible for managing customer data. When the agent hits the “ok” button on the screen, it’s important that he or she gets feedback immediately confirming that the update has in fact been applied. This update would need to be immediate, and clearly synchronous calls are better suited to this level of usage.

This asynchronous / synchronous differentiation has a profound effect on our overall application design, and is therefore one of the factors that influences the way in which we apply service orientation at the level of the application.

Service Oriented Application Design definitely supports and contributes to a Service Oriented Architecture, but purely on the basis of a too narrow scope, is not itself SOA. This being the case, let’s use the term SOA where it actually applies and call what we do at the application level by a different name… say SOAD?

The short answer is no. While an ESB (Enterprise Service Bus) adds significant value, there exists no direct technical reason that you need an ESB.

Perhaps a more pertinent question should be: Should I use an ESB in my Service Oriented Architecture?

ESBs have come a long way over the years driven by many factors including the increasing adoption of SOA and the resulting maturity of relevant standards. Most ESBs started as simple message based integration solutions, providing the means to integrate heterogeneous applications in a consistent manner. The bulk of the major ESB products have their roots in message oriented integration solutions.

Searching the Blogosphere there is an incredible amount of vitriol around ESBs. Much of it seems to me to be an emotional reaction to poor implementations. Personally, I blame the vendors who promise the world and deliver very little, often hijacking your architecture by attempting to fit it to their view of the world.

The fact is that you can implement a “pure SOA” without an ESB. But somewhere in the mix you actually do need real technology. The SOA space is new(ish) and the technologies are still maturing and converging on standards, which themselves are maturing.

There does not even seem to be standard definition of what constitutes an ESB. What does seem to be common amongst the products offered by the industry leaders includes:

• Sophisticated messaging; Most ESBs have their roots in messaging so it’s no surprise that this is both common and a strength. You typically find both point-to-point and publish-subscribe supported. What varies a lot are the capabilities of the management tools, especially in the management of subscriptions and routing.
• Support for Web Services; This has become universal – most ESBs provide “out of the box” web service technologies for wrapping existing functionality as web services.
• Business Process Orchestration; SOA only really begins to add value when services are course grained and business oriented. Business processes cut across business silos, so the use of BPM tools is a natural approach to driving out business services.
• Mediation; Normally this is provided through so-called adapters. Adapters provide a means of accessing data and functionality in a variety of legacy applications. These range from basic file access, to sophisticated application specific API level access (think SAP etc).
• Service Orchestration; Often referred to as service composition, this is a means to combine multiple services into a single logical service without writing any code.
• Routing; Often part of messaging, it can also play at the service level in terms of service virtualization. Routing can be static or dynamic based on content and other criteria.
• Management; Monitoring, auditing, control, admin etc. This adds significant value from an operational perspective.

What this list represents, is mostly plumbing. Depending on what technologies your organisation uses you should already have some plumbing for creating services. What an ESB gives you is a coherent plumbing toolbox that frees you from needing to concentrate on too much technical stuff.

An ESB is not a silver bullet. In fact I would go so far as to say that silver bullets (of the software kind) do not exist. An ESB will add a number of useful tools to your toolbox, but you will still have to do a lot of work to get your SOA in place. Simply buying and deploying an ESB does not mean that you suddenly have a SOA. In fact, this approach is likely to lead you toward what’s become known as an ESB Oriented Architecture. This has common elements with a SOA, but is not a SOA and will not give you the same benefits. What you will have is an integration platform and not much else.

SOA is a mindset, not a technology stack. Be wary of ESB vendors who come armed with a so-called reference architecture. Architectures must be designed to fit your specific needs. There are many common SOA patterns that will apply in many different organizations, but the way in which they are applied and combined tends to be unique.

When embarking on your SOA implementation, first work out what your architecture should look like (your to be view of the world). Then sit down and evaluate which technologies you need to implement your vision. From this you can decide which ESB (if any) provides the best out of the box fit. There will probably be gaps. Look for products that plug these gaps, or be prepared to plug them yourself (as a last resort). Do not let an ESB vendor highjack your SOA. Make them fit their product to your vision, not the other way around.

So let’s restate the original question as: ‘Can you implement your SOA without an ESB?’ The answer of course is: ‘Yes’. Should you implement your SOA without an ESB? ‘Probably not’.