Microservices and Enterprise Architecture: Introducing Two Worlds

Sooner or later, Microservices and Enterprise Architecture are going to meet, start working together and hopefully, create scaleable productivity improvements for large companies.

For too long, Microservices and Enterprise Architecture have been managed separately within big businesses and public sector organisations that have extensive and complex IT needs. Enterprise architecture often runs on legacy systems, whereas microservices are usually part of new, “digital transformation” team.

Another way microservices take root is when they are spread across a range of teams that all play a role introducing a layer of digital technology throughout a company. Microservices are sometimes promoted as the silver bullet to corporate IT transformation; the key to unlocking productivity challenges caused by legacy systems.

But the truth is, as a stand-alone solution, they are often not enough. Bringing these worlds together is the most effective way to improve legacy technology without losing many scaleable advantages that microservices can’t always deliver.

Digital offerings can’t continue as though the rest of IT doesn’t exist, and IT without some of the innovations of the past 15 – 10 years is obsolete. Larger companies needs are met when quantifiable gains are made from meeting and exchanging knowledge and systems, and then integrating Enterprise and Microservices to create a long-term IT solution that benefits from the best of both worlds.

Why are they so different?

Legacy IT and digital are two different worlds, but they slowly are getting closer. You might notice this slow convergence if your company already works with external IT partners – you will find that most can handle both unless they come from a legacy background and offer ‘digital’ services as a revenue-generating afterthought.

From the perspective of anyone trying to bring a legacy and digital team together, here are some of the main challenges you will have to overcome:

• Approaching from a different angle. Enterprise approaches IT from a top-down angle. Projects have long lead times, need sign-off from multiple stakeholders and ideas emerge from reports, emails and committees instead of end-user needs and answers to specific workplace challenges. Whereas Microservices are bottom-up solutions to challenges that don’t need massive budgets and committees to fix.

• Different pace. Microservice solutions can be deployed quickly, over a few weeks, months or even days. Enterprise IT can take years from conception to deployment. Working together means getting used to these two different paces and coordinating activities and expectations so that synergy can be achieved.

• Different languages. Words carry there own meanings and expectations in these two worlds. When working together for the first time, ensure both parties are clear on the documentation and meaning behind words and phrases, such as process, service and component, that could cause problems.

• Divergent approaches to “Architecture”. Legacy IT teams think about architecture from the perspective of integrating and connecting. Microservice team members and external providers may find this difficult because these solutions emerged partly in response to burdensome and expansive legacy systems.

How to overcome these differences

It won’t be easy, and it won’t happen overnight. But it can be done. Getting on the same page will take a few meetings – maybe more than a few – to ensure both teams, and the relevant stakeholders are speaking the same language and clear about the aims, tasks and timescales to start working together.

These two teams do have a lot to gain, as does the organisation they serve. It may be useful to start on a small scale trial project to assess how effectively everyone can work together and understand what other bridges need crossing before embarking on a longer journey.

Larger projects could involve working on large monolith applications used across an enterprise to create smaller, more manageable products that can be deployed in specific markets, or for innovative new projects. This could also serve to break down or tidy up large blocks of code into multiple smaller classes or methods, which would make it easier to code review, unit test and ship changes, thereby serving to benefit both teams at the same time and end-users.

In time, working together, speaking the same language, understanding aims and objectives and working to improve the IT architecture of the organisation will create amplified benefits for the company, stakeholders and customers.