|Chapter 16 - Show me your Architecture|
The focus on architecture has moved us from statements of "We have a client server architecture", or "We use an n-tier/service oriented/distributed architecture", to trying to come up with a pictorial representation of what is probably an extremely complex collection of machines and concepts.
The difficulty we face is that software architecture is an abstract concept. Some portray architecture as layers, others as block diagrams with joining lines or arrows, others again in huge 3d formations, resembling chemical factories and equally as unpleasant to have to look at. All are useful as starting points for discussion, and after some persuasion and adjustment, come to have some meaning within a community of like-minded souls.
Here are two views of a layered architecture, as described in .
Figure 1. a) Automation Oriented Architecture stack mapped to business departments. b) The layers mapped to a three tier pattern.
The benefit of the layered diagram on the left is the obvious delineation into areas of specialisation, and even to business departments in the larger layers of Business, Development and IT Support. The layers are further explained in the diagram on the right, which displays a path through the layers with an example of taking an order.
Figure 2 shows a layered architecture, where each of the four layers has been broken down in more detail.
Figure 2. Exploded layer diagram
In this case, more detail has been added to the layers to delineate areas of interest, without getting bogged down in detail.
Figure 3 attempts to show far more detail, including specific technologies, and a breakdown into a five tier architecture. One important aspect of this diagram is its name. A polo is a small round mint with a hole in the middle. The two polos at the bottom are used as a visual reference and memory hook so that a mention of two polos brings this architecture diagram to mind.
Figure 3. Two Polos architecture
This final example in figure 4, shows technologies, business processes, specific applications, and also lists COTS applications and the taxonomy of the enterprise, which a keen eyed viewer may recognize as a consultancy.
Figure 4 Business Process, Technology and Application Architecture
These four figures have a few things in common. One is that they are all highly specialized displays of what is considered important in a specific environment at one moment in time. It may be of interest to note that figures 3 and 4 are different views of the same enterprise. Figure 4 is a where we are now illustration, representing diverse applications tied together by export from x and import into y. Figure 3 is a concept of how it could all be tied together within a unified architecture.
Another interesting point in these four figures is that they have very little in common, other than an attempt to delineate areas of interest. However, a successful architecture must be far, far more than this simplified delineation. We require a full set of blueprints created to a set of standards which are only now emerging.
If security is important, the architecture must contain a security model. If an architecture must support 24x7 operation, there must be a model within the architecture indicating how this will be achieved. If deployment is in three geographical locations in dual-redundant server farms with firewalls (two foot thick concrete ones, not an extra server with a bit of software on), then there must be a deployment model. Only collectively, do these independent models comprise an architecture.
So instead of our depictions of colourful abstraction, what is available to us to present an entire architecture?
Here are some methods purporting to do so. For references, see the end of the chapter.
|C4ISR||Command, Control, Communications, Computers, Intelligence, Surveillance, and Reconnaissance||Includes the Core Architecture Data Model (CADM),
a formal model defining the data organization for a
repository of C4ISR/DoDAF-compliant architecture products.
|DoDAF||Department of Defense Architecture Framework||Including the DoD architecture repository (DARS)|
|EAP||Enterprise Architecture Planning|
|FEAF||Federal Enterprise Architecture Framework|
|IEEE-1471||IEEE Recommented Practice for Architectural Description of Software Intensive Systems|
|ISO 14252 (IEEE 1003)||Developed into TAFIM, then into TOGAF|
|MDA||Model Driven Architecture|
|RM-ODP||The Reference Model for Open Distributed Computing|
|SPIRIT||The SPIRIT Platform Blueprint||Service Providers' Integrated Requirements for
Information Technology (SPIRIT) Platform Blueprint
is a specification that was developed within the
Network Management Forum, now known as the TeleMangement Forum (TMF).
|TAFIM||Technical Architecture for Information Systems||Based on IEE1003 and superseded by C4ISR|
|TEAF||Treasury Enterprise Architecture Framework|
|TISAF||Treasury Information Systems Architecture Framework||Superseded by TEAF|
|TOGAF||The Open Group Architecture Framework||Includes the Architectural Development Method (ADM)|
|Zachman||The Zachman Framework|
Figure 5. The architecture framework quagmire [n]
Instead of detailing each one of these methods, a study of one will prove more valuable. We will look at TOGAF.
The Open Group's Architectural Framework is gaining some momentum. Its purpose, as will all architectural frameworks, is to avoid starting with a blank sheet of paper when creating architecture. Just as with RUP, it contains tried and tested ways, best practices and foundations upon which things are built. It is an industry wisdom consensus, tool and technology neutral method.
A TOGAF enterprise architecture comprises four separate, but interrelated architectures.
Data or information architecture
The Data and Application architectures are referred to collectively as the Information System Architectures.
TOGAF itself comprises three main parts
The Architectural Development Method (ADM), is represented in figure 6.
Figure 6. TOGAF's ADM
Each phase is defined in increasing detail, with reference to the key elements of TOGAF, and how they are created. The structure of each section is the same, detailing the objectives, approach, inputs, steps to be taken, and finally, the outputs to be used in later phases. More detail is available in the TOGAF document or website .
The continuum itself can be thought of as a box containing all of the architectural assets: documents, descriptions, models, beliefs etc, that an organisation has created.
TOGAF provides two reference models for inclusion in the Enterprise Continuum, the TOGAF Foundation Architecture (TFA), and the Integrated Information Infrastructure Reference Model (III-RM). III-RM is itself based upon TFA, and one is selected as a foundation upon which an architecture is created.
Figure 7. TOGAF's High Level and Detailed Technical Reference Model (TRM)
The SIB is a searchable online area listing IT standards documents and their publishers, with links to those available online.
Figure 8. TOGAF's Detailed Integrated Information Infrastructure Reference Model (III-RM)
The Resource Base is a collation of architectural and business know how and measurements. It contains advice on the following:
Setting up an architecture board
Ensuring projects comply with the architecture
How to set up contracts between sponsors, developers and suppliers
Guidelines for IT governance
Assessing architectural maturity
Guidelines for using architectural patterns
Principles for the use and deployment of IT
Roles, skills and experience for architects
The use of architectural views
Business process views
A method of extracting architectural requirements from technical and user requirements
Architecture tool evaluation
A comparison and mapping to other architectural frameworks
The architectural frameworks continue to align with each other, and as they do so, gain weight. It is clear that Enterprise Architecture is a large complex subject, differing greatly from one organization to another. TOGAF is well placed to evolve into the defacto architectural framework, just as UML became the preferred design method.
The drawback, and perhaps the strength, of TOGAF is that it is not prescriptive. It does not give you an architecture out of the box. It is a method to support an experienced architect and would be of lesser value to the inexperienced.
The realization may have dawned by now that this is not a simple thing to do, because it is highly dependent upon an organization, and what is deems important.
Some will value business services and processes. A large insurance company's initial architecture would be highly application focused. A new company's architecture may be nice and clean, but the same could not be said for a company which had been investing in IT for the past 30 years. TOGAF's TRM points at a high level grouping of important things. The III-RM has a lot more detail which may or may not be applicable in any given environment.
Architectures are comprised of software, hardware and communications networks. Architectural Descriptions are a collation of descriptions, patterns, models and beliefs.
Any business where people do most of the work, such as the Stationer example of chapter 7, may be most interested in the following views:
Business services, processes and workflows
Roles mapped to processes
Processes mapped to Applications
Robbie the Robot, also of chapter 7, wouldn't be interested in any of these views. He'd want to know about:
Every item of importance must be included in the architectural description, and here is a taster of the top level architecture document
Bonzo Inc. Architecture
This is the starting point of the Architectural Description for Bonzo Inc.
Bonzo Inc is located in Mumbai and sells
products manufactured in house to magic stores worldwide.
Bonzo's architecture is based on TOGAF's technical reference model, and extended to fit our particular needs.
The important architectural concerns are
Each model identified in the standard models and architectural
concerns is described in a separate
Creating an IT architecture can be as simple as selecting a set of applications, installing them on some servers and writing a few batch import and export routines to keep each one up to date.
Or it can be a complex undertaking requiring every inch of an architect's knowledge, experience, skill, insight, inventiveness and careful planning to create an extraordinarily complex but magnificent, well-oiled machine.
The architectural description reflects the complexity of the undertaking. More complex requires more models, more views and more description. Simplicity means that more models and maps can be combined in fewer diagrams. If it all fits in one diagram, that is what you slip across the table when someone asks to see the "architecture". If it is more complex, and is highly likely to be so, you point them to the relevant area of storage, or you give them the thick wad of papers that are collectively what they requested.
Yes. As long as it can be understood and delivered.
It appears not. A certain capability of abstract thought is required, and not all developers can make the disconnect between concrete and abstract deliverables. 
See the next chapter.
See the next section.
Reference models and architecture frameworks do not in themselves help you to be brilliant. They help you be methodical, which often has a more reliable output. To be brilliant is another challenge indeed, and requires a slightly different focus, deeper though, and an ability to weave many abstractions at the same time.
We have touched before on the seven habits of highly successful people. This section reflects on these people habits and applies them to machines. It also adds in a number of habits particular to machines.
Push technology is a proactive IT mechanism. A proactive robot will sense when its battery is low, and plug itself into the mains for a recharge. Proactive software will email the CFO when a suspect payment is made rather than wait for him to go and look for it. In a proactive world, when you book a meeting, clever software will book the right room for you without you having to raise a glance at a telephone or finger to a keyboard.
Event driven architecture (EDA) is a proactive architecture. Message Queuing appears the medium of choice, allowing proactive messages to stack up and be processed at the receiver's operational speed. Message queuing's loose connection is much more resilient than relying on remote calls.
In the mist between proactivity and reactivity lie load balancing, failover and workflow based upon operator load.
An architecture has to grow. It cannot be
developed in one project or delivered out of a box. It is similar to a corporate
structure, which also doesn't come predefined. In business terms franchising
offers an opportunity for structure in a box, which is exactly what the
architectural frameworks try to deliver, although with far less detail than a
The end is a seamless, resilient architecture. Beginning with the end in mind means working towards this goal.
One example of an end will be when a worker looks in only one place to see what work they have to do. At present, a particular worker may have to check on a mainframe, take verbal directions from peers and superiors, read through email, looking in a workflow environment, check the post-its on his desk, chair, screen, and finally revisit his things-to-do-list. The end is a single point of reference for things-to-do. The architecture will include work request submissions, authorizations and viewing. To build this in to the architecture requires the addition of a message format, integration technology to allow the message to travel from many systems to a point of collation. Workflow will provide redirection to a supervisor for authorization. Proactive software will balance the workload, and finally a single viewing application will allow the worker to see his things-to-do list. If he adds to it himself, the proactive workload balancing software will not overload him with other's requests. And that cryptic gap in your day will be a fire evacuation practice.
This habit has begun to be applied in that written and verbal communications have been overtaken by email. Unfortunately in the interim, technologists have invented many more lines of communication, such as workflow and texting.
Beginning with the end in mind also means looking beyond the enterprise, as communications are not limited to the enterprise. In a supply chain, a worker requests an item from a store. The store, being empty then requests the item from the supplier, who in turn requests it from the wholesaler, and thence the manufacturer. The manufacturer may need parts to produce it, and the part manufacturers will need raw materials, maybe from the mining consortia. With the end in mind, this will be a seamless request, uninterrupted by human. Automated supply chains must be supported by a reflective architect.
IT systems are always prioritizing. Our microprocessors prioritize work, as do our programme managers. An architecture supporting first things first would send highly important messages before less important ones. It would list our single work view in order of importance to the enterprise, while ensuring that important sequences of process are efficiently arranged.
In software development, the first thing is the architecture. Without defining at least a skeleton to support the loftier goals of the enterprise, development will be less than holistic.
Each move in the chess-like world of enterprise architecture must benefit the architecture, benefit the developers and deliverers, and benefit the users. Everyone must win. One team must not win at the expense of the others.
It is difficult in worldly communication to create a win-win situation from opposing ideologies. In IT, we must think win-win-win for the architecture-developers-users. This is possibly the most difficult of all the trials an architect is faced with, and certainly more daunting than the technological challenge. For example, project pressures can circumvent architectural decisions, which leaves the architecture less ideal and possibly less robust.
Understanding means speaking the same language. Data needs a common (also known as a logical or canonical) data model. Messages need to use the same protocols, most likely http over tcp/ip. A common understanding of business and corporate terms must exist in a taxonomy or hierarchical ontology. If your software understands, it is able to convert the common data model into its own representation of that data. Similarly, if it wants to be understood, it must convert its internal data into the common data model before sending it out.
This conversion process can be internal to each software application, or handled by an integration layer. An integration layer uses the canonical data model and a set of transforms to convert the sender's format to the common format, then the common format to the receiver's format.
Synergizing means getting more than is capable from the sum of the parts. At present, we get a fraction of a percentage of the processing power available to us on the many desktop PCs any organisation owns. Most of the time they sit idle, waiting for the excitement of a keystroke or mouse movement which will take all of one trillionth of a second to process. Then seconds of zero productivity go by until the next nudge of the mouse. At night, they are switched off - their asset value slowly decomposing as they do nothing.
Moving towards possible synergy in this example
is to use grid computing, where computational tasks are shared out between all
unburdened microprocessors. There is little value in one processor working flat
out while many others are idly waiting for its output. Share the burden with
Synergy in architecture is a difficult concept to grasp, but may be better understood once we can at least move towards efficiency. Efficiency is created by the careful balancing of users needs, architectural concerns and developmental pressures to create a synergistic group of people, and in turn a useful, future-resilient architecture.
To sharpen the human is to take time out. To
rest, to reflect. It is difficult, or pointless, for a processor to take time
out as they cannot yet reflect.
Sharpening the saw in IT is to revisit every tooth in turn to make sure it is correctly aligned and performing well. Sharpening the architecture is continually revisiting the current and intended architecture and reworking in light of experience, knowledge and new applications or technologies.
The 7 habits alone do not define corporate
culture. They are for the individual.
The corporate world is still not interdependent. It uses (in the main) a tired and fading metaphor of command and control rather than interdependent systems.
IT, for once, is a small step ahead in that there is no CEO. The CEO role in Enterprise Architecture is either a shared and distributed force, or it is filled by a group of operators. I shall not delve into the conundrums this could present, nor am I suggesting the CEO role is unimportant!
You may also have heard a few more mantras other than those indicated in the 7 habits. Here are some relevant to machines: Be flexible, delegate, manage time and resources better, speak a common language and promote non-formal links.
OK, no-one may have heard the last one, but have you ever noticed that the smokers, those who huddle together outside cleansed offices, always know more about what’s going on than anyone else. The reason is that they form a social network reaching across company delineations. The same goes for gym members, local drinkers, or any other special interest group peopled from within an organization. According to Ray Reagans and Ezra W Zuckerman: Teams are less productive when its network remains concentrated among relatively similar persons.
How many times in Star Trek is the engineering problem solved by rerouting? It seems to bring an otherwise crippled starship back to life. Rerouting will make your architecture miraculous. But how do you do it?
Rerouting is managed through a service capable of farming out requests and rerouting them when required. Imagine the following scenario: A piece of processing work is posted to a rerouting service. The rerouting service has a glance around to look for an unburdened system capable of performing the task. It sends is along with a timeout of five minutes. Half way through the process, the computer performing the task fails. The timeout occurs without response, so the task is routed elsewhere.
A proactive rerouter may even monitor computers
it has sent work to, to see if they are still up and running. It may even send
the task to another service to estimate the time required for completion, to use
that as an indication of the correct timeout value.
In addition to rerouting, a service may be designed to be able to restart something, or even give up and try again later. It has to be flexible.
Workflow systems, as they route work requests to people, who may be off sick, or on holiday, or dead, must have such flexibility designed in.
Why, in a perfectly load balanced, well
distributed system, would anything have to delegate?
One reason is that in an event driven world, a machine may be given a task at which it excels. If it’s busy, it should delegate its current task elsewhere. In a load balanced system, delegating back to the load balancer would be the best option.
In enterprise architecture, the people, the business architecture and the IT architecture will work most efficiently when they synergize. When machine can delegate to man, and vice versa, within a flexible, balanced system, operating on the first thing first within a load balanced, coordinated workflow, an enterprise will run more efficiently.
A logical data model and a logical process model are essential in a connected world. People in an organization speak the language, hold the beliefs, and spill the acronyms of the organization. However, these logical models are becoming domain specific rather than enterprise specific. For example, an insurance company may use the industry standard logical data model Polaris, rather than one created to their own internal beliefs. Doing so means that customers and suppliers can also speak the same language. Speaking a common language in architecture is conforming to standards that exist beyond the enterprise.
Until recently, this was achieved using the import/export functions of data and office tools, or more often by using the same tools (hence the popularity of Microsoft Office) to avoid integration problems.
Architectures and designs can speak a common language by using architectural reference models, views, and modelling notations.
Has anyone seen a computer in the gym, or
standing at the bus stop?
Possibly not. However, a machine can look at a list every now and then to decide who it is going to delegate to. It may learn, using Bayesian or neural algorithms who might do a job best, and it may share that information with others. Sharing can be centralized, but then two pieces of information cannot exist together. Thus they cannot merge or diverge, and cannot grow genetically. Centralized information cannot hold A is best and B is best. Non-formal can.
To illustrate this concept requires another story. Two computers, A and B, learning with neural networks, decide that C and D respectively, are better at a certain task. A sends to C, believing it to be the best, while B sends to D. One day, D begins to perform slower than B is expecting, so B fires off a request to others asking who performs the same task, and who do they send it to? A replies with C, and B sends to C, which performs the task better than D. B then moves C to the top performer and D to second place. The next day, B sends work again to D, and finds that it performs better. It resends to C, and notes a slower response to D, and moves D back to the top of its performer list.
Human non-formal links are created by behavioural tendencies. In computers, the need to do so is less marked as they are all interconnected through a network. Non-formal in a machine's case mostly means non-centralized.
IT projects get cancelled. All of the work done
is wasted. Working smart would be (in order of smartness) to cancel the project
earlier, to never have started the project, to never plan the project in the
Many organizations waste lots of effort because they are not collectively smart enough. In this case, the smartness is being smart about business desires, technological feasibility and delivery capability.
A smart architecture is a level headed, deliverable one. Expecting hard work to deliver the sub-ether faster than light communicator is not going to help deliver it.
When a single processor is running at 100% while others await its output, it is not on the smart task. Delegation is smart, not working hard. The same goes for architects.
There are three great inefficiencies: entropy, latency and procrastination.
Procrastination can be overcome by workflow, human and machine load balancing, prompting mechanisms and a single place where work is displayed to the worker. A procrastinating architect can only be moved by cakes.
Entropy is the energy lost to the system, or the work done by a system which provides no output.
Latency is the long and often painful wait for a response.
Entropy and latency are the subject of .
Scientist have a long, distinguished, tried and tested method of proposing and often destroying theories. The steps of this exercise are: create – peer review – publish – read - improve.
Although IT is a fairly new arena of thought, and IT architecture even newer, there are other disciplines who have waded these snark infested waters before us. Development methods, architectural frameworks, architect organisations and others' designs are all available to us and we are more effective when we refer to them.
There are certain things in IT that will cause others to avoid you. Here are two:
Single points of failure exist in many people and technical arenas. If the CFO is off sick, the large cheque can’t get signed. If the ship's propeller breaks, the ship won't go. If the email server is down, the email won't go out. If the office is on fire, the people will leave.
Usually, dual redundancy is used to avoid SPOFs, but there will still be a single point at which feeds the dual redundant systems. This is a smaller SPOF, but a SPOF nonetheless.
If a spoke on your bike wheel goes, the chances are
good that you will still be able
to pedal. If a few go, the wheel may begin to wobble, but on you will go. There
will be a critical point of failure when the wheel begins to fail, but it
doesn’t happen with spoke one. However, if the hub on your wheel goes, you’ve
An IT hub may be load balanced and failovered to avoid the SPOF, but what happens when the hub us overloaded because every single system in the enterprise is shouting at it? It becomes a SPOF and a bottleneck. The stack of messages grows faster than can be processed, thus the bottleneck, and eventually it overflows, thus the SPOF.
Architectural methods for avoiding these must be carefully designed. A hub must provide mechanisms for handing off (delegating) or readdressing work. For example, instead of saying “Hub: give me the address for person X”, you would say “Hub, where can I get the address for a person when I have their name.” The hub supplies the location of the service rather than redirecting a request to the service, and frees itself up to fail all it wants. Addresses will still be found even when the hub has failed.
Hand off and readdressing make a system highly resilient. If a system asks the question “Hub where do I get…” and doesn’t get a response, it can continue using the address it was using yesterday. All applications written within an architecture that defined such operation would benefit the architect, the systems (hub and requesting application) and the user, a win-win-win situation.