Technology Service Modernization (Part I): 3 Approaches to Modernization

Welcome to 2022. While I was in a blogging hiatus, my time was spent closing out conversations with business and technology leaders looking to modernize their technology solutions as they were looking to adapt them new market needs and challenges. I thought Web3.0 was the big buzz word but it looks like Modernization is the real deal

In an effort to understand why our clients needed this now we needed to frame their problem better and through workshops understood that there was a polysemy in the word modernization as different people in different contexts attributed a different meaning to it – some meant modernising their application infrastructure while others meant a re-haul of how IT services reflected business capabilities

Paths to modernization

Through our journey, we learned that there were a few different approaches to modernizing depending on the problem at hand

Through recent experience, we learn there are 3 popular approaches to modernization depending on the context. Couple are tactical and great short-term options but can cause issues in the long run and one is Strategic which can be quite a fair bit of upfront work with incremental benefits over time

1. Façade services aka strangler pattern: over old applications or existing services from systems integrations
2. Moving workloads out to externally managed services
3. Business oriented design

The simplest approach is when the problem is framed as an infrastructure modernization challenge due to on-premise hosting and manual practices for maintaining software. The path here is of the cloud modernization where moving to managed platform services can provide immediate value to the bottom line

The other approach is to provide a simple abstraction over existing technology services with a façade to meet new needs. API gateway vendors offer this dream with API policies use to shield core legacy systems and services from performance and security implications of a new context. This is a great first choice until you need to make deep-changes to provide new features

The third and the more considered approach is to start with a Business led initiative that maps domains, contexts, services to business capabilities and looks to modernize software delivery practices and services by building better boundaries so that teams business led, autonomous and can scale independently to meet their specific needs

Observations

All the paths can help organizations modernize their technology services to new challenges by providing scalability, automation, adaptability but they differ in their ability to sustain these over time. Some of the solutions are tactically sound but over long periods can cost more to operate and change or even create more inherent challenges that would require further spend to remediate

Experience from our clients indicate that implementing a façade to serve new clients, markets in new contexts using existing internal integrations or services grew complex and expensive to deliver over time as the abstractions over existing systems of record did not scale or became a nightmare to operate and maintain due to customizations. They were not meant to adapt to the new scenarios and adding a façade pushed the modernization problem to the core systems of record. Data complexity grew over time leading to large programs of work to fix the broken information model in the end systems

In general experience would indicate that both options 1 & 2 were poor long term strategies as they increase inherent complexity over time needing to long lead times through a delivery pipeline with large capital expenditure and attention to achieve their outcomes

It was with option 3 that our clients have witnessed incremental return on investment (ROI) as we started with business needs, crafting boundaries modelling business and functional areas, encapsulating information and sharing them through as-a-service model and providing autonomy to teams within the boundary so that the entire organisation is nimble and able to scale

We applied was domain driven design (DDD) as our primary design technique to workshop and build strategic models of the as-is and to-be socio-technical landscape of the organisation with our clients. We used this blueprint to build a catalogue of information mastery and services for internal and external consumption (APIs and events). This scaffolding provided the next steps on the journey and the outcome was immediate – incremental changes, visible pipeline with clear set of services which were traceable to business capabilities and a funding model

Summary

Every company is a software company and adapting to new market needs, partners, customers, regions etc requires a clear and consistent set of technology services (APIs) mapped to business capabilities. Modernization is the art of transforming your current software practices to modern ways of building software that is distributed, aligned to your business capabilities and has clear boundaries for encapsulation, security, autonomy etc

There are 3 primary ways to modernize with options 1 & 2 to following a façade and lift-shift pattern. These two options are great first steps build fail to address the deeper business concerns and using techniques like Domain Driven Design (DDD) to kick off business-first approach is the way to do strategic modernization

In the next post we will examine how you can evaluate your organisation needs and make a case for design-first approach to your leader. We will talk about 3 key reasons to do design first modernization and how business oriented design techniques like DDD are critical