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.