3 learnings from enterprise architecture projects

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.

It seems that 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.

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.