Are You Also Calling Your Implementation Models as Digital Architecture? Secrets You Wish You Knew a Year Ago
Sounds demented! Because I am referring to your Architecture Model as "Implementation Model."
Architecture is still an evolving discipline in the context of Enterprise and IT. We have seen great progress in the last twenty years comparison to previous 50 years. In fact, last ten years alone, there is widespread adoption and utilization of Architecture principles in creating and managing systems. There is so much to learn from every framework, best practices, solution models that are available today.
Read this blog and find out if are you also calling implementation models as architecture and hence losing out on real value from Architecture efforts.
John Zachman - Architecture
The Architecture is a structured set of descriptive representations relevant for describing an object and being employed such that an instance of the object can be created and such that the descriptive representations serve as the baseline for changing an object instance.
Here are few reasons why in the majority of the cases, the architecture models are "Implementation models."
1. Almost, all the cases the models are multi-variable, i.e. composites (do you recollect compounds vs. elements in the periodic table). As John Zachman defines- single variable models are Architecture models. There are six variables, i.e. data, function, network, role, time and rules. If a model consists of a single variable type, then it's Architecture model. However, if a model has more than one variable, say a model is having reference to data & function, or other model having a function, data and role references, etc. these are examples of composite models (implementation models). Interestingly, in most cases, models are multi-variable and hence an implementation model. As the number of variables is added to a single diagram, they tend to become less legible and these models more likely to change quickly and become outdated rendering them useless owing to their shorter life span.
2. Often architecture models have references and labels of the actual vendor product names. Such diagrams form a good chunk of the list. This mistake (knowingly or unknowingly) shortens the life of these models, rendering them useless during the system life journey as a basis of change or managing complexity. System life is longer than products & technology being used for implementation. It's important that we separate the logical (system) models from technology (specifications). Also, separate technology (specifications) from technology (implementation). When you have diagrams, which refer to AWS Architecture, or Azure Architecture or Siebel Architecture, you know that you are referring to implementation details and configuration issues than Architecture.
3. You have spent 6-10 months and created 100 plus nice looking, sometimes easy to comprehend but often complex (difficult) to comprehend diagrams and thinking you are done with Architecture. Did you ask yourself how to validate if these 75 diagrams are sufficient for implementation, and change? Why did you create these models in the first place? Do you have a one-page sheet which says this is the use case, so and so stakeholder and that's why this model?
4. Architecture is about creating the anatomy and not X-ray of the anatomy. A composite model has short life just like an x-ray while anatomy lives longer. When you are following a framework and created a set of composite models, soon you realize that all the models have started to lose its relevance as time passes by resulting in huge amount of rework. Eventually, as the system complexity increases, and there is more insight needed, there is little value that you can derive from the models that you had created.
4. By the time the system is operational, most of the models are outdated. How to keep updating your models as things are changing every week / every month. This means that implementation models and operational models have more content than Architecture, i.e. your architecture models are a subset. Isn't the irony? Your implementation models have more information than your Architecture models? That means your Architecture is inside your implementation details? So, if someone wants to understand the system architecture, they don't have enough models to look at as a basis of change, but keep doing the reverse engineering to know what's there. Do you know the various modelling representations like BPMN Models and UML models (Use cases, Activity diagrams) are all multi-variable (composite models)?
5. Sometime operational models (i.e., how exactly system is operational using other systems and technology are being called as Architecture rather than describing the logic (basis) for the same.
6. Almost all the ideas and things which have a suffix or prefix “framework” are basically composite models by design i.e. multi-variable models and not the single variable models. This include FEAF, DODAF, RM-ODP, Gartner EA, Forrester EA, Microsoft EA, RUP / 4+1, EUP, Balanced Score Card, ComVantage etc. etc. Further, all these framework mandates certain number of “models” to be created without realizing that those models are insufficient, incomplete and inconsistent in terms of supporting six variables (what, how, where, when, who, why) and six perspectives (identification, definition, representation, specifications, implementation/configuration, instantiation).
Example of Architecture vs Implementation models
1. If you are discussing optimizing data transfer, it's technical specification (a subset of Architecture models), but if you are referring to how Amazon Direct Connect works, it's implementation details and not Architecture for someone who plans to use that service
2. Modeling cloud bursting and a hybrid cloud to support various use cases will result in Architecture models. But, when you create the above models and inject the labels specific to Azure or IBM or Amazon Hybrid Cloud solutions, these models become implementation models. Of course, these implementation models are useful. But, they are not Architecture models.
Remember no one calls a compound (which is very useful say Dart for Headache) as an element and put inside the periodic table? Isn't it?
3. When you are modeling CRM and related Functionality, you are creating CRM Architecture models. But, if you are referring to how does Salesforce supports various CRM functionality, and you have models containing the Salesforce specific labels those models are implementation models.
What is Architecture of ”Solution” vs Architecture of “Raw material” and how does it work?
This is significant but it's easy to understand. Imagine how does it happen in Civil engineering world. If we need to construct a 50 storeyed building, you get the Architecture models. Then choose the raw material such as cement, steel, etc. The Architect of the 50 Storeyed building is focussed on the Building's Architecture (i.e. definitions, representations, and specifications for multiple stakeholders and concerns) and allows the contractor to choose implementation raw material such cement (Lafarge, Holcim, UltraTech), etc or Steel (ArcelorMittal, Nippon Steel etc.).
Please remember the architecture of the raw material say Steel or Cement is a different concept than the architecture of the building.
Similarly, Architecture of your Software System is different from Architecture of the software raw materials that you plan to use for implementing your software system. Unfortunately, raw material suppliers (Amazon, IBM, Microsoft etc. would like you to believe that if you buy their raw material, your System Architecture will come for FREE.
To become a successful Architecture of Solution vs Architecture of Raw material needs different skills. It's not about right or wrong, it's just that they are different skills.
It's easy to remember that the Architecture of Aircraft is a different problem than Architecture of Airlines business.
Do you know now why your systems are turning legacy faster?
Yes, you guessed it right. Actually, Architecture of your system was never created in the first place. You just had some random set of implementation details (models) supplied by your software and hardware raw material suppliers and you thought you have ARCHITECTURE in place because it had English word ARCHITECTURE written on it.
Architecture models are single variable model while implementation models are the multi-variable composite model. And you had so many of later ones. That means your Architecture was inside your implementation details? and that’s why instead of saying “implementation” needs to change, we keep hearing Architecture needs to change. The elements of the Periodic table don’t change.
Similarly, architecture elements don’t change. What changes is the composite models (implementation models). We can create multiple implementation models from same set of architecture elements
Summary
All the frameworks only reflect maturity of individuals / groups who have authored the framework. It’s pretty much like in 1800 century, everyone had an idea of chemical compounds. But, thanks to Mendeleev’s periodic table, it provided a consistent and complete definition resulting in its wide spread utilization in almost every industry.
But I guess analogy to Human anatomy is more suited for Enterprise and IT systems. We can compare out situation with the medical practise of 1700 and early 1800 centuries. Every practitioner had their own understanding of what constitutes human body. It’s pretty much like our current situation in the Architecture, every practitioner defines what it is. Please do remember, the organs and organ systems are not created by doctors. They already exist.
When the medical practitioners realized that all humans have a common anatomy (thanks to Mark grey and his team) It fundamentally altered the way human dis-orders were treated, resulting in increasing the life expectancy in USA from 40 years in 1900 to 90 plus years now.
Isn’t longevity the core issue for systems and enterprise today? There is clear separation from the idea of Anatomy and X-ray needed to answer questions and solve issues. Interestingly, there is no debate anymore that every human has one anatomy, actually all humans have a common anatomy structure. All the Enterprise have a common Enterprise Anatomy structure. That's why Enterprise Anatomy is the basis for Digital Architecture. And Digital Architecture is the key to Digital Enterprise.