Skip to content

April 13, 2021

Taking a Fresh Look at Enterprise Business Systems

By IT Revolution
Example Wardley Map

A group of industry experts tackled the challenge of ERP updating as part of the 2020 DevOps Enterprise Forum.

This team (Pat Birkeland, Adrian Cockcroft, Damon Edwards, Chris Kernaghan, Courtney Kissler, Scott Nasello, Ron Olshausen, and Jim Sherwin) was primarily trying to offer guidance to enterprises about how they may think about the impact that digital transformation (DevOps, Lean, etc.) is placing on incumbent business systems (such as ERPs and middleware) within their integrated landscapes.

The team applied Wardley mapping to increase their situational awareness and demonstrate this approach as a tool to explore ideas, identify key themes, and hopefully communicate with senior enterprise leaders. As an example, the team looked at custom business processes (some should be standardized, others may need to be removed from the ERP), integrations, and automating business-process testing.

Most companies are going through some form of digital transformation, and most companies have an ERP. The intent of this document is to give practical guidance on how to think about your ERP in the context of digital transformation, knowing that it will not be one-size-fits-all. The recommendations are intended to be considerations, and leveraging Wardley mapping is a great technique for assessing what’s needed before jumping right to the recommendations.

What follows is an excerpt from the full whitepaper, which can be downloaded for free here.

ERPs Are Becoming One of Many Monolithic Systems Vital to the Enterprise

As organizations focus on digital transformation, the need for more flexibility and agility is critical for survival. ERPs are often on a twice-per-year release cadence, and change latency (time to value) is typically over a year. This is favored by SI partners for several reasons:

  • Low-cadence releases provide for a more stable platform for operations—this reduces the likelihood of service penalties for unplanned downtime.
  • Increasing the size of software deployments increases the need for testing—a service that SIs often supply to their customers.
  • The manual nature of operations requires several iterations of test deployments—these take time to conduct.

Due to the adjacent nature of the ERP teams to IT, they have been able to both avoid the changes from DevOps and miss holding their trusted advisors to account, resulting in bimodal operations with regard to change to their application environments. This is unacceptable in the digital landscape, and the need to be clear about the position and role of the ERP in the organization is becoming more and more important.

Much of ERP application testing continues to be manual, often performed by business analysts, end users, and SMEs. There can often be organizational resistance to decreasing the reliance on manual testing and more fully embracing test automation for a number of reasons.

While tooling to support test automation in ERP applications has progressed considerably, it is still in its early stages of maturity. Testing tools are powerful applications that are designed to take the place of the user. They contain many capabilities, and a lot of customers lack the people to use these tools effectively, both to define the tests and also validate that the tests work so they can be used.

ERP applications can also be difficult and time-consuming to test because of complex data dependencies (shared state) between applications. Functional testing of processing an order can involve synchronizing large data sets between multiple systems as well as running complex middleware for data transformations. A complex set of sequencing dependencies often exists between batch processes. Some of these batch processes may only be run infrequently, such as at month end or quarter close.

Manual Regression by Business SME Provides a False Sense of Security and Constrains Business Agility and Growth

Although testing an ERP is difficult enough, many enterprises are essentially manually testing multiple connected monoliths—ERP, HR, supply chain management (SCM), warehouse management system (WMS), Product—inside an integrated non-production landscape.

An integrated landscape needs to have all of the integration services running to provide a realistic test (middleware, batches, ETL, and triggered processes in the coupled systems). Frequently, the test landscape must be initialized to a synchronized state across the systems, often taking many days to achieve a representative environment to include third parties, such as third-party logistics (3PL).

Historically, when all applications were hosted in a client’s datacenter, the enterprise had various options to manage their IT footprint and schedule ERP upgrades/maintenance around their key business activities. In some cases an enterprise might upgrade as soon as updates are available, choose to defer an upgrade, or combine an upgrade with major configuration updates. As enterprises consume more public cloud services or use SaaS providers, their ERP is not the only consideration in setting the tempo of integrated landscape releases.

To remain competitive, enterprises have been rapidly introducing new architectural patterns (microservices, serverless, DevOps, etc.) and SaaS applications. The existing practices of end-to-end regression testing only once or twice a year are becoming less sustainable as other members (or SaaS providers) of the integrated landscape are dictating a need for regression testing many times per year.

The sum total of the collective change around the ERP means the integrated landscape will have to dramatically speed up their delivery or the enterprise will abandon the integrated landscape as the primary risk mitigation device.

Better architecture (loose coupling, feature flags, microservices, etc.) may address many issues but it will also introduce a new paradigm:

In contrast, the citizen model of integration refers to the process of democratization of integration workflows upending traditional approaches to data and application integration put together by general developers with no specialized domain knowledge driven by the demand for self-service from the business.

So, the core challenge for these enterprises remains: How will you absorb more change at a faster rate from SaaS providers, cloud infrastructure providers, and ERP providers if you continue to cling to manually creating non-production test landscapes and manual regression testing by business SMEs once or twice a year?

With a large number of changes in a release, software releases do not scale, the complexity of providing the defined set of changes increases, and the required testing evidence of successful development and trial deployments increases exponentially.

Increasing the frequency of releases and decreasing change latency requires new and modern ways of working. Many DevOps principles, such as feature flags, test automation, version control, dependency injection, microservices, and continuous integration/continuous deployment (CI/CD) pipelines, are only now beginning to be adopted by ERP application vendors.

Many ERP application developers have been working with variants of the same proprietary vendor language, like Advanced Business Application Programming (ABAP), for years. They may not have been exposed to modern software-engineering capabilities found in other developer communities and may have felt little urgency to adopt them.

Due to the nature of how SI partners operate within a company’s ERP environment, changes that increase the amount of work, potentially reduce the number of consultants and increase the frequency of changes are regarded with fear by the service-delivery management layer of the SI.

What if a Fortune 3000 enterprise recently implemented Microsoft Dynamics 365 Finance & Operations for their ERP as a SaaS offering? In this context, the vendor would operate the entire production infrastructure stack out of their datacenter, perform any code/configuration promotions, and tune and scale the database based on transaction volumes. The vendor would also monitor performance of the system and take action in the event of any high-severity incidents.

The client has no access to the production system except via standard APIs or batch. The client would be responsible for business logic and configuration as well as testing. System integrators are also involved in these types of scenarios but have to work differently because they may or may not have access to the production system.

An interesting aspect of this implementation is that Microsoft requires mandatory upgrades of the platform/system at least twice per year. The client has a very small amount of time in which they can defer updates, and then Microsoft will deploy the new versions. Traditionally, clients have been able to defer upgrades for multiple quarters, or even years, if they wanted to focus on delivering features, onboarding new subsidiaries, or pursuing legal entity or taxation schemes.

Because the provider is now dictating this cadence, CFOs/CIOs have lost a lever in running the company. In addition, because of the mandatory updates, the client has to test their entire connected enterprise applications landscape at a faster rate than before. So although we may not want to apply DevOps to operating an ERP, DevOps will require enterprises to absorb changes at much more frequent intervals.

As you move critical functionality to SaaS (Salesforce, etc.) and lose complete autonomy over software updates, how are you going to regression test all of your enterprise applications, middleware, and third-party integrations multiple times per year (or even weekly) when you don’t have automated testing, require tightly coupled non-production testing landscapes, and depend extensively on “the business” to do manual testing of business processes and reporting?

Wardley Mapping

Because we perceived that there is quite a bit of cargo-culting around ERPs, we investigated tools and frameworks we could use to address some of our key questions about ERPs, integrating with ERPs, and guidance we could offer to enterprises as they embark on digital transformation journeys. We were lucky to find that the work of Simon Wardley was very useful in helping us to think critically about ERPs.

Simon Wardley (a CEO in the early 2000s) was looking for a more effective way to lead his organization through a time of great technological change and industry disruption. He observed that corporate leaders tended to blindly copy each other (even though their context or challenges might be different). This would be similar to copying Garry Kasparov’s chess moves from one of his games and expecting them to work against a different opponent in a different match. Instead, he innovated an approach that combined economics, game theory, competition, and science. Wardley has applied his unique doctrine to a diverse collection of contexts: hybrid cloud, complex systems, behavioral patterns, the environmental risks of chemical pollution, developing novel computer systems, and managing companies.

Wardley maps are a way of diagramming the products/services/activities of an organization in a way that enables us to make statements about what is the case right now, what could be the case in the future, and what the consequences of actions we can take might be. Rooted in the fundamental needs of the user accessing the products or services, they provide a framework for understanding the situation that the organization operates in. This can support the development of a strategy to change the organization somehow; often the organization is a business, and we want to create a strategy to grow it.

Wardley maps (see Figure 1) are value maps (y-axis) that add evolution/maturity on the x-axis. Wardley mapping draws heavily on economics and game theory. The Wardley mapping process doesn’t develop strategy; the end goal is to create representations of the environment in which your organization or business operates, which can be used to increase situational awareness. The value of maps is not the artifact itself but the discussions and alignment possible by exposing assumptions, challenging plans, and making plans to pursue new sources of value.

Example Wardley Map

Figure 1: Wardley Map

The value of maps and mapping is that they enable a group of people to focus on user needs, what’s valuable (and why), and ultimately have deeper conversations about the current state and how the future state should be achieved. In this sense, the act of mapping is often more important than the artifacts that are produced by mapping.

The seven recommendations that follow were based on perceived general patterns of evolutions most enterprises should be thinking about:

  1. Reduce time to upgrade.
  2. Automate business-process testing.
  3. Refactor business processes for undifferentiated processes; relocate differentiated processes to systems of engagement.
  4. Use modern integrations practices.
  5. Use Utility ERP.
  6. Use utility reporting.
  7. Deliver unmet/undiscovered analytics value.
  8. Recommended Pattern of ERP Evolution

To read about each in detail, download the free It’s Time for…ERP Disruption whitepaper here.

- About The Authors
Avatar photo

IT Revolution

Trusted by technology leaders worldwide. Since publishing The Phoenix Project in 2013, and launching DevOps Enterprise Summit in 2014, we’ve been assembling guidance from industry experts and top practitioners.

Follow IT Revolution on Social Media

1 Comment

  • Travis Apr 19, 2021 7:41 pm

    Thanks for this - a valuable read! Took a little bit to get to the punchline....I'd almost suggest flipping the article, with the recommendations at the top and then a dive into how they were arrived at - with more discussion of the challenges/context following. One other suggestion would be to define the acronym "SI" before using it....looks like it stands for Systems Integrators but hard to say for sure.

    Reply

Leave a Comment

Your email address will not be published.



Avatar photo

IT Revolution

Jump to Section

    More Like This

    Progressive Delivery: A New Approach to Modern Software Development
    By IT Revolution

    Today’s technology leaders face a critical challenge: Software is now embedded in nearly every…

    Read Article
    Building High-Performance Teams in 2025: The Flow Revolution
    By Leah Brown

    Organizations face unprecedented challenges in 2025. Competitive pressures demand faster innovation. AI tools are…

    Read Article
    The 2025 Enterprise Tech Leadership Summit: Save the Date
    By Gene Kim

    This September 23-25, at the 2025 Enterprise Tech Leadership Summit (ETLS) in Las Vegas,…

    Read Article
    Historical Patterns in Enterprise Ways of Working: Key Lessons from Industrial Revolutions Past
    By IT Revolution , Jon Smart

    In a compelling keynote address at the 2024 Enterprise Technology Leadership Summit, Jon Smart,…

    Read Article