Bobby James – MuleSoft Solutions Architect – Devoteam S Platform

Following on from Dylan Jenkins’s excellent blog, “MuleSoft’s Centre for Enablement: Should Enterprises have one?”…

I was inspired to write a few words around my opinions and experience of working in an organisation’s Centre For Enablement (C4E) and, latterly, how I’m not enamoured with all of the advice around setting one up (and the cul-de-sacs it can go down if blindly applying some of its principles).

There’s much guidance on creating a successful C4E within MuleSoft documentation and external blog posts. Whilst the principles and the advice are correct, incorrect application of these processes to the wrong situation will always lead to the C4E team being blamed for any failures.

As seen in other IT disciplines, the process is doomed from the outset when any methodology’s key starting assumptions or requirements are ignored. One size fits all does not always fit all, so here are a few areas a C4E needs to be wary of.

API Monetisation

The blog “Turn your APIs into API$: Exploring API monetization with MuleSoft and Hypercurrent” was brilliant in helping me understand API Monetisation.

From my previous C4E work, the blog confirmed my thoughts on how we could monetise our APIs.

However, mulling over the principle, I came to a series of What If’s?

• Customers don’t buy an API. They buy a Service. Sure, if the API exposes the service for customers to purchase that wasn’t previously available, then the API has contributed to revenue, and the number of times it’s called can be monetised. 

However, I recently requested access to several API interfaces to be used within a Devoteam application. I was told we’d have to pay for the APIs (and it wasn’t particularly cheap). Given that this project was only a demonstrator with no funded budget, I declined, and the demonstration solution moved towards a free spreadsheet extract. 

We looked instead to automate through RPA. Hence, expense and work were done to expose these features via an API, but we didn’t want to pay for the service, so it may have been monetised, but it generated no income.

• Some APIs support cost reductions, and whilst cost takeout in terms of infrastructure, technical debt removal and licences can be measured against a new API(s), some reductions are less quantifiable. 

For example, a series of APIs can provide different fraud checks for a financial institution. The business outcome required is fraud reduction, but a deep dive into which check or combination of checks drove the outcome, should be done at the client application level. 

This assessment can bring further benefits for the financial organisation, but not down to the API level. (Again, the use of the service, not the integration method). Hence, monetisation of these APIs takes time and brings little rewards.

• One of the standard API strategies promoted is the API Application Network, which promotes the reuse of services across an enterprise, organisations, and business groups. The goal is to have a homogeneous integration solution across the estate. There is sometimes no direct external customer; thus, monetisation is directed towards service use by each group.

However, I worry that stakeholders are charged for the service when they have yet to use it directly. Then, due to governance, they could also be forced to implement a design, which, when costed, someone says, “You know what, it would be cheaper to do a file transfer directly to the target”. Before you know it, monetisation has now contributed to integration sprawl. 

Some may remember the pre-charging of data centre space, which partly contributed to groups having shadow IT (bad) and moving into the cloud (good).

Should you attempt to monetise these APIs? 

Well, doing so may be challenging but can be useful to understand usage and traffic, if nothing else.

KPIs / Metrics

The blog “11 best practices for designing a data-driven organization” was a significant source of information for me that focused on what KPIs and Metrics should be. My key takeaway was KPIs / Metrics must be used to help inform business decisions!

Mulesoft Catalyst directs the C4E to create KPIs/Metrics against business outcomes and lists potential measures. However, only considering yearly goals, those outcomes can change and be affected by outside sources not in the control of the C4E. I want to avoid going through each suggested measure and saying how it could fail. Still, if a project that needs to develop APIs as part of the solution falls behind in its delivery dates due to target or consumer application issues or resource constraints, thus delaying the deployment of the APIs into production, then a “How many APIs were deployed into production this year” is not a fair metric of the C4E.

Additionally, revisiting our fraud example above, the business outcome is reducing fraud. Many factors could contribute to reducing this, as well as specific combinations of assessments. However, if fraud increases due to an increase in customer base or a failure in one of the assessment applications, rippling down this failed KPI to the C4E misses the point entirely.

Sometimes a business outcome could be the refresh of the integration platform due to technical debt, such as a security drive or an end-of-life notification (not a specific cost reduction, for example). The upgrades must be made in this scenario, and time is the critical factor. Hence, the number of APIs moved into production could be a measure. However, if the legacy applications will not support the new interfaces, such that the old integration platform cannot be removed, the business outcome is not met, even if the KPI is met. Meeting this KPI brings little benefit if the APIs have no endpoint to connect to or have to compromise on the integration technique.

API Reuse

This is the holy grail of integration.

An organisation builds an API network to provide a series of basic services that can be reused across all channels. However, if the channels operate on different systems, primary keys and authentication methods, it’s a broader problem for the organisation to standardise these services than just API integration.

For example, telephone banking has existed longer than Internet and mobile banking. As such, user authentication methods have evolved, and intermediate web services have been placed in front of the mainframe, which often uses a different primary key. Hence, the APIs that provide services for mobile banking may not be usable for telephone banking. 

When you add in open banking and its need for consent management, it’s more likely that new APIs will be created to support heritage processes and systems.

Hence, reuse is highly affected by whether it’s to support new or existing services.

Conclusion

So when answering the initial question, Centre For Enablement – Does One Size Fit All? The answer is a clear no, and when starting on a C4E journey, you will make mistakes you only realise in hindsight.

The key is to stay focused on the overall goal of integration assurance, efficiency and homogeneity. 

In this blog, I’ve attempted to give caution as to how to avoid some common mistakes around API monetisation, KPIs/Key Metrics and API reuse.