An Approach to Application Modernization: Planning & Design Phase

Modernization is a team sport where end-user, line of business, and IT systems need to come together with a single goal in mind, “ease of use and improving user experience.”

13 min readNov 30, 2020

By Ernese Norelus , Eduardo Patrocinio, Oliver Senti

This current installment is part two of a multi-series blog; we go deeper into applying the application modernization approach. It will leverage IBM Enterprise Design Thinking, Event Storming, Domain-Driven Design, and Event-Driven Architecture. We are drawing on an exemplary approach to the Garage Method to enable application modernization projects at scale by applying a compelling application modernization journey to the Cloud.

Why modernize?

Without a doubt, this should be your first question. “Why do I need to modernize my applications? What do I gain from this?”; modernization is a costly and risky endeavor. Frankly, what do companies gain from modernizing their applications aside from getting a big fat bill, incurring negative financial impact, and might not deliver the business value expected!

An actual modernization project is a transformative force for your company to remain competitive and relevant rather than a burden. All applications go through a lifecycle; modernization is a journey, not a destination. Your success is bound directly with your ability to transform and disrupt the industry and the competition. Application modernization is a necessary evil, where organizations must undertake at some point. They can be a myriad of reasons for you to modernize your application. Such as, the application no longer meets the organization’s needs or the application is going out of support. Deprecating end of life products with policy. You could choose not to update, ride the wave, cash in, and call it quits once you gain no more profit. Okay, I make it look rather drastic with a bit of sarcasm. There is a price to pay to remain relevant and competitive in a volatile market like all things, and you must be prepared to pivot when needed. You don’t have the luxury not to modernize, and else it’s like declaring bankruptcy if you can not compete with the agility of newer, leaner organizations.

In my experience, there are many wrong reasons for application modernization, don’t fall into the trap, such as: “I need to be on the latest technology, as everyone is going to the Cloud.”

Application modernization can be a technology-driven initiative, but such initiatives often fail if not supported by business objectives. Both business and IT must arrive at an agreed target architecture for this to be sustainable. Application modernization has to be part of the organization’s culture to gain the benefits that come with it. It must provide advice, guidance, standards, and controls for it to be successful. Here are my top three reasons for any business to go down the path of application modernization:

Create new business opportunities — “user satisfaction.”
Deliver applications and features faster with business agility and speed — “reduce onboarding time.”
Reduce the high cost of new features — “cost-effectiveness.”

By now, you would have realized that modernization is not an endeavor to take lightly, as it affects end-users, lines of business, IT systems, and IT personals who come to depend on the solutions to deliver business value. A poorly planned application modernization may not translate into improved business value. Thus, good reasons for beginning the journey with planning and design. The rest of the blog will do just that by walking you through our Garage Method approach to Application Modernization.

Modernization journey

As more applications are migrating to the Cloud, the IBM Garage provides a prescriptive approach to Application Modernization, starting with a business framing to review the business objectives:

Application Modernization focuses on delivering business value and addressing at-risk technologies. It’s a good idea to start with Business Framing; business framing is divided into five major parts:

Business drivers:
Initiative exploration:
Initiative prioritization:
Set up for success:
Follow up:

Application Modernization with Event Storming

The goal of application modernization is to refactor or rewrite for improvement/optimization a critical legacy system, a brownfield exploration of the business services or business processes. Here we bring to your attention an approach that has yielded much success with application modernization, leveraging on Event Storming and Domain-Driven Design. Event Storming and Domain-Driven Design have been extremely successful throughout the industry with the adoption of microservices.

Event Storming is a rapid “outside-in” design technique delivered in a workshop format to explore complex business domains interactively. It uses a visual and communicates business processes as a domain model in ubiquitous language, a synthesis of business modeling principles using Domain-Driven-Design, where the domain is defined as a sphere of activity or knowledge. The workshop focuses on domain events generated in the context of a business process or a business application. A domain event is something meaningful that happened in the domain. The workshop focuses on communication between product owners, domain experts, and developers. The process starts from the context of events happening in a domain and looks at events as fundamental elements in a model. The Domain model captures concepts and processes for a specific business domain and requires a deep understanding of the field in question. The best way to accomplish these requirements is through Event Storming.

Many of the concepts used during an Event Storming workshop are from Domain-Driven-Design; Event Storming focuses on an interactive, collaborative whiteboard exercise that engages all domain experts. In comparison, Domain-Driven Design is best at strategic and requires extensive training/practice to master the terminologies. Domain-Driven Design is best described as a software development approach to solving complex domain models; the solution revolves around the business model by connecting the implementation to the core business concepts. The common terminology between the business/domain experts and the development team are domain logic, subdomains, bounded contexts, context maps, domain models, and ubiquitous language as a way to collaborate and improve the application model and resolve any emerging domain-related issues.

Event Storming intends to uncover the underlying domains and the services and best used for:

Understanding greenfield applications
Understanding brownfield applications
Verifying new business process ideas
Assisting to find bloat or inefficiencies in processes
Understanding complex ideas or processes

How the Event Storming Process Really Works

An Event Storming is a collaborative, practical, hands-on scoping session that everyone can understand. The session is only successful if the right people are involved. Arguably, the most critical aspect of any project, not only in a modernization project. Select the team carefully and bring the business domain experts, customer executives, stakeholders, business analysts, software developers, architects, testers, and folks who support the production product. These should be the right resources, enthusiastic, and willing to embrace change, and able to work well in a team environment. It’s a great deal of investment that will yield a great return on investment. The session can vary from 2 hours to 5 days; all depend on how complex the system is and how much work is required. And another one of its unique features is that it results in actual output. And this physical output can be used as the basis to scope your microservices and start the incremental design process for your software architecture.

During Event Storming sessions, you will find there’s a lot of clarity gained on the end solution because there’s a lot of questioning and assumptions being resolved between people from different parts of the business. And with the development team involved, different if-then scenarios will be presented that the domain experts haven’t even thought of. And to keep the discussions within our Event Storming session in scope to the problem that we are trying to solve, it’s always useful to get the key stakeholders or the product owner to introduce the actual problem we are trying to resolve in the Event Storming session. And this introduction only needs to be brief. And here is a cheat sheet, which will help you carry out your Event Storming session in real life. This first cheat sheet lists all the key things you need to prepare for your Event Storming session.

We will be using a tool from miro.com, which provides a virtual whiteboard and virtual stickies. These are virtual stickies that never run out of stickiness. Another requirement for the Event Storming session is the role of a facilitator. This individual or team will be responsible for organizing the Event Storming session and ensuring that the Event Storming session conventions are followed during the scoping session.

Cheat Sheet:

The cheat sheet will help you carry out your Event Storming session in real life; it lists all the key things you need to prepare for your Event Storming session.

Domain Events

The first step of Event Storming is to plot events, and we need our facilitator to introduce this step. The whole concept around events is pretty straightforward. These are things that need to happen within our end solution. And these events can be anything that needs to happen within our existing system or our new proposed system. The convention has always been to use orange sticky notes for domain events, which we’ll do. We also need our group to plot the events left to right across a timeline to show the event’s order.

Events are activities in the domain / Events are immutable
They represent an action that happened in the past (past tense)
Because the action already completed, they can’t be rejected
Often broadcast to many destinations
Record a change to the state of the domain. Often the result of a command

Commands / decisions

Commands usually are paired up with events and typically represent an action, interaction, or decision that leads to the event it’s paired with. The convention for plotting commands is to use a blue sticky note. Command represents an action or a decision, this is normally either taken by a user or by the software itself. The idea behind plotting commands is to represent actions and decisions that led to an event and allow the team to question and debate what user or piece of software carried out the command that led to that event.

Commands are a type of activity that occurs in the domain.
Represents a request to perform an action.
The action has not yet happened, and it can be rejected.
Usually delivered to a specific destination.
Causes a change to the state of the domain.

External Systems

External systems within the Event Storming sessions by convention use a pink sticky note to show an external system. When we say the external system, this can be anything that we don’t have any control over. For example, an external third-party system could be an internal system that’s not currently part of what we’re modeling in the Event Storming session.

Separate system
Third-party or internal system
You can show commands received
You can show events emitted
Can also depict as a black box:
- Triggered by commands in your system
- In return triggers commands or events in your system

Policies / Business Rules

Commands that are preceded by something called a policy and are depicted as lilac sticky notes. Policies usually sit between an event and a command. Policies are that we’re forcing the team to think about all the events that need to happen before carrying out a command or a set of commands. One thing to note about the logic that the policies represent, sometimes the logic is explicitly known, as the organization knows all the events that lead to a certain command. Sometimes, the logic is implicit, as in it’s organically grown over time. People are not aware that these events need to happen before that specific command is carried out. And the idea behind plotting these in event storming sessions is to bring all this implicit logic out into the open and identify any additional events and commands.

How is our SYSTEM supposed to reach the given EVENTS?
Whenever EVENT then COMMAND
We need a LILAC between the ORANGE and the BLUE
Implicit policies: without an explicit agreement
Explicit policies: Assuming everyone is following them

Read-Models

Read Models allows you to plot any important data requirements. This allows you to emphasize any specific data requirements required to decide or carry out an action. This could be a specific part of a UI or a specific type of record which is required in order for the user to make a decision or carry out an action. We plot these data requirements as read models in Event Storming, and we use a green sticky note to plot them. The read model terminology isn’t very intuitive; it might be worth introducing read models within your event storming sessions where you present examples. A read model can include entire screens within your application, specific parts of a screen within your application, and the output of a report generated by your system. The output of a SQL query, notifications to a mobile app, basically anything readable that will help a user carry out an action or make a decision.

Data to help the user carry out a command
Aid user actions and decisions
Required data that could be anything.
- Data on screen
- Data from a SQL query
- Data from any data source
- Specific part of the UI
Can use scribbling of a UI wireframe
Use to highlight specific required data

Hot Spots

A hot spot is a place that needs more exploration, lack of proper knowledge.

Things that are not working as planned
Exceptions
Irregularities
Failures in the system

Aggregates

Aggregate is a crucial step towards scoping and identifying our microservices. The reason for plotting aggregates is that we have something to represent the data that the commands act on and have something to present the data related to the events that happen within our system. Aggregate sticky notes usually sit between command and event pairing sticky notes. In reality, the aggregate should really be seen as a data holder that holds many instances of that specific type of data, and it also has a state based on that dataset. Another key reason for plotting aggregates is that they bring together command and event pairings with other command and event pairings that act on the same data.

Data holder
Commands act upon the data
Emits events in response
State is consistent with the data
Pale yellow sticky
A noun for the name
Way of grouping commands and events

Drawing Boundaries — Context is King

An exciting stage of the Event Storming session is called Bounded Context, which consolidates and decomposes aggregates and boundaries around them. These boundaries will help identify the initial scope of our microservices. Before we start this process, the first thing we need to do is we need to remove the concept of a timeline from our workspace because the timeline has served its purpose in terms of helping us identify all the events that need to happen in our system end to end. When it comes to grouping our aggregates, we look at the concepts and the language that the aggregates portray and where there’s a clear relationship. We use that relationship to group aggregates together. The idea of using related concepts and related language to group things is sometimes known as identifying the bounded context. Using this approach, we identify a clear relationship between route and routing audit, and we group these together.

Timeline no longer required
Group related aggregates
Related by concepts
Related by language
Use boundary for microservice scope
Review boundaries before finalizing scope
- Decompose for performance
- Consolidate for transaction boundaries

Consolidating and Decomposing Microservices

The output that we’ve obtained from our Event Storming session for our microservices’ scopes. Other techniques and factors should be taken into account to consolidate further or decompose the microservices’ scope.

Let’s look at a banking process (understanding a brownfield application); we will take on a monolithic application and refactor it into a microservice architecture. Along the process, we might figure out which set of services might need to be retired. The Event Storming would have already help with which applications are critical to your business. Applications that support a particular line of business is one logical grouping for decision making.

Grouping applications based on a particular line of business
Particular architectures or technologies

The starting point of any Event Storming workshop is with an initial brainstorming where everyone writes as many events as possible at the same time.

Putting all together

The first pass was to create all the events (Orange stickies) from the Account Creation system.

Pre-created accounted
Account Creation Processed
Created Account
KYC_R Reviewed Info
Lead Requested
Stored document (reference in MongoDB)
Notified the customer via (Email)
Notified Customer on Negative Status of (KYC Checks)
Issued Debit Card
Customer activated DC
Send pin to customer
Request Received through Branch (BPEL)
Received and Verified
Retrieved (Pre-printed Cheque Book)
Generated Cheque (printer)
Sent Cheque Book to customer
Printed customer Name on Cheque Book
Validated Credit Details
Modified Credit Details

All the commands (blue stickies) plotted from the Account Creation

Account Creation Process
Create Account
Deliver Account Kit to the Customer
KYC_R Review Info
Lead Requests
Activate Debit Card
Issue Debit Card
Received and Verified
Retrieve (Pre-printed Cheque Book)
Generate Cheque (printer)
Validate Credit Details
Modify Credit Details

All the External System (red stickies) part of the Account Creation system

KYC Checks
Reference in MongoDB
Notified the customer via (Email)
Generated Cheque (printer)

All the policies (lilac stickies) part of the Account Creation system

IC Verification
Notified Customer on Negative Status of (KYC Checks)
Block Customer in the System
Modifying and Resubmit the Application

All the read-models (green stickies) part of the Account Creation system

Account Creation Process
Lead Requests

All the aggregates (black stickies) part of the Account Creation system can also translate into microservices.

Account Creation
KYC Checks
Request
Debit Card
Cheque Book
Credit Card

You’ve already seen how effective the Storming Event output is in identifying our microservices’ initial scopes. The next stage is for the development team to use this as a starting point to develop software that meets all the requirements identified in all the Event Storming sessions. This architecture they need to build will be built across weeks across sprints, and these initial scopes and initial contracts will be used as a guide.

Lessons Learned

Modernization is not just a technology change, but perhaps more importantly a culture, skills, and process change. Don’t just upgrade the technology without upgrading skills, practices, and culture.

Conclusion

Where does application modernization start? A successful application modernization strategy begins with the client in mind. For that, you need small and highly collaborative teams that work with the customer directly to produce a flexible product, high quality, and that can react to market demand quickly is essential.

In part three of a multi-series blog, we will leverage on IBM Enterprise Design Thinking, Event Storming, Domain-Driven Design, and Test-Driven Development. This is an exemplary approach to our Garage Method to enable application modernization projects at scale.

Co-author

Eduardo Patrocinio, Distinguished Engineer at IBM (Garage for Cloud)
Oliver Senti, Practice Manager of IBM Garage Singapore

References

You want to learn more about Application Modernization and its challenges and benefits. Please refer to the links below where you can find many reads on how to master the core concepts that can be adopted quickly and without spending months in trying to figure out “the right way to do stuff”:

Learn more about IBM Garage at www.ibm.com/garage