Technology Services Modernization (Part II): Why design-first approach with DDD delivers greater value


In the previous post (here) we looked at 3 ways to modernize technology services and concluded the best strategic approach was to start with the why, map business domains, capabilities, services and modernize through good internal practices that make software teams aligned to capabilities, autonomous and therefore nimble to respond to new challenges

Great! How do you apply this in your organisation and make a case for this “design-first modernisation” approach? What would use as key indicators in your software delivery processes to motivate your business and IT leaders to embark on initiatives that leads to design initiatives like DDD

In this post we look at 3 key reason why you need design-first approach to modernization and key indicators to watch in your organisation to highlight the need for a measured approach

3 key reasons for design-first modernization

1. Technology services need Business alignment: When technology services do not map to business capabilities they become hard to trace leading to difficulties in consuming them in new contexts or changing them. Modernization through reuse of existing technology oriented integrations (SOA or EAI type services) becomes difficult in new situations as reusing, changing or even consuming these technology oriented services in new context may require coordinating a project team, managing change through a complex delivery and coordinated release leading to increased lead times and project spending

Mapping capabilities to services and starting small in a specific context is a good start

Impact: Poor alignment can lead to slow rate of change. This can lead to lost opportunities with partners and lost revenue due to inability to pivot/scale existing services to new customer segments and markets

When it is hard to trace business offering and capabilities to our technical landscape then it is difficult to change or innovate to meet new demands

Key Indicators: What indicators should you be looking for to implement change? When there is no alignment then we see the following lagging indicators – over reliance on technical integration interface and SMEs, long lead time with large integration projects with big capital expenditure, long lead time to onboard and serve new consumers

There are also some leading indicators such as complex dependency management across programs of work and the need for complex coordinated releases & regression testing which should be motivation to invest in domain centric design for modernization (or improving existing operational efficiency)

2. Distributed and Flexible Core Business Services: Unless you are a very small business or a startup, you probably have a few areas of your business that can operate autonomously and serve clients without needing to depend on other lines of business. If your core service offerings are actually provided by a few teams acting autonomously across business areas or geographical areas then it becomes simpler to adapter to new market conditions or needs in smaller independent regions to incrementally implement change. In contrast if you rely on a single core system or database then this constraints agility as a technology, team and delivery bottle-neck

Distributed model offers much greater flexibility to internal teams as they can focus on their own area of specialisation

Impact: A single common core technical system (or database) for business will fail to scale over time as it becomes the shared-kernel for multiple teams, coupling them in a 3-legged race. This core system and its team are inadvertently bottlenecks in any conversations around scaling to new customer segments, partners or markets

Central core is great for small scale but a bottle neck to acceleration

Key indicators: How do you discover common core shared kernel that is a bottle-neck? The key symptoms are – (a) there is a dependency to some core system as your business and technical teams always refer to this system and its SMEs as key to any change (b) there are long lead times to change because of the dependency and a complex software release process requiring coordination across teams (c) there are long lead times to change because teams integrating to the core are implicitly coupled. For example, a team integrating to the core last release with no changes this release must be consulted before a new team integrating to the same core can release (regression testing) (d) larger change fail rate due to implicit complexity around the core (e) larger time to restore as software release rollback is near-impossible due to all the intertwined parts

3. Boundaries: Having good boundaries can help with encapsulation of information, isolation and as the organisation scales good boundaries can help teams stay autonomous through as-a-service model. If internal and external teams are able to deliver new solutions without dedicated support from service provider teams, then this leads to greater autonomy and faster release of new features. Good boundaries force teams to interact via services (and events) so they are not coupled via physical infrastructure (common database or code) or concepts (no need to know the internals just consume a service). Good boundaries help organisations build a collection of services aligned to business capabilities and offer partners and new consumers these services in new contexts to discover new opportunities and revenue models

Boundaries are healthy and help drive specialization, autonomy through encapsulation of concepts, isolation of concerns and focus on a limited set of business capabilities

Impact: Lack of clear boundaries can blur responsibilities, encourage shared kernels of information or code that become bottlenecks for change. Boundaries help keep the mess inside with a clean abstraction outside. Providers across a boundary use standard published-language (PL) to communicate while consumers can use anti-corruption (ACL) services to translate

Boundaries facilitate as-a-service communication which reduces need to collaborate across teams enabling accelerated delivery. This drives modernisation because teams can respond rapidly to new business needs

Summary

In summary organisations with good boundaries with alignment to business domains and contexts with capabilities expresses as a set of services (that are not tied to a core but distributed), do really well with reacting to new market challenges and customer needs while maintaining the ability to deliver software incrementally, regularly and fast

These 3 key attributes make a very good case for organisations to take stock of their engineering practices and services because continuing without this framework is doing what we did in the past 10-15 years which is great for scale of that era but will not meet the demands of the new world where partners, eco-systems, global markets and savvy API developers expect greatness from businesses

1 Comment

Leave a Comment

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s