Adaptive Enterprise Architecture: Towards a model (Category Architecture)

Recently, I decided to read whitepapers on enterprise architecture and came across article Scientists from Morocco, where they are trying to cross the hedgehog with the already, or rather corporate architecture with scrum:) At the beginning of the article, the authors note that current approaches to corporate architecture (TOGAF, Zachman) They do not have the flexibility to handle the rapid, multi-level changes that characterize today’s fashionable digital transformations. They focus on reactive processes that focus on filling out a pile of documents and are difficult to manage unforeseen changes. Next, the authors decide to formulate a set of criteria for an adaptive corporate architecture, which includes such things as: 1) Support multi-level dynamics (Support for multilevel dynamics) Changes occur at different levels and at different speeds, which means that the architectural process must be able to work with each type of change. The authors note that the standard approach with as-is and to-be architecture is no longer static, but undergoes various changes, which must be taken into account in architectural processes. 2) Sensing of change (feeling) The process should maintain a sense of change and allow you to plan your initiatives to adapt to the change. n 3) Process of adaptation (adaptation to new needs) This is a key part of the authors’ approach called adaptive enterprise architecture. 4) Complexity of change management (complexity of change management) TOGAF and Zachman are failing, and they want an approach that’s a lot easier in terms of change management. 5) Handling of unforseen changes (handling unexpected changes) It is necessary for modern corporations that are facing a high rate of unforeseen changes in their business environment. 6) Explicit management of adaptability trade-offs The authors note the importance of explicitly managing trade-offs on adaptability to change. Now it is often just one of the non-functional requirements or attributes of the quality of solutions, and in the new approach they need to be controlled clearly. 7) Evaluation of adaptation (adaptation) To manage adaptation, we need to be able to measure it, and we need metrics within the process of corporate architecture.

Further, the authors compare different approaches to corporate architecture according to these criteria and it turns out that all of them do not meet the criteria. They combine approaches into groups.

1. Approaches based on guidelines (Zachman, TOGAF, Koffi A.D, LEAP, DYA)
2. Integration oriented approaches (Shmidt R & al, Zimmerman A & al)
3. Co-evolution oriented approaches (DEEVA, ACEM, ...)

And then the authors decide to offer their own approach, which meets the criteria and relies on time-tested agile approaches, or rather Scrum. Next, they talk about how wonderful Scrum is, and then they pull it on the architecture.

1. We have the role of architecture owner, business/IT owners. The former is responsible for strategic alignment, while the latter is responsible for optimizing business processes and technical solutions.
2. Work proceeds in cycles on 2-4 weekly cross-owner syncs, architecture reviews to provide feedback
3. There is an architectural backlog that prioritizes changes to corps architecture, and there is also KPI and As-Is/To-Be motion tracking on graphs. All other agile rituals about the relationship between business and IT remain in place, just EA beclog and rituals of adaptive corporate architecture live nearby.

To me, this whitepaper felt like pulling an owl on a globe without much explanation as to how it would work in practice rather than on paper:)

#Architecture #Software #Management #Governance #Engineering