Does your organization want to increase the adaptability of an existing business model and reduce the time to market of the associated products?
However, do you face the challenges that come along with a (historically) grown, monolithic application landscape? This is the ideal scenario when agile approaches can add value – by definition. However, many agile solutions just describe a simple “greenfield” approach. Such an approach is applicable to the development of a genuinely new business model. What about the much more complicated case of an existing one, where planning and managing the transition becomes the main challenge?
A flexible and decoupled business and system architecture is the basis for building an efficient agile organisation (see Scaled Agile at Work: Efficient Team Orchestration). A decoupled system architecture enables teams to work technologically independently of each other. Decentralised business processes give teams the necessary decision-making authority to organise themselves. Hence, a promising approach must take both into account.
We provide you with an approach how to successfully transition from an inflexible monolithic to a vertical slice architecture which is flexible, decoupled and therefore enables business agility on enterprise level. To illustrate a real-life scenario, we will use a fictious case study and our practical experience from various transformation projects.
What are Monolithic and Vertical Slice Architectures?
Before going into the details of the case study we would like to briefly define what a monolithic and what a vertical slide architecture mean.
Monolithic architecture
A monolithic architecture integrates all application components into a single, indivisible unit. Typically, it involves large applications that centrally provide several closely connected functions. This leads to improved performance and simplified development, but less flexibility and higher dependency.
Vertical slice architecture
In a vertical slice architecture, an IT application is divided along business lines rather than technology. This division creates ‘verticals’, each focused on specific business features and use cases, delivering dedicated business value. This results in a strong market focus, flexibility, scalability, and reduced vulnerability to errors. On the other hand, convergence of functions increases, operational overhead rises, monitoring gets more complicated, and troubleshooting during interactions becomes more challenging.
Case study: Retailer transition to enhanced business agility
How to start the agile transformation journey?
The approach must ensure business value-based prioritization. The transition strategy must gear towards enhancing customer’s experience and economic impact. A gradual approach is preferred to ensure undisrupted and seamless day-to-day business.
The methodology that supports this is value stream mapping in which the relevant workflow step(s) that deliver the most value are identified.
In our case study the ‘Visit to Order’ step is identified as a crucial point in influencing customer purchasing decisions as it significantly impacts the customer’s perception and likelihood to make a purchase. By improving this step, the company can potentially increase customer satisfaction, sales and overall profitability. The prioritized goal is to make the ‘Visit to Order’ step more flexible, responsive, and economically impactful. This paves the way that eShop can adapt quickly to changing customer needs and stay competitive in the market.
The initial design of the transition architecture focuses on the decoupling of the ‘Visit to Order’ as a vertical solution from the other steps (see figure 3). Starting to ‘agilize’ one step only might be beneficial to learn from experience and improve before scaling. The initial, optimized vertical can serve as a blueprint for how the changes will be implemented and integrated into the existing landscape.
As a first measure, agile teams can be established within the clearly defined scope of the vertical solution. The gradual approach allows iterative learning, faster development, testing, and deployment.
The rest of the value stream will be further supported by the monolith. This ensures that the transition is gradual and does not disrupt the entire business operations at once.
How to manage technological complexity?
The construction and operation of the entire software stack requires high technological competence from the vertical teams.
Since other value stream steps are supported by the monolith, interfaces are required for handover points. The teams will need new development infrastructure for agile development of their solutions. Examples include cloud configuration, monitoring, and testing. Covering all of these disciplines in large IT environments like eShop would be overwhelming for agile teams of 5-11 members, both cognitively and capacity-wise. Additionally, as the remaining steps of the value stream will be progressively implemented by own dedicated vertical teams, similar needs will arise.
Therefore, the transition architecture is further refined:
- The layer beneath the value stream is renamed into ‘Customer Facing Solutions’ – these IT solutions directly provide business functionalities.
- A ‘common domain’ called ‘Platform Solutions’ is introduced. This domain consolidates solutions that offer IT support for development and operation to teams within the Customer Facing Solution domain. Dedicated teams will be established for this purpose.
- To facilitate interactions, the monolith is decoupled through an API layer, termed ‘Modularized Legacy Solutions’. These APIs are developed and maintained by teams consisting of developers from the monolith.
How to address redundant business functionality?
In the ‘Visit to Order’ value stream step, messages such as order confirmations or notifications of item restocking are sent to (potential) customers. Similarly, in later steps, messages like shipping notifications, invoices, and payment reminders are also sent to customers. When dealing with such a cross-vertical business function, there are two approaches:
- Independence with redundancy: Each vertical independently manages and develops its business solution. This approach strengthens independence but leads to redundancy and increased coordination needs for ensuring a consistent user experience and compliance. It also necessitates alignment on the underlying data model and business functions across domains.
- Centralized business platform solutions: Business-context-specific solutions remain as ‘Customer Facing Solutions’ within the verticals. Business-agnostic solutions are outsourced to a ‘Common Domain’ named ‘Business Platform Solutions’. Templates for these can still be provided by each vertical. This approach slightly limits the independence but reduces redundancies and leverages synergies.
For the case of message dispatch mentioned above, eShop’s architects opt for the second approach. They establish a ‘common domain’ called ‘Contact Management’. For this and other cross-functional business solutions (e.g., reporting), a new domain named ‘Business Platform Solutions’ is introduced similar to the approach for technical cross-functional solutions.
How to handle cross-domain business logic?
At eShop, customers are assigned a ‚Customer Category’ based on their purchasing behaviour and Customer Lifetime Value. This globally defined customer attribute impacts business functionalities across the entire value stream, such as pricing, delivery speed, and payment options.
Such horizontal dependencies, inherent in the business logic, cannot be resolved through verticalization alone but require overarching management.
eShop has decided to introduce a new role, the ‘Value Stream Owner’, responsible for identifying and orchestrating such business dependencies. In collaboration with the architects in the verticals, it is determined how and when, for example, Order Fulfilment knows about the delivery speed appropriate to the customer’s ‘Customer Category’. The corresponding business solutions orchestrate features of the verticals and the ‘Business Platform Solutions’ domain.
To ensure the end-to-end operability of the processes and use case models derived from the value stream, we assign the following activities to the role ‘Value Stream Owner’:
- Identification of cross-domain business logic along the end-to-end customer journey,
- Definition of steering logic and data for cross-domain business dependencies,
- Alignment about an overarching data model and definition of interfaces,
- End2end monitoring, e.g. via shipping times per customer service level.
All the measures described above enable the agile transformation of the first step of eShop’s value stream. Insights gained from its implementation would be fed back into the model, facilitating the successive transformation of the remaining steps.
Our approach at a glance
Based on the above outlined challenges and derived solutions, we advise the following approach:
- Articulate the rationale. Define the vision and business value of the initiative, and ensure top management is committed to the transformation.
- Select a market-oriented value stream. Choose the value stream with the highest urgency for action. If not already identified, start by identifying the value streams.
- Identify the optimal step(s) in the value stream. Find the step(s) with a favourable balance between contribution to goal achievement and technical change effort.
- Establish solutions:
- Customer Facing Solutions: Specific business defined solutions enabling a particular value stream (step).
- Business Platform Solutions: Generic business solutions used across multiple value stream(s) steps from the Customer Facing Solutions.
- Development Platform Solutions: Cross-functional technical solutions supporting business design and development (LOW- and PRO-Code), verification, validation, and operation in the upper domains.
- Modularized Legacy Solutions: Parts of the monolith provided to other domains, aiding in its gradual decoupling and replacement.
- Manage cross-domain business logic. Establish responsibility and capability to ensure the end-to-end operability within the value stream.
- Assign solutions to agile teams. Based on the solution categorization and requirements.
- Start with the first value stream step(s). In each development iteration, ensure existing functionalities work with new components. Inspect and adapt the architecture and process organization. Scale horizontally, reviewing the upper phases.
Our approach leads to a significant organizational and technical change.
A sustainable implementation requires an invest into technology and, above all, in employee expertise.
The transition itself must be implemented in a separate (agile) initiative with the relevant initiative owner, requirements engineers, architects, etc.
Conclusion
A vertical slice architecture serves as the cornerstone of an agile organization, and it should be carefully planned before initiating any organizational transformation.
To achieve meaningful results without overwhelming the organization, a structured, gradual approach is essential.
Our best practices emphasize transitioning incrementally, dismantling the monolith step by step, and eventually replacing it with a more flexible architecture.
In this blog, we’ve discussed the transition to a vertical slice architecture within the context of an agile transformation, focusing on a single value stream. This approach allows for agile, business-driven innovation, minimizing disruptions while maximizing adaptability.
Moving forward, we will explore how this methodology can be applied to multiple value streams in larger enterprises, further enhancing scalability and operational agility.
Support from top management remains fundamental to the success of such a transformation. Without leadership commitment, the necessary cultural, organizational, and technical shifts cannot be effectively realized.
