Navigating through the information model labyrinth
When modelling information, it is important to balance easy to understand high level overviews with accurate and detailed models. In the beginning of a project, all there is are high-level overviews. Often they are not yet complete, and they are not very useful once you get into the details. Later on in the project, there are too many detailed diagrams, where it's hard to get an overview, and the overview diagrams have not been kept up to date. In order to avoid this, it is important to set out a structure of diagrams that you will design and keep up to date.
I believe that the conventions and methodology we use for this are valuable for your information modelling as well. That is why I would like to relate to you how we typically handle this. I will start at the top level with ArchiMate and switch to UML for the detailed modelling. I will not explain these languages themselves, though even if you are not familiar with them it should not be too big of an obstacle for you to understand the models.
Our framework can be split into two major parts, one for the information architecture that is made in ArchiMate and one for the actual information modelling for which we chose UML.
As shown in the diagram, I split the information architecture into four levels. Each of these is described by a degree of detail into the architecture.
At the first level, I stay high level and aim to provide an overview and starting point into the architecture. I identify domains that fit both business and application level and provide logical containers for our information. These can be the main business domains for example. For each of the domains, try to identify and display the most essential information concepts. They should provide a summary and insight into the domain. For modelling the domains, the ArchiMate – business collaboration was chosen for lack of a better fitting type of object. For information concepts, I use ArchiMate business objects, as you can see below.
At the second level, I drill down do the specific domains themselves. We will stay within the domain and list all information concepts important to the domain. Of course, this won’t be an exhaustive list but all the information used within the domain should be covered here, even if it is through high level information objects.
At the third level, it’s time to take the next step into the architecture, showing the data objects within the applications. Since several data objects can be part of the same information concept, they each have their specific characteristics and names within their specific applications that are important to model. Definitely when these objects live in different domains, it’s important to identify their names and terminology within the different domains and applications. When relevant, you can also create diagrams that visualize all data objects that represent one specific information concept.
At the fourth level, we then dive into the interactions between applications and possibly domains. This is where you model information about interfaces between applications and shown in the model below. By placing the connecting business object on the diagram and linking it to the data object, I created support for navigating through the models. If you now search for all diagrams that contain this specific business object, you will immediately know that it is part of an interface – in case you also properly name your diagrams of course (and depending on the functionalities of your preferred modelling software).
Getting to the level of detail of data within applications and information exchange through interface, we experience that we are at the limit of what we could easily model with ArchiMate. This is the point at which we switch over to UML, which is a lot better suited for detailed modelling. Here we created a hierarchy of levels as well, to create structure and clarity into our collection of models.
The levels shown in the diagram below might already be more familiar to you. This is where we get to typical diagrams such as a conceptual and a logical model. I won’t show you specific examples on each of these anymore, just one to illustrate the difference with the higher level modelling in the information architecture.
Previously, I showed you how I model an interface at level 4. I stayed high level there, the main aim was to link the different involved objects and applications. Some users only need to go up to this level of detail, they don’t need to know what attributes are exchanged, for example. When you want to model this information, you can do so at level 7.
On the model above, there a many things to notice. For starters, I placed the ArchiMate interaction and application components on this diagram as well for traceability. This way you can move from the ArchiMate high level diagram very easily to this one detailing all the specifics of the interface for which I use UML.
Within your level 6 diagrams, you should have logical models of the applications involved in the interface. You then use the specific classes involved in the interface on the model shown here. In case the naming of attributes is not clear, or some are aggregated into one through the interface you can choose to link the specific attributes, as was done here for illustration. This can make the model heavy, though, so only do this when it is necessary for understanding the diagram.
Connecting it all together
You can look at these two parts as being parallel structures that partially describe the same information. If you want to stay high level, you stick to the information architecture on the left. If you want to have more details, you zoom in to the corresponding models on the right. You can see that, for example, level 5 complements level 2 with more details.
Where moving from left to right means getting more details on the same objects, moving “down” in the structure means drilling down into the architecture; getting more specifics on one object for example. On Level 2, I still see all information concepts from one domain. When I am then curious for all data objects that contain the information represented by one of those concepts, I go down a level.
This structure can create a lot of clarity and speed up the modelling process because you know what is expected where. You don’t have to wonder what type of information to include where. Once your model gains maturity and more stakeholders use it, the threshold to master it and find their way is a lot lower because your structure is clear and documented. This makes adoption of your models higher and increases the chances that they will actually be used and kept up to date.
The next thing will be to integrate this within the organization and test how solid our conventions are for end users that need to work with the architecture. Who knows, those experiences might prove worthy of another blog post. Stay tuned!