Microservices and Enterprise Architecture: When Two Worlds Meet

Even if the buzz begins to fade, microservices are still on the front of the stage. Yet, in our view, one subject has not yet really been addressed: how to make business architects/urban planners work with microservice projects. A legitimate question: these two worlds are quite distinct, one often working on old legacy systems, the other on the so-called digital projects of the company. Why are these two worlds going to need to exchange? What cultural and methodological differences will they have to overcome? Why do they have an interest in working hand in hand?

Why Should These Two Worlds Meet?

It is a fact that these two worlds will meet sooner or later, for one simple reason: if many of these microservices projects are the result of the initiatives of  "digital directors" and other CDOs, sooner or later they must be integrated into the rest of IT. A new "digital" offer can not eternally go on as if the rest of IT did not exist, as it needs to reuse already existing bricks, or "repackage" existing business offers living in the legacy world. Sooner or later, we must share and exchange. Failing this, the industrialization of all these new business offers can not be done. The gain is therefore real and very quantifiable, although it is obviously necessary to explain and share it, because of the risk of misunderstanding is great.

How Are They Opposed?

Let's face it, the meeting of these two worlds is difficult to orchestrate smoothly. Four major cultural differences distinguish them:

• A difference in methods: There is a very bottom-up general approach for these microservice projects, where it is developers who have defined the ways to work with business users, when enterprise architecture approach is very top-down oriented. The company architect must, therefore, work much more closely with development teams and learn from their contact their methodologies.
• A difference of tempo: While microservice projects are very often agile and are potentially capable of delivering every day in production, business architects can easily work on cycles of at least six months. A good tempo and a good synchronization must therefore be found, without breaking or degrading the work of each one.
• A difference in vocabulary: The vocabulary of these two parts is filled with false friends. For example, the terms process, component, and service derive their own definitions of the world of development and operating systems. Be careful to understand each other, and to explain examples and documentation to ensure mutual understanding.
• A different perspective on "architecture:" When enterprise architecture seeks to integrate and share, microservice architectures disintegrate and explode data and processes.

Lastly, we should not rely entirely on books that revolve around microservices. Not that they are uninteresting and useless, quite the contrary, but nothing tells you that the great dogmas have all been respected. Have them in mind, but do not take them for cash. And if you are looking for a book to begin with, you can start with Sam Newman's book called "Building Microservices."

In our opinion, the first step is to show great mutual humility, and to multiply the meetings, in order to be able to answer the following questions:

• How is the organization of the project decomposed? Knowing that we can have transversal architects between microservice projects, whose work begins precisely to resemble the work of a company architect.
• How do you work with business users? Many of the microservices projects are based on the Domain Driven Design methodology, which includes its ability to model the domain in what is called ubiquitous language.

After answering these questions, everyone must find their place. It's not simple, because the corporate architect is tempted to think that he is at the top of the "hierarchy," whereas the implementation of such an organization risks either embarking on a heavy workload or slowing down projects. It must, therefore, be assumed that these two worlds work on different time scales.

How to Get Started

To answer these questions and to overcome the divides, a track must be seriously dug: that of this famous ubiquitous language, which potentially is a view of the enterprise business model. This ubiquitous language does not necessarily represent all business objects and can be implemented differently in code. The translation between the two models represents a first project to launch, so that the docking with the business model takes place, but also to define who has the right to modify the other.

Should we be bottom up or top down? Make an equivalence table? Our choice spontaneously would rather be about going back and forth in both directions, but to each judge according to its context. Finally, let us not forget the question of tooling and its possible ability to automate and publish data models represented by both teams. A good understanding and good tooling can greatly facilitate exchanges, but pay attention: at the time, no modeling application will help you spontaneously ...

This work is obviously only a first step, but the gains, very tangible, can be observed quickly! Enterprise architects will need to get closer to development teams, who themselves will have to make an effort to understand the role of this corporate architect. The key to success is humility and kindness, to ease tensions and misunderstandings. Because it is a certainty, these two teams have much to gain by working hand in hand!