Enterprise Architecture Introduction #1

Many studies on the selection of tools for describing "IT architecture" shows that almost 50% of companies use software tools that are neither suitable nor appropriate for this purpose. [Visio, Charts, etc.]

Practically in every company - graphic tools and programs are used to describe the elements of an IT systems: networks, device description, software configuration, diagrams ... It is usually software that has some possibilities to build diagrams, connections, but from the point of view of functionality it is something between vector graphics based with line/basic symbols and something like an incomplete and undefined database containing some set of elements.

In the case of ad-hoc diagrams or when someone makes a diagrams for their own purposes and doing it only once, it may be justified. Except that these diagrams start to live their lives, once they are made and are very often they are duplicated and distributed to others. Practice and experience show that with each new diagram, new ideas appear on how to use a given diagram or drawing for some further purposes.

I think anyone can confirm that with time the number of such independent and duplicate diagrams grows. With time, the administrative effort also grows. Probably such diagrams are never up to date - because of lack of time or periodic checks. The more people, the more diagrams and the greater the problem with keeping them up to date. If you add to this various methods of description, free interpretation of the described configurations and internal matching of the diagrams to the needs of the moment, then it is not difficult to guess at this point that we have just achieved diagram's chaos.

In fact, if the diagrams are not in some central repository, we have one more big problem, which is called: in search of a missing diagram. If we add to this situation: employee rotation, constant changes in systems and attempts to document the state of e.g. infrastructure, applications or strategies combined with changes in information systems - it is clearly visible that this is not a scope of tasks that can be performed by one person, but rather it is already at inter-departmental coordination stage. Every company is dealing with this and to solve this, they usually have to hire external consultants.

Let's start by describing it - at technology level. Here is a basic network diagram with a few servers and applications.

Now let's approach the topic more methodically:

• What elements are in these diagrams?
• What are the dependencies between the elements?
• Are we able to separate the above-mentioned elements into those that have some similar characteristics?
• Will we be able to present some form of organization and management of the above-mentioned elements in the next steps?

These are the basic questions that need to be answered to understand: choice of tools is critical and decisive for future activities and organization of work. In the case of software for describing of corporate architecture (Togaf / Archimate model) we have several layers that we can define and use to logically present what we have at all levels of the IT landscape. (This article applies to "technology level").

The model itself can be divided into 2 parts:

• repository with elements - where elements are divided according to functionality, characteristics and information they contain
• diagrams built on the basis of the repository

In the case of e.g. MID software, the number of diagrams that we can create is over 30 types based on several basic types of diagrams.

How would the same network look like in a MID model?

Below is an example (Architecture Overview):

and at the next step we have (Architecture Details):

What conclusions arise after presenting such an approach?

[Left side: all connections listed and indicated, Right side upper part: which elements contain which element, Right side lower part: details about hardware/device element.]

First of all, we gain control over all elements that are used in the model.

• items have definitions and descriptions
• items attached to the diagram are automatically placed in the repository
• in case of changes in an element: name, additional data ... they are automatically updated in all diagrams in which they were used
• when removing elements, we also know where the element was previously used or what dependencies still exist. When removing elements, there are 2 types of deletion. Removing from the diagram and removing from the repository database. The second option has to be confirmed.

But the most important from the point of view of organizing information about systems is that we finally have the ability to create schemas according to always up-to-date data. And most importantly - we can present a point of view in the diagrams, which usually can take 3 forms:

• general overview diagram
• diagram of logical or physical connections
• detailed information on all architecture or parts of architecture

According to the principle that applies not only to IT - presenting the issue in accordance with the Top-Down methodology has a huge impact on the speed of acquiring knowledge about the system or it's part and determining the impact on other elements of the system. This is nothing unusual and it can be said that it is everyday business. There is pressure to learn about the technology or tools, but without a clear and legible connection with the bigger picture it represents as a whole - everyone has a problem understanding its role and scope of tasks.

This article only covers the technology layer. That is something that is relatively easy to present because we usually use mental shortcuts that created associations with physical elements. Returning to a very large simplification, we see that:

• server has a network card / ethernet connection
• the network card is connected to the switch/router
• router has connection to other elements and plays role of separator of the network based on location
• some application or database is placed on the hardware level via internal interface / service

But while the physical connections are still quite simple to show. At the logical connection level and with related elements at other levels, it becomes a difficult challenge. What is really positive is that specialists who take care about specific elements of systems can update this single element and keep them always up-to-date. Anybody who will use such element will have updated version. It is simplification of not only diagrams. It is simplification of the work.

To be continued ...

===

In a series of several articles, I would like to focus on presenting the issue based on the Achimate/Togaf model and the MID Innovator software package. Articles will be published every 7-14 days and their aim is to popularize the issue and encourage its use in practice.

Links:

• MID Innovator: https://www.mid.de/en/download/innovator-downloads/enterprise-modeling-suite
• Archimate Tool: https://www.archimatetool.com/download/
• Togaf: https://www.opengroup.org/togaf

#EnterpriseArchitecture #AliensIT