Rule 1: Agility thru federated modular capabilities

After introduction last week, this is the first of the Ten rules for digital business renewal.

Strategic agility builds on the modularity of digital capabilities. When capabilities are truly modular, they can be independenty developed, scaled and moved. This translates directly to agility – the ability to capture new opportunities and to renew business.

For example, new digital service can be created fast by organising DevOps teams around microservice architecture. Correspondingly, payroll-like support function identified in enterprise architecture can be outsourced for maximum operational efficiency.

The degree of modularity depends on organisational structure, processes and IT systems alike. In other words, while architecture provides the necessary framework to design and describe modularity, it is operating model and technology platform that enable modularity and thus agility.

Modular capabilities are not inherently scalable. Poorly designed architecture, technology platform and operating model introduce scalability bottlenecks thru unnecessary centralisation. To maximise flexibility and scalability, capabilities should not only be modular but also decentralised.

For best possible flexibility and scalability, aim for distributed modular capabilities.

Federation adds an important element to the mix: Autonomy. A good example would be DevOps team having full ownership over set of microservices, including mandate to freely choose the tools and methods for developing and maintaining the software as they seem fit – as long as time-to-market and quality targets are met.

The implications of lifetime ownership assignment are profound: Software development is no longer about temporary projects but about permanent services and products. Inefficient and error-prone handovers are eliminated. With ownership comes accountability, quality and predictability.

If planned autonomy is a guiding principle for operating model design, the concept of bounded context guides architectural and platform design especially in relation to data. Bounded context emerges from Domain-Driven Design principle that allows different definitions across various contexts within the overall capability landscape – most of all conserning data deployed in digital services, connected products and business applications. No attempt is made to achieve global unification across all contexts. For example, “customer” would have different definition in marketing compared to customer care. In other words, enforcing single Master Data with detailed definitions would represent harmful centralisation.

If agility and flexibility are the upside of distribution and federation, the downside is also apparent: Lack of cohesion and inefficiencies due to poor alignment and, subsequently, increased operational costs. The key questions become: What to optimise? and How to minimise inefficiencies?

In the age digital disruption, the answer to the first question must be: Innovation, speed and renewal instead of control, alignment and cost. Success in the former group trumps the significance of the latter.

Optimise for innovation, speed and renewal.

However, the second question deserves an answer too: Thru holistic, systematic and persistent capabilility build-up based on careful design on architecture, technology platform and operating model.

Next time the roles of architecture, technology platform and operating model are discussed in more detail.

To be continued.