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.
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.
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.
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:
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:
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.