by Marc Lankhorst & Rob Kroese
on Apr 18, 2018
The architectures of large 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
Onekey tipto streamline work on large architectures isto organize your modelrepository bybusiness 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 federatedarchitecture governance structure. Managing it all from one large, centralized architecture department is usually nota good ideafor two reasons.First, the effort required will be substantial, creatingan overhead that will be seen as unreasonable by the bean counters.Secondly, andmore importantly, these central architects will often be too far away from thebusiness in question to really know what is going on.
It is therefore much better to havelocal architects within the different business domains.These architectscoordinate their workwitharelativelysmall central group of architectswhoensurethattheseefforts fit togetherandwho definecommonalities(i.e.reference architectures, technology standards,etc.).This pattern also fits with our earlier recommendation toestablish an‘editorial board’that ensures your architecturemodels conform to a set of commonmodelingstandards.
Organize your architecture projects
In large architectures, you typically won’t work together on the entire architecture with all architectsat the same time. Rather, different groups will work ondifferentparts of the architectureandonly share their results when they are ready for wider distribution.
This typical two-stage change process is supported byBiZZdesign’steam platform.Project teams work together on one or more models that are part of amodel package.Within aproject, individual architectsfrom that teamcan commit their changesto these models, which are then only shared within their team, not with others.
When this team is ready, someone with therequisite permission level(‘lead designer’)can make their contributions available to everyone who collaborates on thatsame model package.Only then can others see these changes.Typically, there willalsobe some form of review before this step is taken.This way, a project team can work on their own ideas without confusingor disturbingother users of that same model package.
Use self-service and automated quality control
When you work with a large group of people together in onemodel repository, the challenge tomaintainhigh modelqualityacross the board gets even more difficult.A good practice is to define a set of quality requirements forall the modeling workforthe architectstouse. A couple of examples are:
No unused elements:Elementsthat are not linked to other elements and are not present on any vieware possibly unwanted
No duplicate objects:Makesure 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 drawnnested objects on a view, there are also relationships defined (typically composition or aggregation) between parent and child objects.
BiZZdesignEnterprise Studio has built-in mechanisms toprevent these situationsfromhappening,andyou canalso check onthese situationsafterwards.Architects can use these mechanisms as self-service, whichhelps to create models ofhighquality.Modelersshould be encouraged to usethese kinds of mechanisms.
However, in large repositories,itcan bevaluableto use automated quality controlfeatures as well.It is possible to define automated scripts that check on more detailed quality requirements, such as:
UseofArchiMate elements:Often,a subset of the full ArchiMate language isused to keep the architecture models easy to read.An automated check can produce a report that lists elements thatare 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 elementswill output a report with all relationships that are possibly of the wrong type.
These kinds of automated checkscan be executed periodically andwill 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.Allofthis helps togenerate strongerawareness ofthe 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?Attendone of our webinars, meet us at anevent,request ademo,or get in touch for more personal advice.
SUBSCRIBE TO BIZZDESIGN'S BLOG
Join 10.000+ others! Get BiZZdesign's latest articles straight to your inbox. Enter your email address below: