Some time ago, I listened a presentation related to various definitions of what IT Architecture really is, with their respective contrasts related to what many companies usually confuse about what IT Architecture really is. I think this confution, deserves a special article that I will write soon but for the moment I want to focus on relationships

¿So.... what is Architecture?:

The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time. (TOGAF)

And this is where I would like to zoom in and dedicate an entry in this blog, I want to talk about relationships, their modeling and the value that give you in the IT strategy.

In my opinion, beyond any formal definition, the strategy of relationships and how they are managed and governed, is a key factor in the architectural strategy's approach

They give you the capability to know how your application layout:

• It's connected with your business process.
• How a business function is related with the application that support that function.
• How your data flow between applications.
• Etc.

Not long ago, I started to mapp the architecture of a place where I work using archimate, applying Togaf as a methodology and, because the company is a service company, I'm using the TmForum Framework to adopt a reference. I have to clarify that company is not a telecommunications company but yes it is a service company, and the methodological framework offered by Togaf and TmForum are a great references and a great help to have a methodology and a reference standard.

Taking these premises, I used a method that allows me to map processes, data, applications and technology in a single place and thus be able to understand the relationships between them and act accordingly having this knowleadge in my dashboard (archimate).
To do this I started using Archimate, modeling four main universes (Data, Applications, Processes and Technology), grouping each of these universes in this solution and modeling the objects of each universe grouping them into domains (eg: customer, product, resource, etc) . Resulting something like this:

The challenge is that each of these entities has their respective secondary entities, also has relationships to the data they manage and also to the business processes and application. The first thing I thought was "when this grows, it should be easy to interpret and you should be able to "navigate" over this information."

Clearly, if you have gotten through reading this far, and have been working in IT for a while, you have the answer ..... Exactly .... that's right ..... GRAPH DataBase !!!!. What better way to formalize the architecture in a database and obtain as a result the ability to consult it quickly, by anyone who needs it and that the database is a mechanism for analysis and management of relationships.

My experience:

Without being an expert in Neo4J (I still am not), and with few tools, I was able to quickly get the following experience:

• Archimate has a plugin for managing the model with a database. The plugin is very good, since in terms of its management with relational databases, it allows you to version the modeling, save versions, etc. But the problem that I found in my experience as a user is that in my tests it was unstable, sometimes it allowed me to do what I wanted and when I repeated the same step after some changes, it gave an error.
• In line with the aforementioned plugin, it also allows export to a database like neo4j. In my experience it works fine (I didn't use it much either), but the problem I ran into is the "how the plugin builds objects" inside the data base. I mean, for each entity, relationship, and property, the plugin creates a graph and a relationship. In this case, it was not what I was looking for, since with how I modeled the objects, the properties are a specific attribute of the entity and not a separate but related object.

So before scripting in python or some programming language I decided to do my test, simply with excel and the Archimate export to .csv files. Where the export result is three files, one for the elements, another for the relationships and finally the properties.
In the file, I built the structure of each export file and added a small and very simple column, with an excel formula where concatenate de differents parts of the Neo4j statement where it inserts each line depending on what it is:

• Elements: inserts them.
• Relationships: Create them.
• Properties: It makes an update of the previous two.

The excel with the data resulting from the export builds the Neo4J statements and "wuala", after executing the resulting statements, we can have an architectural interface to publish catalogs, dependencies and analyze RELATIONS, etc.

It is important, beyond any standard and modeling method, to maintain the order of the objects, since this will also make the usability of the catalog and its understanding. In my case, as I use the grouping logic of TOGAF / TMForum, I have three great universes which I transpose with the use of the "Group" element of Archimate which allows me to keep my work board organized (data elements, related to groups of data elements and so on with everything else).

*For example:

It is also very important to take some time before modeling to define the properties of each element and have the behavior of completing the fields. This will allow, in the future, to look for patterns that allow analyzing the health of architecture. For example, you could consult the Database:

• "All nodes of type Application, with more than one relation to a node of type Application Function "and thus find semantic coherence problems where more than one application is resolving one business functional.
• "All objects of type Data Entity with the label GDPR Sensitive with their relation to the node type "Application" and thus be able to list the applications that manage data regulated by GDPR.

As you see, this is the important of the relations.

All objects have properties, and the secret of this strategy is in the properties of the objects and the organization to make these an interactive map from which you can obtain value.

As you will notice, the use and potential is infinite, it is only a matter of devising your modeling strategy and the behavior of doing it to obtain the value of the data that your own IT architecture generates in the relationships of the objects.

¿Wait.... But how looks like this in a Graph Database?:

Set the quality in HD:

To conclude, in my experience, the relationship management is almost everything in terms of architecture management and its strategy. It is impossible to imagine an area of architecture that thinks about its roadmap and solutions without considering the implications it has with the rest of the ecosystem and even more so without knowing and documenting how the application ecosystem is related.

Thanks for your time.

Martin.-