Over the last few years, more and more enterprises are embracing IT Architecture which is a good thing but I want to highlight the issues and concerns with boldly adopting a framework and standards without fully understanding the true purpose and intent of the Architecture in Solution Communication.
Modeling & Frameworks
Over the years we have seen many different forms of modelling appear such as BPMN, UML, ADL, JML, Archimate and classification frameworks such as Zachman and more recently TOGAF. Though these languages and framework has helped standardise and improve the general effectiveness in which Architects & Business Analysts are able to define & communicate solution and enterprise architecture in a standard way, we have started to lose sight of the real purpose of architecture and spending more of our time focused on the framework than on effective solution communication.
Klingon
Heghlu’meH QaQ jajvam – “Today is a good day to die”
Presenting Architecture diagrams in Archimate or similar modelling languages and presenting these to the various stakeholders is like asking the business to sign a contract written in Klingon discussing the “Ferengi Rule of Acquisition” we should not be expecting our stakeholders to learn Klingon, what we do need to do is to learn to communicate in their language.
Sadly there is no universal translator or babel fish in which we can utilise to easily translate architecture to the business or developers, but we can’t lose sight that this is the primary role of Architect, to define, design and communicate the intent and impacts of a solution to the various stakeholders.
Visual Communication
For any given architectural design, solution or blueprint there is always various stakeholders that will need to review, implement, approve and endorse from the inception thought to the implementation phases.
To achieve this goal, Architect’s have to focus their skills in being able to effectively communicate often complex ideas and solutions in a manner that the reader is able to understand either detailed enough for developer or an engineer to develop a work package or a sponsor to sign off that the solution addresses the intended business problem.
Conceptual vs Logical vs Physical
It is all too easy for an Architect who has a strong background in technology to focus on the physical aspect of a solution and end up with a solution design that closely resembles the schematics of the space shuttle at the expense of effective communication.
This detailed physical architecture though helpful for those that are building a solution, it does not help business stakeholders whom are interested in the intent, functionality and purpose of the solution, in this instance a conceptual solution would have been the right level to discuss with the business
Let’s drill in the various levels of abstraction when discussing architecture.
| Level | Description |
|---|---|
| Conceptual | Architecture that lacks a lot of detail in order to plan or communicate the basic intent and structure of the solution. (shows the relationship and impacts between each of the elements, think the “What“) |
| Logical | Architecture that is not constrained to a particular technology stack or environment but lists all of the various functional components. (Capture inputs and outputs of each of the main components, think the “How”) |
| Physical | Detailed architecture that provides detailed view of each component, and platform (details on network zones, server specifications, hardware and components, think the “Where”) |
Architecture Views and Tiers
Depending on your role will detriment the view and scope across the various tiers of architecture you present. Enterprise & Portfolio Architectures are constantly changing and evolving views which try to keep track with business strategy, whilst Solution architecture is most often a snapshot in time which addresses the immediate project solution problem. The key concept is the audience, Enterprise and Portfolio architects work most closely with the business and strategy functions of the organisation and communicate using illustrations that show the relationships and impacts of systems to the enterprise. Whilst Solution Architects develop architecture artefacts that are most often used by developers, network engineers and IT security, for the creation of detailed work packages, detailed solution reviews.
Building the thing right or Building the Right Thing
An expression I use all to often is “Are you build the thing right or are you building the right thing” Whilst both are very important, knowing your audience and the purpose should be driving how you present an idea or concept. As I mentioned earlier, we should not be using Klingon to present architecture, it should be information that is presented in the clearest and easily digestible manner in which others understand the intent, design or functionality of the solution.
The most important thing to nail early is the Intent (Building the right thing) of the solution, it is pointless building the worlds best escalator if the business really wanted an elevator. A Business Analyst’s role is capture the requirements, the architect’s role is to interpret the requirements and design a solution to meets the implied and stated requirements. It is important that Architects develop a solid Logical view of the architecture to present to the business and project sponsors, so that what is delivered is going to meet their true intention during the inception phase of the project.
Having come from a very technical background, I have spent the last 10 years trying to hone my visual communication skills so that I can effectively and succinctly communicate the various aspects of the solution and strategy to stakeholders at all levels.
Architecture diagraming should focus on the following points
- Simple layouts
- Clean and Tidy
- Consistent colouring and theme throughout.
- Keep it Concise & ask yourself does it provide the information for your intended audience.
- Don’t provide Physical Diagrams to business stakeholders, keep the view focused on what they require to understand.
- Level of abstraction matters, focus on the “What”, “How” & “Where” for the audience, a Architecture does not tell a carpenter how to hammer a nail. The same goes for Developers, Solution Architects don’t tell the developer which framework or software language to use, only what features and functions to develop.
- Tradeoff Accuracy of physical details (or unimportant detail) to get the message across.
To Wrap up, the main point I want to make is, Solution Architecture is taking a set of requirements and developing a solution that fulfils these requirements. The solution needs to be communicated to both the client / customer and to the developers. Therefore the customer understands what they are paying for and the developer knows exactly what they are building. Communication is king and we should spend more time focusing on learning effective communication methods and techniques for communicating with our key stakeholders rather than trying to shoehorn solutions into a modelling language that is only understood by fellow architects.
I will leave you with these final quotes that every architect should strive towards
“Any Fool can make something complicated, it takes a genius to make it simple”
Woody Guthrie
Simple is clever. Complicated just means you haven’t been clever enough to reduce “it” to its essence.
Phil Dourado, The Little Book of Leadership
Andrew Bruce 