How to ensure quality from your SAP consultants

I was talking about the talking about the future of consulting/freelancing at my disruption training. One thing that we got to talk about was recommendations like as on TripAdvisor.

If you are going to hire a consultant or employee (for that matter), you just have to hope that your skills as judging the person are correct. And also their CV is accurate and has the skills to solve your problems. I’m sure there are some are terrific interviewer, but it may be challenging to find the best person for a job.

If you were going to hire me you would make obvious like to see that somebody has said something nice about me. I’m charging a premium rate compared to what is typically requested via requiters.

I have only been hired once where the recruiter asked for references from two previous clients. I’m not sure what is the normal way to be checking what is going on. The way this normally has happened is. I have asked “Hey John, I have a new project going on will you give a reference for me.”
He will then write few words of recommendation. Like “Daniel has been really helpful in our SAP PI project. He has been taking the lead and ensured our systems is update. ”

The problem with such a review is that my clients may like me for the person that I’m and how I’m helping them. The solutions that I’m providing may not be optimal and not live up to the promise that I gave or is telling them. In some cases where I’m helping with skills that are outside their expertise, they will not be able to tell if I did a good job.

There is the third party review as a second approach. Here either I or future clients need to pay another consultant to review the work that I did. He would need same skills as I have to be able to verify what I have done. It would probably to be the most reliable sources of review because it is judging the work.

Though it may have some challenges. How am I suppose to give third party access to what I have done and shown it the best way? In most contracts, I’m not allowed to share confidential data with outsiders. I have made some solutions that are not optimal if you look at them from an end perspective, but there may have been changes during the development that meant we ended up with some crap data.

A solution: Another way could we agree on two rates a normal and one for good work. For the first period, I’m at the standard rate. Then after two-three months, my client get a third party reviewer to go thru the content that I have made. And if it is okay I got the premium rate (paid back for the 3 months) otherwise we go for the normal rate. And the contact may end.
With this latter approach, I’m giving the client some risk reversal to ensure they only pay the premium if I’m really good. And most consultants would be able to wait for it.
The only price for this would be the third party review, which anyway would be an excellent way to ensure that you are making good quality.

I guess the topic of judging Quality will be in a separate post later. Be sure to connect or follow to hear about it.

How does Service Oriented Architecture (SOA) relate to the current world-view in SAP integration?

Service Oriented Architecture has undergone some interesting changes over time. It all began with CORBA, or remote procedure calls, and mainframes. Then came SAP, where you could call RFC remotely and build applications.

Later there was a trend toward object-oriented architecture and building applications based on classes. Where the focus was on objects and what to do about them.

Next came service-oriented architecture (SOA), and SAP’s contribution – Enterprise Services–where creating a sales order required certain components and a partner with certain other elements, and it all became a bit of a monster. SAP heavily promoted Enterprise Services, and any developer that needed to create an interface had to support the unwieldy SAP interface. This was challenging for providers to fulfill and for consultants to work with, because it required a lot of special development.

Later, OData emerged that brought a different kind of discovery protocol that allowed application to self discover content. It is different way of creating services and you would not see a common definition of what an order should look like.

Going full circle, lately we are seeing server-less architecture, like Amazon Lambda, for example. Server-less architecture allows developers to build functions that consume varying services, and in turn, applications can be built to leverage those functions. The smart thing, from a deployment perspective, is that you can create these functions to have all the resources you need, allowing you to scale your application in a different way.

Those developers who have been working in the field for a long time, realize these are all basically the same thing with different approaches and packaging, allowing companies to offer some cool features and be competitive.

From an SAP perspective, service oriented architecture is less desirable. Few developers today are using it for these sorts of purposes. Only a few companies are moving all their functionality to the SAP approach, such as Enterprise Services, which does have some more features than an IDOC.

But from a support perspective, it may still be relevant to use SOA. If you’re using IDOC already and are thrilled with it, continue doing that. But if you are going to build new interfaces, consider whether an Enterprise Service might be worth implementing. In SAP S/4, all interfaces are sent with the OData. All interviews are on the table, so that when data is exposed, it’s easy to read from your ECC system or S4 because it’s all OData on HANA services. OData is a protocol where the command is to expose data as web client data, rather than sending a service order and doing back end interactions. One problem with this approach is that it requires a technical function guide to drive it.

In general, people are habit driven, and we don’t want to invest a lot of time in figuring out how new things work. It’s the same with developers who don’t want to spend a lot of time figuring out how to do something in a new way, unless they perceive a clear advantage. I think this human nature is partly why we don’t see more people using Enterprise Services. Perhaps another factor is that Enterprise Services was originally released in small function blocks, which was an obstacle for developers who were reluctant to implement something that only affected a small subset of the business function they were working with.

As a developer there will always be new things and paradigms to consider. People will always say the have tried it, but now it is in a new context with new systems and concepts. So we will have to live with this change.

Always use PI/PRO for exposing web services

I recently had a long walk at the park trying to get my young son to sleep in his stroller. While I walked, I was thinking about a question I had this week from a potential client, and wondering about SAP integration, and whether or not we need PI/PRO, or if we might be able to use ECC for webshops instead.

The potential clients were doing web service, or a portal, and they wanted to know if they could connect with an ECC backend. I told them that’s fine; the conventional wisdom in PI communities has been that we want to make sure everything is governed through the PI, so we’ve used SOS services. This has been the mantra since I started with PI/XI, it’s been the standard approach.

Recently, however, I see that this standard has loosened up a little, and developers are exposing things in different ways. The first thing that comes to mind is Gateway, which is almost the same thing as using the PI, but enables you to access the ECC data directly using the OData and other similar operations. So Gateway is probably one of the more capable technologies.

We’ve also got solutions like API management, which usually goes through Gateway, or in some instances through PI/PRO. This is a bit of a change, which makes me think again about what the benefits are of using a PI. Obviously, you’ve got the element of governance — you know who’s calling the server – and you’ve got a way of exposing all kinds of different services to the outside world. In this case, the developers just need to worry about web services, and not about RFCs, proxies, or whatever you are calling on the back end. Other benefits include security and scalability, which allow you ensure that that the web service/front end, would not bog down the ECC system with too many requests all at one time. The PI allows you to configure that in different ways. Those are some of the good capabilities of the PI.

On the other hand, the PI is adding some latency to the web service calls, and the development process takes a little bit longer because it is more complicated to call through different layers.

So, ultimately, I guess people need to figure out what a project’s integration strategy is, and whether they have a PI or an HCI, and especially how they all fit in together. For example, if you want an HCI and are calling the ECC back-end, things can become a little complicated! With that in mind, in a lot of instances, it may even be possible to call ECC directly, and let the web guys worry about that part. Sure, as a PI developer, I would prefer to get this extra work, but if it’s not adding a lot of value for my client and it’s just me logging hours, I don’t know if I can justify using it.

What are your thoughts? Please share your input, so I can share with my clients.

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?

Retiring the SAP PIDocumenter and Diff tools

I have retired my documentation tools.

The reason is that they used an old form for documentation and SAP PI/PO did no longer support the use of XIM files. It was therefore not as much the tool was used anymore.

I have created a short guide to how you can export your mappings to an Excel sheet with NWDS. I’m not to found of the layout of it but it does support standard and also export UDFs. So it is an easier way to make the documentation.

How to document SAP PI/PO Mappings using NWDS