Author: Willem Janssen

Why Enterprise Architecture does not keep its promises

It often happens that an Enterprise Architecture (EA) has been implemented in an organization with great enthusiasm and goodwill, and has failed. Why is that and how can it be prevented?

Organizations often work out how to apply EA frameworks such as TOGAF, after which a set of often complex diagrams is devised. With these template diagrams in hand, processes, actors, functions, applications and data are mapped and stored in a central repository. A few years later you often see that these diagrams are no longer up to date and it is not clear who in the business owns what.

The result is that the wheel often has to be reinvented when part of the organization is analyzed, for example for the implementation of a new application. For example, processes are modeled and data analyses are done. For every project where this type of information is recorded, it is often done in a different way and the information is not stored in such a way that a subsequent project, or operation, can use it.

The potential value of using EA is great. Oliver IT sees EA as having a construction drawing of a house. If it is up to date and reliable, it is easier to determine where we need to renovate in order to continue to serve the changing market properly, which professionals we need to involve in a renovation and whether we will touch a part of the house that is already planned for a renovation. The reasons for applying EA are solid, but EA often cannot live up to expectations.

Where are things going wrong?

1. The distance between the operation and enterprise architects is too great.
2. The language (diagrams) in which enterprise architects communicate is not well understood.
3. Enterprise architects are in many cases not able to move quickly enough with the operation
4. Ownership is not properly invested

The promise is that architects will help the organization make well-founded decisions about strategy, possible changes to be implemented and (future) technological applications. An up-to-date construction drawing is required to be able to fulfill this promise. The focus is often on what this construction drawing should look like and should fit what the organization should look like in the ideal world, rather than how it actually functions. There is too little insight into daily reality, which means that insufficient contributions can be made to solutions to challenges that the business actually experiences.

The reality is that most people cannot read diagrams easily. The architecture diagrams are often complex and require a lot of attention from the reader to really understand what they say. The reader drops out, while such a diagram often contains very valuable information. Enterprise Architects are often very strong in abstract thinking and assume that other people are just as good at it. On the other hand, and not only in the EA field, there is the pitfall of using too much jargon. Often, both the oral and the written language of architects do not match the language that other colleagues speak.

This is often also a capacity problem. It is not uncommon for a handful of architects to keep EA documentation up to date for organizations employing thousands of people. People simply fall behind the facts, so that information that is recorded under EA cannot be kept up to date. This significantly diminishes the value of this information. The business notices and feels this and will apply its own ways to still be able to achieve the (short term) goals. Another reason is that there is a tendency to want to record too much information, which does not help the amount of work to keep it up to date.

An example is that when a process diagram is viewed, it shows an owner who has been out of service for 2 years, or where the name of the colleague should be, it is not entered. Investing data ownership is often even more challenging and is becoming increasingly urgent due to the increasing role that data plays within and outside the organization.

How?

1. Decentralize and democratize the creation of necessary diagrams.
2. Record only the essentials in these diagrams and keep them simple.
3. Work iteratively. Start small and let EA grow at a pace the organization can handle.
4. Ensure ownership.

Keeping diagrams up to date is much more challenging than preparing them for the first time. Projects in which an army of people map out the organization usually work fine. Keeping up is where it often gets difficult and strand. This can be prevented by having people directly involved in the changes update these changes in the construction drawing. A good start is the IT professionals. Where software is adapted, the processes, the data, the actors, the technology, the capabilities, etc. are often affected, etc. Make the construction drawing and the adaptation thereof part of the design process, so that these professionals benefit directly from the new methodology. Prevent chart updating from becoming a chore task that must be performed after you have actually finished. This requires user-friendly and accessible tooling. A good example is Value Blue, where the role of an architect will shift to guiding and supporting colleagues.

" Perfection is the enemy of good ”. Seek connection with the colleagues 'who will do it'. Explain concepts without using jargon and connect with the abstract thinking level of the modellers. Only let them record information that they themselves see the use of or convince them that additional things are actually useful. It doesn't have to be perfect right away, certain concepts can also be introduced later. Give the model, but especially also the people, the opportunity to grow.

Make room to experiment. Start with a limited foundation that is minimally needed. This creates space for the modellers to come up with their own ideas, which can be adjusted where necessary under the guidance of the experienced architect. Architects will have to act in a more serving role than a demanding role. That does not mean that architects should let everyone do their thing. There is a model that must be met, there are conventions that cannot be deviated from. Above all, explain why and, as an architect, move along when the modellers or the organization wants changes in the method of recording.

Invest the ownership of processes, data and applications in an unambiguous manner. Make sure that modellers and owners share a responsibility to correctly describe and keep the relevant diagrams current. Ensure assurance by including having current plates in, for example, Definitions of Ready and Done and having owners formally confirm their diagrams are current on a regular basis.

In this article we wanted to provide a number of concrete tips that can increase the chances that the investments in EA will pay off and that EA will keep its promises. It is a shame to let the enormous amounts of work of architects ultimately lead to beautiful-looking results that unfortunately offer little added value for the organization. Continuing in the same way as before will not suddenly work, so dare to experiment and take action when the traditional pitfalls are not avoided.

Specific questions?

Enter your e-mail address and Oliver IT will contact you as soon as possible!

Done! We will contact you soon!
Jeroen Jansen Consultant
Jeroen Jansen