Blog

3 learnings from enterprise architecture projects

I have been working at Arter as an ARC Software, data protection, data management and enterprise architecture consultant for a little over a year now in the spring of 2020. I switched to my current position from inside the house and instead of IT, I have my educational background mainly in marketing and sales.

Needless to say, this was not a small jump. Becoming a consultant means a lot of new terminology, new ways of working, new roles and responsibilities has to be adopted. Being a consultant involves a lot of expertise, inspiring people and an ability to express yourself clearly. An interesting part of the work has been the co-operation with project managers, and the related collaboration in project management both with customers and internally at Arter.

I don’t claim to be an expert in project management, but I strive for continuous improvement. Against this background, I would like to share three things that I have noticed will lead to a successful enterprise architecture project.

1. Set upper level goals and principles

In order for an enterprise architecture project to properly take off, the runway needs to be in good condition. The principles of architectural work that appear in several architecture frameworks and their description is an area that is really easy to overlook as a matter of course.

However, at the point where “Is this necessary” -type discussions become relevant when expanding the model, it is useful to be able to rely on some commonly agreed, more abstract documentation of what is to be done and what results are expected. After this it can be considered whether or not the current need for expansion is necessary.

2. Motivation and milestones – decide when you are ready and enjoy

Enterprise architecture is a brutal job in that very rarely can it be said to be “finished” or even “adequate”. In part, this is a self-inflicted problem, when you have chosen to work with architecture. On the other hand, it is also related to the fact that in this work, like elsewhere, the dismantling of the work should not be underestimated.

Architectural work should always be clearly disassembled into proper looking and sized entities. Enterprise architecture frameworks may seemingly represent such a distinction, but often even this angle requires a reflection into one’s own goals and entities.

For example, it is much easier to decide that our minimum state of architecture is to gather together the descriptions of processes, systems, and data protection materials already made in the organization than to marvel at the TOGAF metamodel and state that no one leaves until the Conceptual architecture level for information systems is complete.

It is also easier to enjoy the finished work if it already serves an identified need in the organization instead of just following a frame of reference.

3. Inspiration and teamwork – communicating about architecture

An enterprise architect, like a quality manager, often has the challenging position of maintaining and taking care of a heavy and large entity. However, it is not appropriate or sensible for the documentation to be produced by the architect alone. Thus, enterprise architecture requires the help of others, and in the absence of a managerial position, this usually means you have to utilize some internal sales skills.

Information system services, logical entities, capabilities

The biggest problem with enterprise architecture projects is often the quantity of different terms and the own confusing world where architectural work is located. The basic terminology alone takes multiple coffee cups to digest. This terminology should then be adopted as a framework for the development of operations. In addition, one should be able to use a software to describe all of this.

Even though I haven’t seen it myself, I feel like this is exactly the point where many give up. “Enterprise architecture is something that is worked on in the enterprise architecture team, others do not have to participate in it” – one can mistakenly think.

I’m still debating which is the better way to familiarize a new person with enterprise architecture: to start from an entity they are already familiar with, or to try to show the bigger picture first and then explain how their input serves that whole. As when teaching board games: to tell first how the player’s turn goes and then what the goal of the game is, or vice versa?

From a motivational point of view, it is important that everyone involved in the project knows exactly what is being done and why. However, in the case of enterprise architecture, does too much detail obscure the key issues and takeaways? In theory, the most important thing is that the material can be produced by experts, because they possess the best practical information.

Communication and teamwork are therefore important aspects of the success of enterprise architecture, but they also involve many challenges. I believe that one of the most important qualities of future enterprise architects will be the ability to communicate about what they actually do.

Order a free demo and try ARC Software - a tool for enterprise architecture

Get a Free Demo of ARC-software

* marked items are required

Author