Throughout this series, we’ve been reviewing Ryan Craig’s Forbes article entitled The Biggest Tech Talent Gap Can Be Found In The SAP Ecosystem. After having reviewed some of the specific gaps and challenges surrounding this ecosystem, today we’ll turn our attention towards an alternative solution by playing some money ball.

Recreating SAP Resources in the Aggregate

In the movie Moneyball, Brad Pitt stars as Billy Beane, the general manager of the Oakland A’s — an American baseball team with limited financial resources. At the beginning of the movie, Beane is challenged with replacing several all-star caliber players on a shoestring budget. After much deliberation, Beane determines that these resources could not be replaced one-for-one. Instead, the front office had to come up with creative ways recreate these resources in the aggregate.

I believe the same basic principles apply when considering how to restructure SAP talent rosters. We get job requisitions from recruiters all the time that contain literally hundreds of requirements. We call these resources “unicorn” resources because an SAP product compliance specialist with 20+ years of experience working in a particular industry that also moonlights as an ABAP developer that has working knowledge of cloud and legacy technologies probably doesn’t exist — and if they do, their rates are probably way more than the customer can afford.

Practicality aside, one of our biggest frustrations with these types of requisitions is that they’re usually not reflective of what the customer truly needs. If the task is to build a web or mobile app, you don’t necessarily have to have an all-in-one resource that can build it all by herself. In most cases, a faster and more economical approach is to pair up an ABAP developer that’s strong with data modeling (e.g., CDS) and SAP Gateway with a web developer or two and divide up the workloads accordingly.

Breaking Down Barriers

Scaling these types of aggregations requires companies to break down the barriers that exist between their SAP COEs and the enterprise at large. Today, ABAP development teams frequently carry heavy loads because they’re usually tasked with building anything that touches SAP — web and mobile apps, interfaces, reports, you name it.

While it may be easier politically to keep all this development under one roof, it’s never really made sense from a practical standpoint. Most ecosystems understand and respect the differences in skillsets required to carry out specific types of development tasks. Going back to our web app example, it’s rare that other ecosystems would task one developer to build the web frontend (e.g., using React) and the backend services and APIs (e.g., using C# and cloud-managed databases).

The point to all this is that there are many benefits to be gained by maintaining a healthy division of labor where specialty resources can play to their respective strengths. Getting back to our scarcity of SAP resources conversation, this sort of division of labor opens up access to a much larger pool of resources — including non-traditional SAP resources.

Clean Core is a Technology-Agnostic Philosophy

While resource requirements for SAP S/4 HANA upgrade projects have put some of these talent gaps in sharp relief, it’s interesting to note that SAP’s clean core strategy calls for a shift in resource allocation that should (in principle anyway) alleviate some of these resource constraints.

Although most SAP materials will talk about clean core through the lens of technology solutions like SAP BTP, the reality is that the clean core concept is a technology-agnostic philosophy that’s not unique to SAP. In a nutshell, clean core calls for:

• An elimination (or at least reduction) in surgical enhancements — especially ones that use brittle, outdated, and proprietary technologies.
• Building extensions outside of the core system using open APIs and technologies.

While you can accomplish all these things using SAP BTP and other SAP proprietary tools like SAP Build, these types of solutions can also be built using 3rd-party platforms such as Microsoft Azure or the Google Cloud Platform. I covered this topic length in my From RICEFW to BEANS blog series.

Even though many of my SAP peers might call me a heretic, there’s absolutely nothing wrong with building cloud or low-code solutions outside of SAP so long as you follow clean core development practices. Here at Bowdark, we’ve had great success building these types of solutions for customers using Microsoft’s Azure and Power Platform technology stack.

Closing Thoughts

Getting back to our Moneyball example, the great news for customers is that you have choice in how you decide to address these talent gaps. While some customers may be more comfortable sticking with an all-in SAP approach, that’s not your only option. You can supplement your pre-existing SAP talent pool and recreate resources in the aggregate by dipping into other technology ecosystems.

This is especially true as it relates to the adoption of low-code development platforms. Here, you have the ability to really scale your SAP pro code developers using a fusion teams approach that unlocks collaborative, co-development scenarios with business analysts and makers within the enterprise. Collectively, these teams can accomplish a LOT in a limited time window while also pushing the envelope with innovation.

All in all, this is a fascinating topic and it’s going to be an interesting couple of years to see how all this plays out. As always, we’d love to hear your take, so please drop us a comment and we can keep the conversation going.