Layered digital architecture can accelerate your digital transformation
Layered digital architecture can provide an approach to accelerate the digital journey by detaching itself from the legacy core.
This article discusses how a layered digital architecture can help organizations enable digital capabilities faster without being impeded by its legacy infrastructure and platforms.
Background
Hopefully Covid-19 pandemic is behind us, and our lives will return to normal. For businesses, the normal is still to be determined. The covid experience created a strong wave to enable digital capabilities and fast-tracked digital adoption. Every organization is accelerating its digital transformation.
The challenge many organizations have is their legacy-core monolith platforms that were written many decades ago, it impedes them to accelerate digital. Mainframes are still used for core products administration like in banks and insurance companies. These systems were never designed for end-to-end customer experience journeys, nor they can deliver a consistent omnichannel experience that digital customer expects today. They are inflexible and expansive to enhance, and certainly not digital-friendly.
Key challenges:
Organizations have been implementing some level of digital transformation for the last two decades, however, they are reluctant to transform their application landscape, especially the legacy core. These digital capabilities were bolted on top of legacy-core by exposing some of the legacy functions through primitive interfaces without much thought for consistent customer experience. There are three fundamental challenges:
- Legacy technology: The legacy core was written in programming languages like assembly, COBOL, PL/1 in the 80s following architectural patterns that were long outdated. Modifications to these platforms are slow and painful. Knowledgeable staff with a history of enhancements has either left or are in queue to retire soon. These platforms pose risk to business continuity.
- Complex application designs and integrations: Technology debt was ignored for too long and subsequent enhancements were stacked on top of previous tech debt. The replacements or transformations of applications became too large and costly. Capability replacement or modernization needed large investment due to many complex and primitive point-to-point integrations, and it was difficult to justify business value or return on investments.
- Missing capabilities in middle layers: The digital capabilities were often directly bolted-on on top of the legacy core and in-between critical capabilities were not developed. For instance, lack of customer relationship management platform, lack of common view of the customer, lack of data and integration platforms, etc. Siloed line of business added additional complexity and data quality for upstream consumption suffered as a result.
Part I: Accelerate digital transformation through Layered Digital Architecture
Figure: Layered Digital Architecture
To enable transformation layered digital architecture is divided into three cores and each core has two layers, as follows:
- The digital core is the channel-facing transformation zone. It consists of user experience (UX) and supporting digital platforms that enable user experiences. It supports all types of user interfaces, i.e., customer-facing and agent-facing interfaces. The digital core is the focal point of the digital transformation. Digital experience platforms include traditional web/mobile user interfaces, chatbots, smart assistants, outward-facing Open APIs, and other digitally connected devices. Other digital platforms include numerous capabilities like journey management, personalization, content management, etc.
- The integration core is the enabling zone. It consists of integration platforms and decoupled data platforms. Integration platforms support both synchronous and asynchronous communication through API Platform and Event Hub. It also includes all inward-facing platform APIs. Decoupled data platforms extract enterprise data and detach them from their sources to place it centrally for easy digital access, closer to consumers. This layer enables and promotes many modern architectural patterns including domain-driven, event-driven, reactive, and microservices design patterns which are critical for the modern digital core.
- The traditional core is the rehabilitation zone. It consists of two layers including customer & intelligence platforms and legacy platforms. The first layer includes platforms like customer relationship management (CRM), order management, service management, business intelligence & analytics, etc. The second layer includes legacy platforms that manage billing, contract, account, policies, etc. It will require careful and feasible capability assessment to rationalize, modernize, replace, or strangle legacy platforms.
How to enable middle layers:
In the past, while conducting digital enhancements these organizations tend to think of front-office or digital experiences as “User Interfaces” that are an extension of legacy core. i.e., the Legacy core is the only system of record (SoR) and no other platform has the authority to save the data.
This forced these organizations into a rigid un-scalable architecture. Legacy platforms are not suitable nor were they designed to support front-office experiences, client relationship management, or digital omnichannel experiences in general. Legacy platforms are unable to extend their capabilities and data structures required for modern omnichannel experiences. Because of these rigid architecture practices, the Omni-capabilities in the middle layers were never developed leaving a huge gap without which platform transformation is unable to start.
Hence, a cultural shift is required to enable an application or platform transformation. Layered digital architecture can provide an approach to accelerate the digital journey by detaching itself from the legacy core, and by introducing additional capabilities in the middle layers.
This includes two concepts that need a revision to enable these middle layers:
1. Customer Platforms Layer:
A customer layer can provide numerous omnichannel capabilities for front office experiences. This includes customer platforms across lines of businesses including customer relationship management platform (CRM), quotation, product catalog platform, ordering platform, service request platform, etc.
To enable the customer platform layer, the stance on System of Record (SoR), System of Engagement (SoE), and System of Insights (SoI) need revision. These are traditional concepts from monolith architecture that are no longer applicable (in traditional context) in the digital enterprise. Data is distributed across many platforms rather than a singular monolith platform. Organizations will need to invest in this decentralized customer management with a two-pronged approach:
- Where certain customer data is more suitable to be managed by platforms like CRM, order, service request, product catalog, goals management, etc.
- Where certain customer data is more suitable to be in domain microservices, e.g., customer personalization preferences, progressive profiling, etc.
For instance, customer interactions can occur in many places, e.g., customers creating online orders. These orders can be managed by an ordering system in the customer platform layer (instead of the legacy core). This will make the ordering platform system of record for orders. Similarly, customer data is better managed in CRM platforms. It can maintain customer profiles, 360 views of customers, interactions, activities, etc. Their taxonomy and data structures are much more modern and conducive to an omnichannel experience. It can be a system of record for customer data instead of a legacy core.
However, CRM will not the only source of customer data. Other platforms or channels can also create new customer data due to their unique interactions or transaction. They may also develop domain microservices (that own its data) and it will be SoR for that data.
The approach to System of Insights (SoI) should also be decentralized. They are longer a capability of a central monolith intelligence system. Rather it can occur in many places, e.g., in churn propensity models, personalization features, fraud routines, etc. The insight features can be developed independently (as a modular or a componentized architecture) or a bunch of them can be provided by a platform.
Thus, the traditional lines of SoR/SoE/SoI are not contained in “certain” platforms anymore, rather they are spread out, making architecture much more flexible. This technique also provides a way out of technology debt and allows organizations to slowly strangle a legacy capability into a more modern platform.
2. Data Decoupling Layer:
For digital channels, data needs to be closer to the consumer. In the past organization that tried to create a single source of truth resorted to an expansive MDM solution. Due to the size, cost, and complexity of MDM solutions were never fully materialized. Another approach was to bring all the data to a singular database which runs into typical monolith limitations of not being able to support all types of consumers/channels, rigid data models, and poor data quality.
For digital channels, a distributed data management approach provides a much more flexible architecture. As organizations move away from monolith platforms it will allow them to create a curated decoupled data layer. These data zones will become a key pillar for a digital strategy, as they bring data closer to consumers and it provides higher performance and agility.
In a decoupled architecture, data can be processed once but copies of that data can be pushed out to decoupled zone. This technique works well when data has high reuse across many consumption purposes especially digital. This data is a good candidate to be ported to a decoupled data layer. Other data that has low reuse or where data is local to its platform, that data doesn’t need to be extracted to a decoupled data layer.
To enable this layer organizations will adopt two architectures patterns, i.e., event-driven, and domain-driven patterns. They will need to create a data procurement layer. The source systems (SoR/SoE/SoI) will trigger events to an event hub to send their respective data to the decoupling zone. There this data will be curated, processed, cataloged, and data quality will be applied. This highly purified data is then saved into domain databases (following domain-driven design), and it is also published on the event hub for other consumers to subscribe to. Consumers that require a local copy of this data for their platform can easily copy it by subscribing to domain events from event-hub. Others can access this data through domain APIs. This architecture is much more flexible as it provides consistent data, and it also brings data closer to consumers. In the digital world, that is golden.
These concepts play heavily into creating modern architecture suitable for digital business.
The views expressed are my own and do not represent any organization. I aim to have respectful discussions that further positive change as we navigate unprecedented technological transformation. Change is constant, so my perspective may evolve over time through learning, testing, and adapting to new information.
