Architecture modelling guidance

Who will be using the answers or consuming information provided by the model? The number 1 principle with modelling is to model with a purpose.

The purpose of a model, or a model viewpoint, must be clearly understood before a model, or the model viewpoint, is produced. There are many models and many more model viewpoints documented as being useful by organisations such as The Open Group and their Architecture Framework (TOGAF).

This helps the modeller understand what they could do.

It does not tell the modeller what they should do.

The modeller has to first ask themselves why they are developing a model, and then consider the following questions:

• Who will be the audience for the model?
• What questions will the model provide answers / information for?
• Will a model meet the audience needs?
  • Is the notation something the audience will easily understand?
  • If not, what will the audience readily understand? In some cases the model is used by the modeller to prepare alternative collateral for the audience in a form they can understand.
• At what level of detail do the audience want the questions answered or information provided?
  • How deep and detailed does the model need to be?
  • How broad does the model need to be?
• Does the model need to be maintained once the answers are provided?
  • If the model has ongoing value, who will maintain the model?
  • Are processes in place to trigger updates to the model?

Too much detail can confuse and obstruct meaning. Unnecessary detail can affect cost, delivery and the maintenance of models (where they need to be maintained).

For example, enterprise architecture modelling should be at higher levels, have a broad scope, and not be too detailed. Understand when the model stops being enterprise architecture and becomes something else.

If you need a more detailed model, the modeller may create a solution architecture model that has a narrower scope but considerably more depth, particularly the deployment view used to implement the solution. Some consider that once the solution is implemented this detail should be moved to an “uber” integrated model repository, however synchronisation and alignment between the various models can be problematic. Consider other approaches such as updating the enterprise architecturally-significant elements to reflect the changes, and maintain the detailed model as part of the “as built” documentation.

The expression “getting lost in a model” is more likely to happen to the modeller than the audience for the model. A modeller needs to keep in mind Principle 1: Modelling for a purpose when having fun with it (it can be enjoyable as it’s a form of exploration, the diagrams appeal to creative people, and the structure appeals to logical detail-focused people).

The elements and relationships in a model are important, as is providing views of the model through diagrams and generated documentation and reports. Modellers may consider alternative tools to create time consuming diagrams such as visualisation tools like Kumu, or reporting tools that can provide a dashboard view.

An enterprise architecture model, and any associated models and viewpoints, is not a technical configuration management database (CMDB). A modeller attempting to maintain these details as part of an enterprise architecture may create a bottle neck and lose their focus on Principle 1: Modelling for a purpose.

It is possible to model the technologies and their supporting infrastructure in a modelling tool. There are good reasons for this such as traceability and maintainability, but this is probably solution design not enterprise architecture.

If your organisation does not choose to invest in a technical CMDB capability, the modeller should avoid trying to turn the enterprise architecture into a technical CMDB. A proper CMDB capability would normally include automated discovery tools and agents that monitor and populate the CMDB with the current configuration, and have the appropriate processes and resourcing.

Ideally, when needed for an enterprise architecture model the required level of technical detail could be copied across from a CMDB.

When using modelling tools the vendor has made every effort to make their products meet the majority of their market’s needs. Where your organisation appears to have a unique concept, explore and learn more about the default configuration and capabilities of the modelling tool as this will often reveal an equivalent means of representing the concept or relationship.

While customisation can meet the immediate specific requirements of the current stakeholder, in the long run, as personnel change, this can make the models hard to understand and maintain. In many instances highly customised modelling efforts have not survived the departure of the expert who made the customisation.

Standardised notations

Ideally we use standardised notations that have widely available expertise and information on how to use them. Making up a custom notation comes with a lot of baggage in terms of support, documentation and training.

Standardised notations usually have discussion forums on social media platforms such as LinkedIn, and have standards bodies that develop and govern changes to the notation across the international community of interest. Joining these bodies is one way to get further insight into a notation, and influence development.