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
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
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
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
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
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
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
Alok Mishra 
1 Comment