How a Cloud-First Integration Strategy Helps Eneco Offer Innovative Energy Services and Cut Costs

Marco Verhoef, Cloud Integration Consultant at Eneco, has been in the consultancy field for 20 years. After working in the oil and gas industry at Shell, the semiconductor industry at NXP, and the electronics industry at Philips — before moving to the utilities industry in his current role at energy company Eneco — Verhoef has developed technical expertise in a number of functional areas. Drawing on his decades of experience, he has been generous in sharing his insights on cloud integration over the past few years, participating in several blogs, podcasts, and studies on the topic.

SAPinsider recently spoke with Verhoef about Eneco’s integration strategy and its migration from an on-premise integration server to SAP Cloud Platform Integration Suite as an early adopter. During the interview, Verhoef shared insights on how his team built a business case, key takeaways gleaned from the initiative, and how the business was able to save money by moving to cloud-based integration. Below is a summary of that conversation.

Q: What does Eneco’s current SAP landscape and cloud strategy look like?

We are currently starting a project to migrate to SAP S/4HANA, which we have been considering for a few years — if we should move and when. At first, the decision was a lifecycle one based on the end of support for SAP ECC in 2025. Since it can take two or three years to migrate an ERP system, we didn’t want to put the migration off for too long and end up paying double for support after 2025. Once the support deadline was extended to 2027, however, it became more of an innovation decision, and we then found another reason to make the move. We decided that moving to SAP S/4HANA would help us better meet increased real-time information needs and improve reporting.

Eneco has adopted a cloud-first strategy, and our landscape boasts many cloud applications from SAP, such as SAP SuccessFactors, SAP Concur, SAP Fieldglass, and SAP Ariba solutions. In 2017, we migrated our middleware from on premise to the cloud, moving from SAP Process Integration to SAP Cloud Platform Integration Suite. Then soon after, we moved our on-premise SAP ERP system to the cloud with Microsoft Azure. In a perfect world, our strategy would be only to have software-as-a-service (SaaS) solutions, but that’s not possible — yet.

Q: How did you build a business case to move integration to the cloud, and then get it approved by management?

In the on-premise days, we were operating in silos of SAP islands and managing different tools and systems, which was an expensive endeavor. There was no real architectural alignment like we have now. The only time we talked about the cloud was when we made jokes about “the clouds,” as cloud technology was a new trend that architects had just begun writing about in white papers. The first time we heard about SAP’s plans to bring middleware to the cloud was at a workshop in March 2014, and the offering was called “SAP HANA Cloud Integration” at the time. It looked user-friendly, and the cost element was interesting, so I decided to build a business case for management with some integration colleagues’ support.

During 2015, we presented a business case that addressed both the management and architectural levels, and it was mainly focused on cost. If you can show that you will save a lot of money in a year, leadership will be all ears and open to talking about the idea. It was clear from the meeting that middleware in the cloud was the way to go. Of course, we also emphasized the potential for time-savings. Using an on-premise integration server, and therefore having tedious and expensive release projects, was disruptive not only to the IT department, but also to business users — while IT had to upgrade all the yearly source and kernel changes, business users then had to go through all the test scripts and sign off on them. It involved a lot of communication, time, and effort, all of which would be eliminated in the cloud. The days of business users doing repetitive, time-consuming tasks would be over.

The next big hurdle was a successful proof of concept (PoC) to prove that the cloud integration tools could be used as-is and that all interfaces could be migrated. We started the PoC in 2016 with the support of SAP partner Proxcellence, which was very helpful because, through Proxcellence, we could directly access product development contacts at SAP in Walldorf without the need to raise a ticket. For the PoC, we covered about 70% of the technical objects used in interfaces running on the on-premise integration server to ensure we had enough evidence that we could start the project with success.

Q: Were any concerns voiced when you presented the business case, aside from wanting to see the PoC?

Security was the only concern raised. Leadership didn’t want the cloud solution to connect to the ERP system directly from the internet, so we had to find a cloud connector from SAP that would act as a web dispatcher to protect the system from intruders. After a few meetings with an architect responsible for securing the ERP system, we worked it out.

In 2017, we began the actual migration to SAP Cloud Platform Integration Suite. The testing portion of the migration required some extra effort — because many of the interfaces were related to finance and human resources (HR), we involved business users from those areas in the testing as well — and was sometimes more work than the actual programming of the integration flows (iFlows). We also started the project without the ability to migrate all of our 50 or so interfaces, but just before the end, everything came together. During the six months of the project, we would get monthly automatic updates to the cloud integration software that added new functionality. With these updates, SAP delivered the needed functionality and we were able to test all the interfaces live. In March 2018, once we had the cloud integration up and running, we switched off the on-premise integration server.

Q: Is integration becoming more of a strategic focus for organizations? According to recent SAPinsider research, more than half of survey respondents said their current integration strategies are ill-equipped to help them meet future needs. Why do you think that is?

It’s fairly expensive to build architectural lines, and maintaining the lines is even more expensive. If it’s a long-term investment, it will pay off in the long run, but some companies want quick cash in five years, so it depends on the company culture. Bigger companies, such as Eneco, seem to be aligned with a long-term strategy and profit from putting a lot of money and resources into a good architecture. If your end game grows 5 to 10 times bigger in the coming years, you have to invest; otherwise, you will never get that gross.

I think companies are starting to look at integration more strategically for many reasons. A major one is that companies are opening up their IT by putting a lot of application programming interfaces (APIs) on the market. They are achieving extra profit by exposing these APIs. For example, PostNL, a company in The Netherlands that delivers packages, has strategic APIs that allow big wholesale companies, such as Amazon, to easily communicate with PostNL about order deliveries. By promoting its APIs, more companies let PostNL deliver their packages. No matter what business you are in, you want to make a profit, and extending your business model is a new way of attracting customers.

Another example of how APIs can be used strategically is Eneco’s windmills, which send data every second to Eneco’s IT system via Internet of Things (IoT) technology. This data is then analyzed in Eneco’s IT system to identify statistics and determine predictive maintenance — turning a windmill one degree in some wind directions can save power and money, for instance. Using an API, Eneco could potentially open up this integration to non-Eneco windmills, such as those run by a small farm, for example. Eneco could monitor the data sent by these windmills and help that farm profit by providing analytics that can turn into cost savings.

Based on our experience, API reuse is an area with significant potential that deserves attention. We created our own API portal to standardize integration with our back-end systems, and it’s taking off now as people in other areas of the company are starting to reuse APIs in the portal. While we are not yet monetizing our APIs, that is something we are exploring for the future.

Q: Would you share a few key takeaways you learned from your experience implementing SAP Cloud Platform Integration Suite?

Because we were an early adopter, we had to figure out a lot for ourselves through trial and error, and we did come out of it with some important lessons to share.

Loosely coupled software services make your company’s IT agile. You can decrease vendor lock-in chances by having an API and event architecture in place so services are loosely coupled and can be changed anytime. Today, we have many SAP systems in our landscape, which is only growing, so while vendor lock-in is likely with our ERP system, we can change out all the subsystems at will. If lock-in is a risk you don’t want to take, I advise you to develop a risk matrix to evaluate your IT systems’ maturity and develop policies where needed.

Prepackaged content gives you a head start. SAP ships prepackaged content that includes components and building blocks to help you integrate with all of SAP’s SaaS solutions as well as non-SAP solutions. We have used prepackaged content to configure iFlows a few times, and it worked very well. For example, the prepackaged content for connecting an SAP SuccessFactors solution to SAP ERP includes the necessary mapping for all the fields in an Employee table, for instance. This eliminates a lot of administrative work — to enable the integration, you only need to make the connection.

Use a common data model as a basis within your company. When you integrate more technologies into your landscape, you have to ensure that systems can talk to each other and make certain that the business units using the functionality are speaking the same language. To achieve that, you need to analyze your company and create shared, standard definitions. When working in silos, there can be multiple definitions for what a product type in an order means, for example. You have to eliminate that as much as you can so that “order” means the same thing to System A as it does to System B, and everyone understands what all the fields mean within that order. Once you‘ve done that, integration is a lot easier, and no value mapping is needed. While the work to standardize data must start from scratch at your own company, it’s a good idea to look at how other companies are dealing with it.

Q: What measurable results has Eneco achieved from moving its middleware to the cloud?

From 2018 onward, we saved approximately $150K per year on costs, cutting down our IT spend for integration middleware to between 50% and 60% of our annual total cost of ownership. However, the most significant advantages were, and still are, the user-friendliness, the development speed and creativity, and the adoption by functional consultants and key business users. There are also many subjective benefits. For example, business users now monitor their own interfaces instead of the IT operations team, which has taken some tedious work out of our hands. Now, issues only come to us when a third line of support is needed for complex and interesting problems, and not when a standard SAP message alert is received saying that a financial posting period is not yet open, for example. Business users can now monitor those types of front-end transactions.

Q: Can moving integrations to the cloud help companies become more innovative?

It’s all about building a solid architectural base. Once you have that, the sky is the limit. People will have more time and flexibility and can be more creative about using IT to help change business processes and models and achieve new profits. Once you have a solid base, a common data model, a good API range, and a suitable defense mechanism — and the whole company speaks the same language — then many creative people can use that base for new ideas with the full support of the entire company. Business units won’t try to think of their own solution without looking at the existing architecture first. IT can help them find a solution, perhaps by sharing APIs that already exist. Integration tools are no longer just for IT people — they are also for business people who think every solution is possible.