Layered architecture models are outdated
Jan van Bon
Reduce your organization's complexity with ?????? ?????? ???????????? for a customer-driven ???????????????????? ?????????????? ???????????????????? ????????????????: a unique proposition for sustainable service delivery
Layered models are extremely popular in the world of architecture. This started with PRISM in 1986, and was followed up with Zachman (1987), and NIST (1989). In 1993, the Strategic Alignment Model (SAM) of Henderson & Venkatraman and the BDAT model of Spewak ?sparked a tidal wave of similar models, including C4ISR (1996), TOGAF (1995), TAFIM (1996) FEAF (1999), TEAF (2000), DoDAF (2003), and FDIC (2005). This ended with the latest versions of the most popular architecture models such as TOGAF 10.
The BDAT stack is the common factor in most models of the last four decades of creating layered architecture models. Most versions of the model include layers like Business, Organization, Information, Information System, Data, Application, and Technical Infrastructure, in various orders.
These layered architecture models mainly help you analyze aspects or individual components of the system (check TOGAF), they do not help to reproduce the system itself and make it (more) governable. The models do not enable you to develop the management system with which you control the analyzed components, in a reproduction of that reality.
Most of these models are actually matrix models, which link their layer axis to a perspective or aspect axis. E.g., the Zachman model shows this on the horizontal axis:
1. What: Data and information.
2. How: Function and processes.
3. Where: Network and locations.
4. Who: People and roles.
5. When: Time and events.
6. Why: Motivation and goals.
These clearly are not components that can be placed on a single axis, suggesting that they are representatives of the same dimension.
Because of the pragmatic choice of the perspectives or aspects used on the vertical axis, these architecture matrix models are rather arbitrary: they follow the author's selection of perspectives: what the author considered important at that moment is reflected in the model. For example, some of these models have a "security" component - for the simple reason that we consider it an important issue today. However, security is only one of many dozens of non-functional characteristics of a system (check ISO25010). In the early 1990s, "capacity" was an important aspect: a characteristic we can hardly find today for the simple reason that capacity no longer creates the core bottlenecks. Zachman's model uses Planner, Owner, Designer, Builder, Subcontractor, and Enterprise perspectives, the SABSA model uses Contextual, Conceptual, Logical, Physical, Component, and Operational perspectives, and Weil & Ross used Business monarchy, IT monarchy, Federal, IT duopoly, Feudal, and Anarchy for their archetypes.
These layered architecture models are primarily based on hierarchical decomposition, and the components are not positioned in a holistic perspective as a system. Yet, all realities are systems. The conclusion must therefore be: layered architecture models do not lend themselves for a holistic description of reality. Instead, you’ll need a system model for that holistic approach. The components of the layered architecture models will then find a position in this system model, based on their relationships – which puts them all in a shared perspective.
In event 3 of the USM Revolution series of webinars, the USM Panel will discuss that holistic system from an architectural perspective, on September 17.
In event 2, on August 20, the Panel will discuss the concept of a ‘service’, the core product of any modern organization. This should be at the center of each enterprise architecture.
The recording of event 1 is available at YouTube.
Entrepreneur | Low Code Expert | Solution Architect | Trainer | Researcher
3 个月I do agree with the primary statement. However, this article lacks some much needed nuance. For example, the statement 'layered architecture models are primarily based on hierarchical decomposition' needs much more elaboration. In my opinion, although the terms layers is used often in architecture models, they should be much more considered as perspectives on a system. In my understanding from USM, USM defines it as not much different. The biggest challenge however is to connect different perspectives, or layers, or whatever you call them. The main challenge lies in connecting modeling languages for different perspectives (e.g., BPMN, UML class, ORM, ...), or to define a new language to cover them all. Luckily we have #DEMO that already explains the core concepts in different perspectives (product, process, information, business rules), and comes with model concepts and symbols that integrate the whole. It puts products before services, where a service (or transaction) delivers the product. In that sense it is not much different from #USM. The only problem is that currently #DEMO, deliberately!, leaves out implementation aspects in terms of human beings, software and hardware. Other initiatives to integrate perspectives is HAL
Enterprise Architect R&D at BASF - NOT a landlord
3 个月Jan van Bon , how does USM relate to DEMO (as in Design and Engineering Method for Organizations)?
Andy Hoegner, ich glaube das kann für dich interessant sein!