At its essence, digital transformation is about aligning and connecting the building blocks of a modern corporation. Enterprise leaders often view digitization as an overhaul from older, disintegrated business information systems to a fully integrated digital backbone enabled by IT. However, creating change that lasts requires a delivery model that’s built for change. We need to think of transformational activities as stepping stones along the way to new business opportunities, not just individual IT projects. It is important not to lose focus on all that is afforded by going digital. The cohort of digital benefits are often more valuable than any single benefit in isolation.

Going digital without the management and organizational framework to support it is akin to building the fastest, most capable fighter jet without training the flight crew to fly it. In the world of organizational design, the agile enterprise is akin to flight school. It allows an organization to fully exploit the capabilities of a digital business – one that’s organized around value delivery and set up to adapt quickly to market demands at whatever speed is required.

Though the agile concept has been named and branded many things, all flavors aspire to the same fundamental goal – to adapt and iterate quickly in response to market feedback.

While microservices stress downsizing and fractionalizing application components, containers allow components to operate independently of one another and independently of their environment. In essence, a microservices framework using containers mirrors the autonomous, agile organizational structure. You’d be right to recall Conway’s law at this point. “Any organization that designs a system will produce a design whose structure is a copy of the organization's communication structure.” An agile architecture framework should, therefore, be the natural outgrowth of an agile enterprise.

Of course, not all IT architectures – in whole or part – are well suited for a transition to microservices. When considering a change in architectural approach, it’s important to understand the following benefits and drawbacks of the framework and supporting technology:

Benefits of Containers and Microservices:

With effective governance, a microservices architecture that depends on containers can use available infrastructure resources more efficiently than a traditional service-oriented architecture (SOA).

Because components are pared down to their essential functions, they are easier to update, upgrade, adapt and debug – all of which can be done with junior resources.

With container-instance duplication and orchestration tools like Kubernetes, a microservices architecture can be more resilient and scalable.

Since a microservices architecture emphasizes component simplicity, information passed between components also is simplified. This allows the architecture to shift away from an enterprise resource bus (ERB) framework to lightweight application programming interface (API) or point-to-point extract, transform, load (ETL) messaging services, which have the potential to introduce performance opportunities.

Concerns with Containers and Microservices:

A more fractured architecture that uses containers requires more governance and orchestration both within the architecture and at the organizational level.

As container-instances are duplicated to achieve scale and redundancy, synchronization concerns inevitably will grow.

The scalability of microservices may outstrip the ability to read and write from legacy databases and cause performance limitations.

From a management perspective, best practices with respect to the type of employee, management structure and roles required to manage a microservices-centric engineering team are still not well defined.