Supporting Large Architectures as a Team

Apr 18, 2018
Written by
Marc Lankhorst
Marc Lankhorst
Rob Kroese
Rob Kroese

Supporting Large Architectures as a Team

Large architectures of big organizations can become quite large and complicated, posing a challenge for the architects developing and maintaining them. In previous discussions, we have addressed a number of techniques for organizing and controlling such large models to keep things manageable. In this installment, we look at the processes and practices you can use to optimize the collaboration between the people working on these architectures. 

Federated architecture teams

One key tip to streamline work on large architectures is to organize your model repository by business domains or high-level business capabilities. This subdivision is easily recognized by the people involved and aligned with typical organizational hierarchy and division of responsibilities.  

Correspondingly, you can set up a federated architecture governance structure. Managing it all from one large, centralized architecture department is usually not a good idea for two reasons. First, the effort required will be substantial, creating an overhead that will be seen as unreasonable by the bean counters. Secondly, and more importantly, these central architects will often be too far away from the business in question to really know what is going on.  

It is therefore much better to have local architects within the different business domains. These architects coordinate their work with a relatively small central group of architects who ensure that these efforts fit together and who define commonalities (i.e. reference architectures, technology standards, etc.). This pattern also fits with our earlier recommendation to establish an ‘editorial board’ that ensures your architecture models conform to a set of common modeling standards. 

Organize your architecture projects

In large architectures, you typically won’t work together on the entire architecture with all architects at the same time. Rather, different groups will work on different parts of the architecture and only share their results when they are ready for wider distribution.  

This typical two-stage change process is supported by BiZZdesign’s team platform. Project teams work together on one or more models that are part of a model package. Within a project, individual architects from that team can commit their changes to these models, which are then only shared within their team, not with others.  

When this team is ready, someone with the requisite permission level (‘lead designer’) can make their contributions available to everyone who collaborates on that same model package. Only then can others see these changes. Typically, there will also be some form of review before this step is taken. This way, a project team can work on their own ideas without confusing or disturbing other users of that same model package.  

Use self-service and automated quality control

When you work with a large group of people together in one model repository, the challenge to maintain high model quality across the board gets even more difficult. A good practice is to define a set of quality requirements for all the modeling work for the architects to use. A couple of examples are: 

  • No unused elements: Elements that are not linked to other elements and are not present on any view are possibly unwanted 
  • No duplicate objects: Make sure that, from every element, only one unique instance is available in your repository and don’t create duplicates 
  • Relations between nested objects: Make sure that, if you have drawn nested objects on a view, there are also relationships defined (typically composition or aggregation) between parent and child objects. 

Enterprise Studio has built-in mechanisms to prevent these situations from happening, and you can also check on these situations afterwards. Architects can use these mechanisms as self-service, which helps to create models of high quality. Modelers should be encouraged to use these kinds of mechanisms.  

However, in large repositories, it can be valuable to use automated quality control features as well. It is possible to define automated scripts that check on more detailed quality requirements, such as: 

  • Naming conventions: Define naming conventions (like we discussed in ‘6 Ways to Organize Your Architecture Models Part 2’) and create a report with a list of elements/views that do not adhere to these conventions. 
  • Use of ArchiMate elements: Often, a subset of the full ArchiMate language is used to keep the architecture models easy to read. An automated check can produce a report that lists elements that are not part of the agreed-upon ArchiMate subset.  
  • Use of ArchiMate relations: in the full ArchiMate language, a lot of different relationship types are allowed between different element types. It is a good practice to standardize in your organization the use of relationships. For example: always use a Realization relation between an Application Component and an Application Service. A check on the use of the agreed upon relationship types between all different elements will output a report with all relationships that are possibly of the wrong type. 

These kinds of automated checks can be executed periodically and will generate a report in which possible quality issues are listed. Also, the numbers of issues that are present in the model can be shown in dashboards. All of this helps to generate stronger awareness of the quality of the models and make improvements, which is essential in large architecture repositories.  

Do you want to know more about these advanced features of Enterprise Studio? Attend one of our webinars, meet us at an event, request a demo, or get in touch for more personal advice.