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. Sooner or later, Microservices and Enterprise Architecture are going to meet, start working together and hopefully, create scaleable productivity improvements for large companies.

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 Microservices often not enough for companies with complex IT needs serving thousands of staff and potentially millions of customers. Bringing Microservices and Enterprise IT Architecture 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 both to create a long-term IT solution that delivers benefits from the best of both worlds.

Why is integration often difficult?

Legacy IT and digital are slowly aligning. 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.

Here are some of the main challenges that companies and IT teams often need to overcome when working together for the first time:

  • 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.


  • 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.


  • 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.


  • 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 your company can start to overcome these challenges

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.