Let’s say you are a clothing designer competing on an episode of Project Runway (I reluctantly confess to be a fan of this show), and are asked to design a man’s suit. Chances are you will design it according to the desired needs and characteristics: winter or summer, business or black-tie, silk or wool fabric, etc. Also, you’ll likely incorporate your own particular professional touches even as you use pre-built suit patterns to tailor it.
For the most part, despite the range of variations that can be expected in the design, chances are that when creating a typical western suit you will end up with a pair of pants and a jacket; not a Scottish kilt or a clown outfit.
Fundamentally, architecture models are no different. When solving a similar business problem, most architecture models will end up looking similar to each other regardless of the vertical industry to which they apply. For instance, the architecture model for a high transaction airline reservation system is going to be very similar to the architecture model for a high transaction banking system, and indeed, these verticals share many of the same technologies. The phenomenon of “convergent evolution” also applies to architectures. Whenever nature requires a solution to a specific problem, evolution tends to arrive at an analogous solution for survival challenges. For instance, it is known that the eye has been arrived at independent by different animal species (the eyes of insects, octopi, and humans are different) and the flight of bats is an independent result of the flight of birds.
But even if most architecture models will resemble each other, as the saying goes: “the devil is in the details.” It will not suffice to copy a model from a textbook and brand it as the definite model for your company. At a minimum, your model must meet these characteristics:
§ It must be Realistic. No matter how abstract a model, it should ultimately be implementable. Also, the term “realistic” here means that the model should apply to the specifics of your company.
§ It must be Mutually Exclusive and Collectively Exhaustible. This is a fancy way of saying that it should be complete but also economical in its definition—without overlaps and without gaps. Unlike actual implementation designs, which I believe should be slightly redundant and overlapping, reference models can strive for Platonic-like perfection.
§ It will clearly describe its key areas as inter-related, decoupled modules. In today’s terms this means that it should be SOA-friendly. Even though, we are still at Level I, and SOA will be formally introduced on Level II, we know already that unless you are architecting something extremely unique and with a very specialized domain as, for example, software for biomedical devices or for games, SOA is the way to go.
The actual Architecture Model will probably be a brief reference document outlining in narrative form the key concepts of the model: components, key technologies, interaction maps, component inter-dependencies, etc. Remember, we are still in Level I, at the hundred-thousand foot level.
The next step is to represent the architecture model via a highly iconic diagram that incorporates all the key elements of the logical architecture as well as representation of the architecture mapping the business processes. I call this diagram the Architecture Reference Model (ARM), and this diagram is destined to become the friendly-face of the Architecture Model you will document. The ARM is to become both your banner in all subsequent architecture socialization efforts. It serves multiple purposes:
§ Synthesizes in a single chart the key architecture elements and messages you wish to convey
§ Serves as a communications icon, identifying the focus of your technology team.
§ It becomes the rallying flag for all your technology design efforts. It gives a point of reference to help the project team place into context the various detailed efforts.
The ARM should be not so detailed that it drowns in complexity; nor so high level and so generic that it could apply as the architecture reference model for just about anything. If your ARM could apply to the coffeehouse across the street, it is likely too generic. The ARM should include substantial content.
The ARM should be visually appealing and compelling. Enlist the services of a professional graphic designer, if necessary. Remember you’re looking for the ultimate iconic point of reference to summarize all your technology design efforts.
Initially, expect the ARM to change fluidly as you receive feedback from the initial drafts, and as you become more assured of the specific architecture representations. After a few revisions, however, the ARM should become more stable. This is not to say that it will never change, but if you’ve developed a properly designed architecture framework model diagram, adding elements to it should not require extreme changes to the core graphic.
The ARM shown below is based on an ARM designed for an innovative hospitality solutions company, and it is reproduced here with their appreciated consent (AltiusPAR Hospitality Solutions—www.altiuspar.com). What should become immediately apparent is that, even though the diagram was initially created for a specific type of industry (Hospitality), it could easily be applied to other industries. Admittedly, I deliberately used generic terms (e.g. Customers instead of Guests), but tailoring and narrowing the specification of this diagram to other industries would be relatively simple.
See how the ARM above visually highlights the following specific aspects of the proposed architecture model:
· External users (Merchants, Web, and Business-to-Business) will be handled via an external access layer.
· The Intranet and internal customer support systems will be placed inside the DMZ.
· All users access the SOA layer to obtain Shopping, Content, and other Services
· The Data Bases are “hidden” from the service users by the service layer.
· Subsystems such as Campaign Management, Sales Support, Loyalty, etc. must support the external and Intranet users and be accessible from regional systems (presented at the bottom of the cylinder)
· You will be providing Publish/Subscribe services to the field offices, which will only be able to access the core system via VPN
· There will be support and management systems for all layers in the hierarchy
The list could go on and on. A good ARM is a little like a good painting whereby, the more you inspect it, the more information you can gather from it. Don’t underestimate the importance of achieving an ARM that can convey all key architecture model aspects in a single diagram. The intrinsic value it provides by focusing the transformation project framework is invaluable. Besides, it will make for a great poster for your office wall!