The ability to shift the IT lifecycle from manual to digital relies not only on a repository to store Project and Component architectures but also on the ability of Architects to create and maintain models.
This section provides guidance and advice on creating models.
Define the question that your diagram will answer.
You will typically end up with a better diagram outcome if you first define the questions that you would like your Architecture model to answer.
For example, these questions might include:
- Who are the stakeholders, and what are their goals and drivers?
- How does business process X work?
- What functions does application Y perform?
- How is data integrated across domain Z?
- What are the reusable APIs from Application X?
- What work packages are required to deliver the project/program/product?
You can create multiple views and include a piece of the puzzle across each view.
You do not need to have all information about a project/program/product in a single view.
Learn the ArchiMate palette set, including both elements and connectors
The ArchiMate modelling language contains 62 elements organised across seven layers – strategy, business, application, technology, physical, implementation, and motivation.
There are also 12 connectors used to create relationships between elements.
The semantics of all elements and connectors are useful.
You may find that as you begin to learn a few elements and connectors, and how to create a few common diagram types you see the lack of clarity in non-ArchiMate diagrams.
As you improve with modelling, you will learn to value the semantics of elements, connectors, and layers, and you will be able to glance at a diagram and understand a lot of information quickly and accurately.
This semantic framework is at the heart of the power of ArchiMate modelling and allows fast and accurate communication of ideas and designs between Architects.
With careful design, key ideas can be socialised and agreed upon with business stakeholders.
The following example diagram shows all 11 ArchiMate connectors being used. You typically wouldn’t expect that all connector types are used in the average diagram.
The meaning of the ArchiMate connectors is as follows:
- Composition – labelled as “composes” above. The solid diamond is the parent, and the other end of the connector is the child. Use Composition when the child cannot exist without the parent. For example, an Order cannot exist without a Customer.
- Aggregation – labelled as “aggregates” above. The hollow diamond is the parent, and the other end of the connector is the child. Use Aggregates when the child can exist without the parent. For example, an Order has a Product, but Products can exist without having been placed on an Order.
- Assignment – labelled as “assigned to” above. Use Assignment to attach an entity capable of performing behaviour to the behaviour it performs. Typically, this is used when you connect an Actor to a Business Function or an Application Interface to an Application Function. For example, Sales are assigned to the Create Order function.
- Realization – labelled as “realizes” above. This is most commonly used in two entirely different scenarios.
- Use Realization to connect a service to its implementation. For example, an “Ordering System” Application Component realizes (or provides) an “Ordering Services” service.
- Use Realization to show the traceability of information across technology, application, and business layers. For example, Product Data in the Application layer realizes (or “maps to”) a Product as defined in the Business layer. Business Objects in the Business layer can be thought of as a glossary of terms level.
- Serving – labelled as “serves” above. Use Serves to show consumption of services. This could be vertical consumption of services from one layer to the one above, e.g. technology to application, or application to business, or consumption of services within a layer, e.g. App 1 consuming an API service from App 2.
- Access – labelled as “accesses” above. Use Access to show read, write, read/write, or access of information. Access can be used in the Business, Application, and Technology layers.
- Influences – labelled as “influences” above. Use Influences typically in the Motivation layer to show where one Assessment may influence another or where an Assessment influences or rolls up into a Driver. e.g. the Assessment of “The warehouse is inefficient” may influence another Assessment of “customers are slow to receive their orders”. Assessments used in this way are a way of analysing root cause analysis, or “The Five Why’s”.
- Triggering – labelled as “triggers” above. Use Triggers to show a sequence of events, typically between processes or functions, or from an event (business, application, or technology) that triggers a function in those layers. For example, the “Create Order” function triggers the “Raise Invoice” function.
Understand the rule of three
One of the patterns in using ArchiMate is “something or someone (actor) does something (verb) to something (subject/noun)”
This pattern applies across the business, application, and technology layers.
Some examples are shown below, where top-to-bottom, we have the actor, verb, and noun.
The main point to remember is that if you have modelled one or two out of the three possible elements in the “rule of three”, you may want to think about what is missing as part of helping to build out and complete your model.
For example, if your diagram has a Business Actor and Business Function, it’s easier to see that you are missing Business Objects.
Understand layer traceability
The layers in ArchiMate exist for a reason. Typically, a lot of helpful diagram types focus on one layer only.
There is always an exception; however, the most common way elements from different layers get joined is by using the Serving and Realization connections. In terms of inter-layer connectors:
- Serving – shows how a service in one layer is used by the layer above. However, Serving can also be used within a layer, e.g. to show how service from App 1 is used by App 2.
- Realization – shows traceability of information, which can be how an Artifact in the Technology layer maps to a Data Object in the Application layer or how a Data Object in the Application layer maps to a Business Object in the Business layer.
Define the Operating Model first
The purpose of IT is to enable the seamless flow of information to achieve business outcomes.
Everything else is secondary and in service to the above goal.
Define the Operating Model first to provide the core requirements for your project/program/product.
Define the problem/opportunity
Before initiating a project/program/project, make sure that you Define the problem space.
Too many projects have been initiated because someone jumped onto the first pain point they found and decided that was the scope of the project.