6 Ways to Organize Your Architecture Models (Part 1)
Mar 22, 2018
If you have some experience in modeling real-life, full-size architectures for large-scale organizations – preferably in the ArchiMate language, of course – you have likely come across the challenge of organizing your models in logical and manageable ways. In this two-part series, we’re going to share our top 6 ways to organize your architecture models. These six methods should help you keep your models neat and tidy while also supporting better outcomes for your strategic initiatives.
In large organizations, you will need some substructure for your integrated current-state model. The capabilities, business functions and business processes can be organized by business domains or high-level business capabilities. That is a natural subdivision of the business world, both easily recognized by the people involved and the typical responsibility and authorization structures in your enterprise.
The application and data part of your model repository can be organized according to information domains, consisting of:
For example, you might have an information domain for Customer Data, comprising the relevant personal data you capture on your customers and the applications used to store and process it (e.g. CRM systems). Another information domain might be Customer Interaction, where you might find call center and social media applications, for example.
For the technology part of the architecture, a business-oriented structure often makes less sense, as much of the technical infrastructure of an enterprise cuts across business or information domains. Instead, organizing by technology stacks makes more sense in many cases. These stack models can then be managed by separate teams with the requisite technology expertise.
Setting up a navigation page to help people find their way around this structure is also very useful. The figure below shows an example of this.
Two other model categories are 1) external reference models and 2) standards. For example, the BIAN standard for the banking industry or the ISO/IEC 207001 security standard shown in the figure above describe your way of working, including your:
Having these accessible in the same repository is very handy. Of course, there may be cross-cutting and overlapping aspects to these domains. To sort these out, you need to set up regular coordination between the experts involved, preferably supported by a collaboration platform that allows you to set the right permissions, create review workflows and otherwise organize the work to be done. Our Enterprise Studio and HoriZZon products offer tools that support this aspect of architecture modeling.
It is important to make a clear separation between what you have described about the world as you know it is today and the future that you envisage. Facts about the present and ideas about the future should be clearly distinguishable in your architecture models.
One way to do this is to create a read-only, integrated reference model of the current state (possibly per domain, as described above) and separate project-level models that describe aspects of the future as it is being designed. The visibility of these future-state models is limited to the specific project team working on them so people do not get confused by the work being done on future-state designs. Within these future-state models, elements of the current state that carry over into the future can be reused. Once the time has come to put the project results into production, the future-state models will become reality and will transfer into the integrated current-state model.
It’s important to note that the process for creating these models is very different. When describing the current state, it is often easiest to start with what is called ‘structure’ in the ArchiMate modeling language: the organization, applications, software platforms and devices that are readily visible in your enterprise. From there, you can look at their behavior: the processes, services and functions provided by these structure elements. In a next step, you might then look for commonalities and opportunities for synergy or rationalization, just as an example.
When designing a future-state architecture, however, you will often work the other way around: first you define the services you require to solve your business problem, then you outline the processes and functions that need to provide the services. Once that is complete, only then do you decide on the structure elements that will perform this behavior and deliver these services. This avoids the common trap of constraining your possible design solutions by the structures you know (i.e. components, systems, products, etc.), especially early on in the design process.
In architecture modeling, it is important to distinguish the content of your architecture from views of this content that address specific stakeholder concerns, by visualizing part of the content in a suitable manner. The same model elements may appear in different views; vice versa, all views share the same underlying content.
Typically, you organize the model content according to the types of elements you have modeled, for example using the layers of the ArchiMate language (motivation, strategy, business, application, technology, implementation & migration), or even more fine-grained by defining separate collections of business processes, application components, et cetera.
The views on that content are best organized according to the types of stakeholders you address, with views for groups like business managers, process designers, application owners, data stewards, project managers, system administrators, and so on.
More architecture model organization ideas
In the next part in this series, we will address naming and modeling conventions, as well as discuss structures for governance and quality assurance of your models. Stay tuned!
