Transform with Domain Model for successful Application Modernization

Why Domain Model baseline?

The application modernization services market size is expected to grow from USD 6.87 Billion in 2017 to USD 16.67 Billion by 2022, with Compound Annual Growth Rate (CAGR) of 19.4%. Technology and Service providers are scrambling to grab lion’s share of this market.

Application Modernization initiative starts with Application portfolio assessment, which identifies candidates for modernization. To continue the modernization initiative on these, there’s need for a baseline of the business capabilities that are present in these applications. Modernization is applied only to those capabilities that are relevant for the digital business vision of the applications’ customers.

Any transformation effort must ensure the current state functionality in the modernized application. Baselining the current state functionality is a pre-requisite for ensuring parity. Functionality is described in the form of documentation. Most of the documentation will be out of sync with the software, unless there is a software model that is a twin of software code. Software code is the best representation of the mental model of the functionality.

How to visualize and communicate business capabilities from the Domain Model?

Event Storming is a rapid design technique to visualize and communicate business processes as a domain model in ubiquitous language. Event Storming is a collaborative session of business and IT with a focus on business and business processes. The outcome of the session is a domain model. Steps involved in arriving at this are as outlined below:

• Storm out the business process by creating a series of domain events in the verb form stated in past tense
• Create the commands that cause each domain event, as active verbs that work on an aggregate
• Associate the entity/aggregate on which the command is executed and that produces the domain event outcome
• Draw boundaries and arrows to show flow

An example of a domain event

The commands that trigger domain events can come from any of the following:

• User action
• External system request
• Expiration of time
• Consequence of a domain event

Event Storming could be applied in scenarios such as big picture (Project Kickoff) or design level (DDD, CQRS/ES) or value-driven (Value stream mapping), retrospective (initial flow and improvements) or learning (for new hires).

How are the legacy systems modelled?

Legacy systems are designed with structured system analysis and design focused on data model, or object-oriented analysis and design focused on process model. In either case, the system behaviour defined as functionality is described in the form of documents.

• Business processes
• User stories
• Case models
• Module procedures
• Requirements documents
• Design documents

Most of the legacy applications maintain meagre documentation in multiple formats to help different departments.

How to develop business capabilities baseline for legacy applications?

A phased approach to this exercise is a must to iterate and improve the domain model over time.

Domain Events Mining

As business processes are documented rarely and not up-to-date for most of the legacy applications, I suggest couple of tactics before getting into Event Storming.

User Commands
User Interface (UI) commands are the major sources of commands in legacy applications. As a preparation to the Event Storming workshop, it would be good to complete the review of the UI and flows and document a draft business process as outlined below.

Document business processes as sequence of UI screens in a preparation workshop. Map all day in the life processes and all UI screens exhaustively. Append other sources of commands and events.

User, Background, Batch, External Systems, and Timer commands
Execution of the existing test suite will unearth the commands and events to the extent of functional coverage offered by the existing test suite. Typically test suite development, especially test automation suite is developed leveraging functional decomposition method, for maximum reuse of functions.

So, if an automated test suite exists for a legacy application, there will be higher confidence in commands and events coverage

Event Storming

Conduct the Event Storming workshop involving business and IT. Follow the guidelines outlined below for best results from the Event Storming workshop:

• Event Mining will focus on Process and Events. It will not focus on Data and Transactions
• Enumerated events provide an estimated coverage with confidence levels
• Functional events coverage is qualified with a confidence level of the domain experts
• Follow current system behaviour for functional events
• Enumerate the UI screens & Tabs
• Enumerate the command per UI screens & Tabs
• Enumerate the aggregates and document all the properties for each command
• Name the functional events reflecting your software model’s ubiquitous language for each command
• Name the events as past occurrence, verb in past tense
• Store the aggregate attributes and values in transaction audit stream
• Store the field labels and values in the functional event stream
• Maintain the relation between the modified aggregate and functional event in the same transaction
• If there is an ORM, store the aggregate in its table, functional event in the event store and then commit the transaction

Continuous Improvement

Execute business processes from preparation and workshop. Continuously refine the domain model with retrospective and learning.

Conclusion

Application design principles have moved from Data Model Driven Design (DFD, Data Dictionary, ERD) to Process Driven Design (BPM, UML) to Domain Driven Design (DDD) (Domain Events, Aggregates and Commands). Implementing Event Driven, Microservices architecture requires an effective domain model design. DDD allows modular design of the applications for agility, scalability, resilience and continuous delivery. DDD is a set of tools that assist in designing and implementing software that delivers high value, both strategically and tactically. Domain is the problem and Model is the solution to the problem. Domain Model is the organized and structured knowledge of the problem. Design is how the solution works. Effective design fulfils the business capabilities and provides competitive advantage by creating the correct software model of the mental model of the business experts. Steps to develop the domain model of the application:

• Leverage existing documentation to delineate the business functions, business processes, steps and tasks supported
• Perform product walkthrough and UI screens review and come up with a draft domain model
• Execute existing test suite and update the domain model obtained from the product walkthrough and UI screens review
• Conduct Event Storming workshop with Business and IT. For software product companies, sometimes customers know more than the current employees. Involve them where needed/
• Refine the domain model as you embark on the modernization journey

Business Capability baselining and their relevance for the future digital business is the next logical milestone for application modernization.