Welcome to Agile Development

Life has a way of throwing us curveballs. We can plan, forecast, and conduct due diligence—but chaos is always just around the corner. This is especially true in the world of SAP B2B eCommerce development. People from multiple departments at multiple companies have to come together with a clear, mutual understanding of the project. Sometimes, things just don’t sync up. What do you do then?

At Corevist, we have years of experience dealing with this kind of situation. By way of illustration, we’ll share a story that we call Cascading Complexity—how one simple request from a client snowballed within a complex system of dependencies.

It all started with a line-item discount…

Our client wanted to display a line-item discount. It was a fairly simple request—in fact, so simple that we’ve now made it part of our core product. In essence, this functionality would query SAP to find out what line-item discount was available to the logged-in user. It would display that discount in both our client’s Magento catalog and the Corevist  shopping cart.

Our client was under pressure from customers to display this discount information. Some of our client’s products sell on a commodity-type value proposition. Our client believed that customers were abandoning their carts and shopping at a competitor who displayed line-item discounts the moment the user logged in. From a business standpoint, it was a fairly urgent request to display the discount that was available to the customer. We jumped on it and started designing a solution.

…but line-item discounts aren’t that simple in global B2B eCommerce.

In B2C eCommerce, this kind of functionality is easy to achieve. The same discount is often displayed to every user. But in SAP B2B eCommerce, it gets more complicated. Our software has to answer several questions, in real time, using real data:

• Who gets to see the line item discount?
• Is the discount percentage different for different users or user groups or different products?
• When should the discount be visible? Always, or within certain windows?
• Where is the user based? Does the discount occur across multiple currencies?

A portion of the development work to support this functionality had to be done in the client’s SAP system. We worked with the client’s SAP team to define exactly what they needed to do on their end to help us create this promotion. We considered it due diligence, and we do so on every project.

Then we had to do some customization, because the actual logic presenting the line item discount was located in SAP. We wanted to transfer that to the web. In this type of scenario, the Corevist solution functions like a traffic cop. It interacts with SAP on the one side and the web on the other. Now we had to write some custom SAP code dependent on the customer’s SAP system. To pass that to the web through the Corevist app, the web team had to accept the discount values and handle the UI component.

If this distribution of development work sounds complicated, it is. But it’s par for the course in the SAP B2B eCommerce world, and we’re used to dealing with this level of complexity. We weren’t stumped yet.

First complication: We weren’t allowed to touch the client’s data.

We weren’t allowed to make any modifications, even to our own code, within the client’s SAP QA or dev systems. We basically had to build our code locally, do a screenshare with one of their programmers, and watch as their programmers keyed our proprietary code into the system, one character at a time.

It was an unusual request, but we understood the client’s concern. With billions of dollars of revenue passing through the SAP system, one misplaced character could’ve caused untold damage. The client wanted to protect their business processes, and we worked to support that concern.

Second complication: We weren’t given view access of the production environment.

Not only could we not write code in the client’s QA or dev environments, but we weren’t given view-only access of their production environment. The reason for this stipulation was the same as the above. There was simply too much riding on that code. It’s a legitimate concern, for sure, but it definitely encumbered our agility. When things went wrong (see below), it brought a great deal of complexity to the resolution process.

Third complication: Maternity leave!

We had defined the requirements with the client. We had designed the line-item discount functionality. Now we started building it. Somewhere in the middle of that process, our client liaison went on maternity leave. It was one of those “life happens” moments. We couldn’t have been happier for her—but we had to scramble to sync our teams from a knowledge management perspective. The client liaison’s supervisor replaced her on a temporary basis, and the project continued.

Fourth complication: SAP in flux.

We went ahead and built the discount functionality, working with the client’s SAP team. We tested it in QA, and everything looked good. Another flawless implementation, we thought. We went into production on time.

The next morning, we got our worst-nightmare email from the new PM.

The functionality was broken in production.

We rolled it back and investigated. We found out that in between spec’ing the line-item discount functionality and going into production, within the natural course of the evolution of the client’s business, the client had actually made additional modifications to SAP that this particular project team didn’t know about.

It was a communications failure within our client’s IT team. It reminded everyone involved just how high the stakes are. SAP is an enterprise system. There are pros and cons to that. Pro—you make a change, it’s available to everyone. Con—you make a change, it’s available to everyone! Unless every single team understands what the change is, any particular change could disturb the equilibrium of the entire SAP system.

Fifth complication: QA system wasn’t synced with production.

The QA system that everyone had tested on wasn’t refreshed to represent the reality of the production environment. Everyone was living the illusion that when we went to production, the line-item discount would work because it had worked in QA.

That wasn’t true at all, and no one knew that we needed to know. A crucial piece of information fell through the cracks in knowledge management.

Resolution: Agility in practice.

When we got that email, we went into firefight mode. We investigated immediately and formulated a solution. In the process, we found out that our client was actually pretty agile, too. The issue was impacting real systems, real people, real customers. We moved fast, and they moved fast. We got everyone together, and we solved the issue.

None of this was really a technical challenge—it was a communications challenge. On top of that, it was a communications challenge within a gigantic organization composed of many departments with their own concerns. Worse, this client’s SAP services were outsourced to a third party. In a sense, the communication landscape was far more complicated than the coding issue itself.

The Takeaway

At the end of the day, no matter what the paper, email, or design spec says, the only reality is the execution of the software in production. In fact, we failed that reality check. All along the way, the surrogates to reality, which we assumed were in production, didn’t accurately reflect production. We had never encountered an SAP system in such flux, or a QA environment that wasn’t rigorously kept up to date. Now we know, and we press our clients to know their systems and communicate the states of those systems to us.

We’re confident that we’ll encounter a scenario like this again. Business will always drive innovation. Our clients have to respond to competition, deal with business-related issues, and get rid of inventory. The whole website infrastructure needs to be resilient and agile to reflect the pace of change in the digital-first B2B market. Now, in this digital age, we have to rationalize all the calcified processes that businesses have developed which may actually impede innovation. As trusted SAP advisers, we take it upon ourselves to help our clients through this process—and Cascading Complexity was a textbook fire drill in this area.

It was such a simple request. “We need a line item discount. Let’s show the customer what that discount might be before they put it in the cart. In the cart, let’s give them last-minute validation of the discount.”

The realities of implementing that across borders, across technologies, with life rearing its head—that made for a pretty complicated agile development process. But with the right attitude, the right skillset, and open communication, we got it done.  

Featured image courtesy of Masa Sakano. Licensed under Creative Commons 2.0 SA.