In my previous blog, I discussed the challenges enterprises face in the “age of empowered customers,” and existing architecture’s inability to address Digital needs.
To digital, enterprises need emerging architecture and programming styles that enable simpler, adaptive, intelligent, secure and customer-centric solutions.
A future state solution should:
- Enable seamless transition through channels
- Facilitate “context-aware” services
- Emphasize Application Program Interface (API)-first architecture and development
- Deliver elastic, highly resilient and secure services
- Contain “self-aware” services that detect, predict and self-correct system or service failures
- Be configurable and built on rule-based service assembly
An Ideal Future State Solution
Enterprises depend on data and analytics to drive business behaviors and decisions. Real-time access to information and actionable insights is a foundational requirement, that poses a challenge, however.
To handle both structured and unstructured real-time data based on customer context (location, time and space), enterprises need emerging architecture and programming styles that are adaptive and reactive. This level of agility is essential to consistent, constant and frequent delivery.
An ideal future state solution would be comprised of layers and key capabilities:
The Consumer layer is a gateway for channels and aggregates functionalities through composition and orchestration, mediation, and routing. Key capabilities are:
- API Gateway: a single point of entry for consumers to access back-end services. The service composition and orchestration is based on customer journey and context. This capability is provided by API Management platforms.
- State Management: manages state and transition. Control logic is decoupled from the user interface and managed at the Consumer layer.
The Business and Information Services layer is designed on “Micro-services” architecture principles:
Micro-services architecture offers advantages:
- Functional decomposition of services and clear separation of concerns
- Opportunities for evolutionary design by loose coupling and, conversely, high cohesion
- High elasticity – scaling of one service will not impact other services or the system
- Autonomous services designed and separated by “Bounded Domain Context”
- Flexibility to adopt the right tools and technologies for the job
- Ability to be developed and tested independently, as well as re-factored independently (reduces the technical debt)
- Designed for failures: fail fast, learn and recover quickly
The Event Management layer is built on “Reactive Architecture” principles that ensure event management is responsive, resilient, elastic, and message-driven. Reactive systems:
- React to messages concerning load failures and users, ensuring loose coupling, isolation, and location transparency
- Are scalable to react to varying loads so user experience is consistent
- Are resilient, reacting to failures so systems or services are “Always On”
- React to users and are responsive even under load or during failures
- Are asynchronous and non-blocking to request and response, supporting massive scalability requirements
- Provide a high level of concurrency
Additionally, reactive systems process events in real-time and batch. To understand why this is important, we’ll look at a banking industry use case. Customers view and search for recent and historical transactions on Internet and mobile banking applications.
Most banks still use legacy core banking systems, however, and retrieving historical transaction information and processing real-time transaction events causes overload.
To manage massive amounts of transaction history data, the emerging “Lambda Architecture” style is more feasible:
Lambda handles both real time and batch processing. With Lambda architecture, new transaction “events” or data are triggered in the channel or core system and sent to both Batch and Speed layers:
- Batch layer: manages the master dataset of transactions and pre-computes the batch views
- Serving layer: indexes the batch views so that the transactions are fetched in low-latency
- Speed layer: manages the real-time transaction event or data processing and computes real-time views for low latency access
An incoming query from the business and information services layer will merge transaction results from batch and real-time views. This architecture style is ideal for preparing and building context-aware data and serving customers based on location, space and time.
- Process Management: aligns with the customer journey, providing cross-channel execution of processes. It also provides visibility to customer activities across channels. An omni-channel integrated experience allows customers to initiate a process in one channel but complete in another.
A customer applying for credit cards or loans can initiate on any channel – a mobile app, for instance – and save to resume later on desktop. If the customer returns to the mobile to submit the application, the process should continue from where it left off.
For optimum customer experience and Net Promoter Score (NPS) the customer journey and business process must be intertwined.
Enterprise services/API’s and backend storage are provided and hosted on cloud, which can be used across multiple platforms. This architecture style called “Client Cloud,” enables enterprises to build capabilities on cloud environments. The key focus is user experience. Enterprises can choose mobile backend service providers (mBaaS) to manage user access, push notifications and provide storage and databases.
To continuously deliver business functions to customers, enterprises need true end-to-end Agile IT (DevOps and No Ops) and “new ways of working.” They must also adopt automation, cloud, continuous integration and deployment tools.
It’s important to note that architecture and DevOps are interdependent and cannot be isolated. Customer-centric adaptive, flexible architecture and design are critical to true agility:
In my next blog, I’ll describe a pragmatic and grounded transformational roadmap for enterprises, as well as future state migration paths.