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 the following pages, we’re going to share our top 6 ways to organize your architecture models. These methods should help you keep your models neat and tidy, while also supporting better outcomes for your strategic initiatives. Let’s see what they are..
1. ORGANIZE YOUR MODEL REPOSITORY BY BUSINESS DOMAINS, INFORMATION DOMAINS AND TECHNOLOGY STACKSIn large organizations, you will need some substructure for your integrated current-state model. You can organize your capabilities, business functions and business processes 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 you can organize according to information domains, consisting of:
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. Figure 1 at the top shows an example of this.
Two other model categories are 1) external reference models and 2) standards. For instance, the BIAN standard for the banking industry or the ISO/IEC 27001 security standard shown in the figure below describe your way of working, including your:
2. SEPARATE CURRENT- AND FUTURE-STATE MODELSIt 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. As 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 these services. Only once that is complete 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 (e.g. components, systems, products etc.), especially early on in the design process.
3. SEPARATE MODEL CONTENT FROM VIEWS OF THAT CONTENTIn 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 instance 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.
4. DEFINE NAMING AND OTHER MODELING CONVENTIONSTo be able to find anything in a large-scale model, you must know what to look for. In plain language, you will need to know what things are called – and how they’re labeled – in your model. This is why defining clear naming conventions is essential. Different organizations will have their own specific naming schemes, so no universal convention applies to all situations. Nevertheless, here are common tips that may help you create your naming process:
5. SET UP AN ‘EDITORIAL BOARD’To create collaboration in large, federated organizations, you cannot rely on simple top-down control from a central department. There must be room for local variance simply because, in large organizations, no standard will fit all situations. Nevertheless, you do need to coordinate between different departments and domains to ensure their ways of working are compatible, and to share and benefit from each other’s experiences so you can build up your own library of organization-specific best practices.Working with such large and complex organizations, I have seen that it is often helpful to create a kind of ‘editorial board,’ composed of representative architecture and modeling experts from different areas of the organization. They can find shared ways of working and other commonalities across your architectures (such as the modeling conventions and structuring mentioned previously), and they can coach their less experienced colleagues in applying these practices to promote high-quality models.
However, an ‘editorial board’ is different from your typical architecture board, which decides on the architectural content itself. Rather, this editorial board supervises the way architectures are modeled and described. These are two distinct competencies: A good architecture may be badly documented, and poor architecture may be well-documented. Make sure both are well-done.
6. DEFINE CLEAR RESPONSIBILITIES, ACCESS RIGHTS, USER GROUPS AND PROCEDURESIn any large-scale organization, you need to be clear about who does what and who has access to which materials. If everyone can edit anything in your architecture models, you can guess what will happen. Things may get moved or entire models may be deleted. In general, I would not advocate hiding parts of the architecture from view (unless for specific security-related reasons). Architects should be trusted to see the work of their peers and make good use of that. However, you will likely need to limit write access to the people who have a defined role in creating or updating models. Otherwise, your models will quickly become a mess.One way to do this is to organize the work on your future-state architectures in projects, each with their own specific models, as described above. Project teams have the right to change their project models, but their results are only published to the wider architecture repository when they are sufficiently ready, as decided by a lead architect or decision maker within the organization.
Culled from https://modernanalyst.com/Resources/Articles/tabid/115/ID/5246/6-Ways-to-Organize-Your-Architecture-Models.aspx