Posts

Does your new purchase require extra resources

I want to share an observation that I’ve had while working with some of my customers. Whenever a business gets a new type of product, it often involves integrating a different component into their IT system. In the SAP integration world, there are a lot of new tools that you may want to add, which will need to be mixed in with your existing applications. Until recently, you have probably had only one ERP system, but now we’re starting to see a lot more systems — both cloud-based and integration tools, that need to be dealt with. And the question is, who is supposed to be maintaining these systems?

In my experience with customers, I’m not being called in because their in-house developers don’t have enough to do, I’m being hired because they have enough work already, and now the organizations are trying to figure out how to integrate new tools into their system while maintaining the current workload. Most of the time, there is a new tool that needs to be implemented, and people think that their developers should be able to continue doing what they’ve always done, plus magically deal with this new shiny object! But that’s not always how it works.

If you’ve been in this situation, and your organization has worked to implement new tools on top of the regular workload, please feel free to post about it in the comments.

Most of the time, organizations call in consultants to help figure out how to use a new tool, although it seems a bit strange to me that they would bring in someone from the outside to help, when it is the internal developers who know how the system works and who need to be able to maintain it.

About five years ago, one of my clients had only one developer maintaining all their integration work; but today, they have a team of four or more developers working full time to maintain their system, keeping the tasks up to date, etc. There are always challenges with more complex tools and new needs from the business that need to be considered and integrated. For example, if you’re getting API Management from SAP, you might logically think this is integration work, and would be aligned with the Integration Department. However, API Management is a different tool with a different skillset and a different kind of expertise required to make it work right. Consequently, departments need to carefully consider how this new component will work with existing components, and who is best suited to do the development and integration work of the new tool. Careful planning is needed to understand how you can best tie all the pieces together.

I have to put in a plug here: my company, Figaf, has a product called the IRT which we have created for testing PI systems. It is a new tool built to work with tools you already have. IRT is used in testing to help you figure out where new tools will best fit in and work together with your existing systems, and hopefully save you time and effort.

So, if you’re considering buying a new tool, please take the time to consider whether you need more people involved than the normal integration team so that the tool can be integrated into your current system in the best way possible

SAP Integration Landscape and Emerging Complexity

The field of process integration is changing quickly, setting new challenges for Integration professionals, and I think a good understanding of the available tools is key.

When we talk about paradigms in process integration, there have been 3 major phases:

  • Mainframes: Back in the day, most companies had one mainframe or two. The good thing about the mainframe was that it was fairly simple to integrate what were essentially internal programs – even if you had to work across mainframe platforms.
  • Client-server: With the emergence of client-servers and SAP R/3, the number of application servers was growing quickly. Suddenly, as an Integration Department, you had to figure out how to integrate the applications in your landscape so that you could create a new interface. In SAP terms, it may have been a Business Connector or eXchange Infrastructure (XI). You only had one tool to use.
  • The Cloud: Today, cloud integration is the norm, and the goal is to be able to quickly and easily leverage new cloud capabilities from existing development. A couple of examples of existing cloud capabilities are Hybris Cloud for Customer (e-commerce solutions) and SuccessFactor (human capital management).  There are also a number of non-SAP cloud applications. In fact, you most likely have some of them in your landscape already. As the integration expert, your job requires you to make them all play together seamlessly. Some come with prebuild content others you have to create for yourself.

As I said earlier, it used to be that you had integration consolidation that mostly worked in XI/PI. Now, Integration departments are faced with a very different landscape, driven by the need for new integration capabilities, and need to be looking outside of their space at the tools that are already available in other areas of process development. If we understand what’s out there, we can choose the right tool for the job.

I’m talking about tools like the HANA Cloud Platform – integration services (HCP-IS)/HCI, Process Orchestration (PRO), API Management, and Data Services to do bigger data ETL. We’ve also got the Application Integration Framework Overview (AIF), for when you want to do any integration with backend services. There are also SAP Gateway solutions available for exposing OData. Those are the SAP integration technologies that I can think of off the top of my head, other vendors have similar offerings that may be relevant.

I did this exercise with a customer and we spend 6 hours on the different topics and when it did fit into their architecture.

The big problem for the integration manager/architect is that you need to know the tools, and know when it makes sense to use one and how to select one over another. You also need to be able to train your team to use them. As you learn more, you’ll find a lot of overlap between the capabilities of the various tools, and knowing what each one can do will allow you to streamline your process when you have complex situations.

The challenge with all these tools is that it is both labor-intensive and potentially expensive to try them out. Say you have a situation where you want to expose some data to the user. First, you will have to figure out the logic and the capabilities of the various tools to find the best one to combine the elements so your API management will call  PRO or Gateway — to get or expose some data. Then you’ll need to acquire the tools and start using them, in order to really understand where they fit and what you can do with them. Once you get that down, you will need to work out how to leverage the technology internally. So, a lot of work is involved whenever you introduce new technology like this. You also have to keep in mind that you will be paying for licensing to use the tool, even if you don’t end up implementing it.

So as integration experts and enterprise architects, working in a rapidly changing field, we want to do our homework and really understand any tool and how we can leverage it before we place it in our systems.

What is your strategy for landscape integration? How do you cope with training problems?