Can any framework pretend to be a Silver Bullet for complex change or do we need architects that can apply even the most well-thought-out framework “a la carte” judiciously? Well, we are approaching the end of 2022 and after viewing the new Avatar movie,–this sequel still sharing the message that humanity that can be a positive or detrimental force for our planet–I am going back to John Gall’s book “Systemantics: How Systems Work… and Especially How They Fail,” published in 1978.

It’s a very good read for those who want to explore “how complex systems fail “ and to derive important lessons to help us better apply some better success patterns. If you have ever experienced large transformations planned to be delivered in long gated waterfall life cycles, then you are likely aware of the risks of such an approach.  On the other hand, an iterative approach can help remove a lot of that risk. This is because it is performed in short learning cycles that give an opportunity to progressively explore and build up your understanding of the context and the workings of complex digital ecosystem.  Each iteration is completed by the process of retrospective, where Agile Team members discuss the result of each iteration, review their practices, and identify ways to improve.

Each retrospective yields both to quantitative and qualitative insights. However, complex digital ecosystems are not built by only one individual team; a team of teams approach is essential to scale just an iterative practice. In this context, The Scaled Agile Framework (SAFe) recommends that we use an inspect and adapt technique, a significant event held at the end of each program increment (PI). In it, the current state of the solution is demonstrated and evaluated by the Agile Release Train, many teams working together on a solution. They reflect and identify improvement items via a structured, problem-solving workshop. Is such an approach enough, though, to tame the making or transformation of complex systems?

Unfortunately, SAFe does not demonstrate enough value in the practice of enterprise architecture because it narrows EA’s role to establishing a technology strategy and roadmap that enables a portfolio to support current and future capabilities (aka business functions). I purposely mentioned “complex digital ecosystem” in the second paragraph above instead of the term “enterprise.” This is because many enterprises that we can see as a system or system of systems are striving toward a digital enterprise model.  This model is not only digital in the sense of being supported by digitized data and information; instead, it is a model where humans as individuals are still doing R&D, running operations, delivering goods and services, thus leaving us with similar challenges in adaptation and change management.

If we consult SFIA 8.0 competency model, we can see that EA is about:

“The creation, iteration, and maintenance of structures such as enterprise and business architectures embodying the key principles, methods and models that describe the organization’s’ future state, and that enable its evolution. This typically involves the interpretation of business goals and drivers; the translation of business strategy and objectives into an “operating model”; the strategic assessment of current capabilities; the identification of required changes in capabilities; and the description of inter-relationships between people, organization, service, process, data, information, technology and the external environment. The architecture development process … facilitates change in the organization’s’ structure, business processes, systems and infrastructure in order to achieve predictable transition to the intended state.”

The agile requirements model is using elements such as epics, enablers, features, stories (from the general to the specific; it appears to be attempting in this way to tame the complexity of requirements management, starting from stakeholders concerns and leading ultimately to elicitation of their functional requirements. However, the Agile requirements mode ignores the need for ontology, expressed by the metamodel elements and their relationships, and specific needs of various categories of stakeholders with different perspectives on our enterprise in accelerated transformation. To tame this kind of complexity, iteratively and progressively through learning cycles, we can express it as a set of views. These views are developed iteratively, leading first to high level, simpler intentional architecture along with emerging design, provided by both agile teams and architects working together. This process is increasing our chances to build more complex systems than can work.

We rarely create a complex system like an enterprise or other large systems from scratch; instead, we transform them. Therefore, a cross-disciplinary and iterative transformation process is key. The transformation process orchestrates sequences of viewpoints depending on the type of transformation scenario and in an agile fashion. An example of such a process is defined by a uniquely comprehensive method/framework called Labnaf. Using precise systems semantics, it semantically merges and refines more than 20 standards and best practices in a single transformation process, metamodel, modeling language, and tool. I strongly encourage everyone to visit https://labnaf.one to better understand the massive undertaking labnaf represents to better enable even the most complex change in a holistic fashion. In short, it is a method comprised of many other methods in light of the end-to-end challenges of change.

To conclude, I recommend that everyone keep in mind John Gall’s practical principles of systems design based on experience and anecdotes, offered from the perspective of how not to design systems, based on system engineering failures. The primary precept of his treatise is that large complex systems are extremely difficult to design correctly despite our best intentions. Therefore, care must be taken to design systems through the scoping of  incremental functionality to be delivered based on close and continual contact with user needs with outcomes describable with clear measures of effectiveness on the way to even something very grand.

Authored By Alex Wyka, EA Principals Senior Associate and Consultant