Updating the Model

I believe that creating static charts may not have the impact we desire for Enterprise Architecture. Today, infrastructure often changes with the update of a configuration file (infrastructure as code). Additionally, traditional architecture views are less relevant as organizations increasingly acquire major applications as Software as a Service (SaaS), implementing the architectural principle of “reuse before buy before make.”

However, questions arise: Are we progressing in the right direction? Are we not only doing things well, but are we also doing the right things? Generally, a more strategic perspective is needed.

This strategic view must be based on data associated with the objects we are modeling. To present this data, we could utilize the annotation techniques discussed in the previous story.

I believe there are use cases where a view containing annotations will be reused over time, and in such cases, automated updates of the annotations would help maintain an overview of enterprise development.

In this final part of the series, we will explore options for actual updates to the model.

What Does Not Work

  • Using the .csv export of the model. The annotations are not included.
  • Using the Open Exchange File. Annotations are also missing here.

What Could Work

  • Reading the current ArchiMate file, updating it, and writing a new file with the changes. The annotation objects are present in the ArchiMate file.

There are significant drawbacks, particularly the close coupling of the reader/updater to the internal file format of ArchiMate. However, since the ArchiMate file is a ZIP file containing an XML file we need to update, this approach could suffice for a proof of concept (PoC). If valuable, we can later develop a better API-based solution.

A cliffhanger detected: there will be a sub-article presenting the PoC.

Coining the Term ArchDevOps

This approach, where models are updated from the environment, requires writing code to retrieve data from other systems. For example:

  • Retrieving headcount from HR systems.
  • Retrieving the number of instances for Architecture Building Blocks.
  • Retrieving the number of projects running on specific Software Building Blocks.

Many other data points could also be useful, including creating graphs and incorporating them into an annotation block.

Ultimately, some code must be written and executed, and the most straightforward way to achieve this is through a DevOps approach. This leads us to the term ArchDevOps, a method of working where Classical Architecture work is combined with modern DevOps practices.