Businesses need a single source of truth and business efficiency demands connected processes. Today, end to end integration of business process is more important than ever. Driven by the need for rapid innovation that often out-paces corporate IT’s ability to deliver, business leaders are increasingly adopting cloud-based applications. But departmental adoption of cloud solutions can create “application silos,” breaking business processes and scattering critical business information across disparate cloud and on-premise systems. The challenge is how to support business’s needs to move quickly while maintaining the integrity of business processes across cloud and on-premise systems.
In today’s cloud-enabled world, connection is real-time, always-on and continuously evolving. Enterprises have to connect – and keep on connecting – in ways that classic integration architectures barely dared to dream of. Bottom-line is the integration landscape is changing. We keep hearing from our customers who want to know about this new era of integration-as-a-service and how this has changed the integration landscape. Our customers also want to know what if SAP offers any products or services to help with the integration process.
Here are some of the most frequent questions we are asked about how to manage these integration processes – and our answers. Chances are, you have the same questions now, or you might encounter these situations in the near future, so read on…
Are the integration challenges brought on by hybrid, and even all-cloud, deployments more complicated, or just different from those within on-premise environments?
Hybrid business processes have been built from a wide variety of software and other resources, which often makes integration with existing or new applications challenging. This is forcing vendors to think about providing integration capabilities as services that support this growing universe of internal and external business processes and components.
Historically applications were built, structured, and architected in very different ways and when people tried to knit them together, there was confusion, because there was quite a diverse set of requirements that needed to be addressed. And because there was a very wide variation in the underlying architectures in these applications, there was a need for a general-purpose kind of a middleware that could handle many different and diverse scenarios.
This process was further complicated by the fact that the middleware and integration often tended to come as an afterthought. Therefore, the middleware couldn’t really influence or inform the way the application platforms themselves were designed. This made integration more difficult than it needed to be. Meanwhile, customers discounted or underestimated the likely impact or complexity of the integration itself.
What we’re starting to see in this generation of cloud applications is a push towards integration strategies being designed upfront, with a more consistent overall application architecture that people can plug into more easily.
While traditional approaches were basically general-purpose middleware that had to do everything, the modern approach is specific and more application oriented. Traditional approaches were siloed, time consuming, and required you to have an integration competency centered infrastructure. All in all, it was a costly and complex process.
Now, for integrating cloud applications, which are essentially application silos, there is a need for a different approach—you need an Integration-as-a-Service solution. This approach provides a centralized integration engine that not only connects cloud applications, but that also provides a centralized means to manage, maintain, and govern the integration points.
This doesn’t mean that the previous integration approaches are obsolete. A lot of the underlying technology used for integration and many of the underlying concepts are not that new. It’s just that the way they are being packaged, presented, accessed, and consumed is different.
There seems to be two fundamentally different things going on here. One is the need to take integration to the on-demand or SaaS domain. The second one is the need to find a way to express and expose middleware and integration concepts in a way that they could be used by business analysts. These people aren’t necessarily technologists with deep expertise, but nonetheless, they have business and applications problems that can be solved through integration.
What do customers need to know about integrating cloud-to-cloud applications?
We are gradually feeling our way towards the concept of the federation of companies. When integrating cloud-to-cloud applications, customers should therefore ask questions such as:
- What kind of standard integrations are provided by the application vendor?
- What happens if I have issues with them? Whom do I go to? How do I manage that?
- How do cloud vendors work with each other?
- Who maintains and updates the integrations?
It is now important for cloud vendors to deliver pre-packaged integrations to help reduce the risk and burden of customers integrating their applications ecosystem, and to provide a consistent experience of support and diagnosis. For instance, there should be a consistent and centralized set of tools from vendors—such as diagnostics, reporting, metrics, error handling, and error tracking—that can be used across the many different types of integrations customers require. This will help customers have a more cohesive experience from vendor to vendor, especially as it relates to how and when they get support and updates. It’s up to the vendors to support this type of experience, as it is very frustrating for customers to call one company and have their support people tell them to call another. There should be some cooperation that allows vendors to help customers get to the bottom of any issue. For instance, we have pre-packaged integrations for business processes—which we maintain, support and upgrade—that allow collaboration between SAP and other companies. This alleviates many of these integration issues for our customers.
Is there anything within the SAP portfolio that could help, and if so, what is it?
As mentioned above, we have pre-packaged integrations between SAP to SAP applications and selected SAP to third-party applications. Unfortunately, there are thousands or millions of different types of endpoints out there. The integration technology from SAP can map any data format to any other data format, but that’s a trivial and uninformative statement, because it doesn’t help get a specific job done. To remedy this, we are identifying the categories of critical target systems and processes that would benefit our customers most and focus our integration efforts on those. For instance, we have already delivered full and incremental employee mini-master and organizational data uploads from SuccessFactors to SAP for on-premise payroll and finance processes, and bidirectional prepackaged process integrations between SuccessFactors and SAP ERP for Talent Management processes.
What’s the advantage of the SAP iFlows and how are they different from APIs? Are the iFlows the “prebuilt adapters” mentioned as being part of the SAP HANA Cloud Integration technology?
As more and more companies move to the cloud, real-time, comprehensive business process integration is critical. SAP is changing the game by making integration simple, fast, and risk free, saving businesses time, money and resources. We do this through standard pre-packaged integration content called iFlows. These are integration flows (iFlows) that have the transformation, routing, API calls, and logging information built right into the software to provide complete business process integration. iFlows are fully tested, supported, certified, and maintained by SAP. Customers have the flexibility to configure iFlows to suit their business process.
*EC-> Employee Central (SAP Cloud core-HR solution)
APIs, on the other hand, are gateways to our applications. Customers will not have any problems integrating their cloud solutions from SAP with third-party on-premise and cloud solutions, even if there aren’t any iFlows available. All our APIs are open and customers can choose which ones to use to connect to our data using our integration platform or the integration platform from any vendor.
I hope this blog helped answer some of the queries you have in your mind. If there are more, we would love to hear about those. So drop us a line.
Don’t forget to follow us on Twitter
- SAP Managed Tags:
2 Comments
