Tip 1: Use a standard modeling method, tool, and repository
Architecture comes in many forms and visualizations. Process models, data models, ArchiMate models and even cartoons and movies are used in many an organization. All of these forms of visualizations can add value but you need to ensure you use a standard modeling language whenever possible.
Examples include BPMN for process models, ERD/UML for data modeling and ArchiMate for architectural modeling.
Modeling with a standard modeling language has the concrete advantage of enabling unambiguous communication about a design and its review. Tooling is also available that facilitates modeling and supports the management of the information and models.
Often it is possible to create a “repository” in it. A repository can best be described as a central place where architectural information and models are stored. It is then possible to record the relationship between the business, applications, data and technical infrastructure. How useful.
Tip 2: Describe ‘just enough’ architecture
A model is a schematic representation of reality, and it is tempting to represent everything about that reality and if the reality is complex and unruly, so will be the model.
A good maxim is don’t describe the whole world, but “just enough” for insight, compliancy and decision-making. With that, the architecture contains just enough information so that it provides insight into the (complexity of the) current situation and that it can guide changes in the organization.
For this reason, it is good to determine in advance what will and will not be recorded. This can be done by establishing an organization-specific metamodel. This is often based on a metamodel that comes along with the chosen modeling language. For the ArchiMate modeling language, the metamodel can be found here. In general, most organizations need the following type of information.
Business architecture:
- Processes (business processes, work processes and process steps)
– Actors and roles
– Services and or products offered
– Business functions
Application and information architecture:
- Applications (and per application: the owner, vendor, end of contract date and cost – Total Cost of Ownership (TCO)
– Data (and for each data object the Availability, Integrity and Confidentiality classification, the owner of the data and the source system of the data)
– Linkages between applications where an understanding of the technology of the link and the data being exchanged emerges
Technical infrastructure:
- Servers (application, database, and license servers)
– Network and domains
– Software versions (Windows 20XX, Oracle XX)
Of course, capturing more information is possible, but note that architecture provides insight into the interconnectedness of things. It is not a means to make detailed (technical) designs and or to register incidents and problems. It is never intended to replace a CMDB (Configuration Management DataBase). Therefore, architecture does not contain all detailed information.
Tip 3: Collect information from different angles
Rarely can all information be found with one person or in one source. Gathering information about the business, applications, data and technical infrastructure is therefore the talk of multiple officers and or roles, each with their own (domain) knowledge.
Think of business managers, process owners, functional managers, technical managers but also suppliers and third parties. Sources such as management documentation, a CMDB and a service management tool can also help gather information.
Tip 4: Establish management of architecture models
Once the information has been extracted, clustered, modeled and visualized, it is important to keep it up to date. This also applies to the architecture models and or the repository. Therefore, make agreements about the management of the architecture models.
This can be done by going through the architecture model every month with functional and technical administrators, change managers and or process owners to discuss the changes. In doing so, an architect is responsible for maintaining an up-to-date, reliable and complete (ABC) repository.
Summary
By applying the above tips, a business-critical process can be dissected in a few days, providing insight into the process, the actors, the supporting information, the data being captured and the underlying technical infrastructure.
