Business Simulation Across the Landscape

By: Kamal Patel


If you’ve ever watched synchronized swimming, you can imagine the difficulty the swimmers have in coordinating their moves. That’s kind of what creating business simulation across multiple systems is like on a project.

When I was on a medical device project, I saw this in action. I’m no swimming coach, but am happy to say that, with advanced planning, we were able to successfully complete business simulations across systems. But that’s not to say we didn’t have challenges.

The Challenges of Business Simulation

Just like any project, we had our fair share of challenges, this time, they were particular to the business simulation portion of the project. Here’s what we saw, and you might too.

Some Functionalities May Not Be Ready

With so many systems working interconnectedly, you can’t always ensure that all will be ready to start your end-to-end testing scenario at the same time. For example, the business simulation might need to start at the end of the month, but some systems may not be ready to support until the following month. What can you do?

I recommend conducting a dry run one to two weeks before the business simulation to identify gaps and changes that weren’t migrated or to see where configuration isn’t set up accurately.

You may need to put certain scenarios on hold until certain functions are available, or you can create simulations with part of the process until everything is ready to be tested together.

The Data Isn’t In Sync

Data is a hugely important component for business simulation, but sometimes it’s not all lined up and ready for your simulation. Maybe the data couldn’t refresh or you couldn’t load it before the business simulation. Some of the data might be loaded into System 1 but not System 2, and if you execute a scenario, it will do fine in the first system but fail in the second. This can severely impact that simulation.

Make sure your team has all the data refreshed and loaded so that it’s in sync. This can be a challenge when you’re constrained by budget and resources, but leverage what’s available.

One way to kill two birds with one data stone is to load data as part of data conversion cycles so that you have data sync for downstream systems as well.

You Have Limited Environments

Some systems may not have a separate business simulation environment, and that can make it challenging to successfully complete a simulation when systems need to be running their everyday tasks. You may need to share a system, dividing its time between its regular day-to-day tasks and your business simulation project. This requires serious coordination and scheduling across teams and resources.

You Have Business Users Unfamiliar with the Process

When business users aren’t well-versed in the scenarios for business simulation, you may have to stop or readjust scenarios to help them. Test steps may be out of sequence, and that’s a disruption to the flow for scenarios to be tested end to end. 

The solution is to allow business users to complete and support testing in the dev environment. Feature integrated testing. Allows users to get their feet wet with functionality and the scenarios they will eventually be testing so that, when it’s time for business simulation, the users are confident in participating. 

There are Issues in Testing

In a scenario where there are 50 steps, you might find an issue at step 47. To test it successfully, you have to retrigger the whole scenario. You can’t start from step 47. Restarting the simulation adds to the timeline and can gum up the works. 

I’ve found that having a centralized and consistent simulation reporting structure, as well as a centralized team that coordinates the resolution of issues and communicates back to the testing team, helps defines good back and forth communication between the business testing and tech/functional teams resolving issues, and minimizes the disruption that these issues can cause.

Components of Successful Business Simulation

It’s important to define end-to-end business scenarios that need to be tested and validated. Without that, you’re running blindly across the systems and overall processes that need to be validated. To that end, there are both system-oriented and business user components to consider.

System-Oriented Components

Start by identifying everything that needs to factor into a business simulation, starting with what environment you’ll be testing in for the business simulation.

Look at the source and target systems and environments that need to be connected, either through middleware or any tool that’s leveraged from a connection standpoint. Do a tech dry run for each system.

Change order migration as needed. This may involve things like manual configurations or custom tables being migrated from dev to testing.

Also, work on data readiness and/or conversion. There are typically two scenarios here:

  1. You’re loading data into the system and publishing it down from source systems to target systems. 
  2. You’re doing a production refresh into the business simulation environment.

Also, schedule batch jobs, as automated batch jobs that run on defined schedules are critical. They should be running as they should be simulated from a production environment. An example would be delivery drops for pick, pack, and ship that need to run every 15 minutes, invoice jobs that should run nightly as part of the process, and various other sequential jobs that are required for the business to operate successfully.

Business User Components

In addition to system-related components, we also have those related to business users.

Security access is critical for business simulation. Each user profile/persona/biz role in the production environment should be replicated in the business simulation environment.

Identify the business users that will do the execution, as well as the tech and functional teams that support it.

On the medical device project, we were able to ensure the data was in sync across systems and could identify scenarios we could start testing, as well as systems that would become available in later business simulation testing cycles. But the success of the project was attributed to us being aware of those components and working through the challenges.

Share: