API Strategy 2.0 for the “New Normal”: CEO Commentary
April 24, 2020| Reading Time: 4 minutes
The current COVID-19 pandemic has completely changed the way we interact with products and services, and as a result is pushing large enterprises to digitally transform in weeks-months instead of the years set out in many of their digital strategies. In this post, digitalML’s CEO Jeremy Sindall shares his predictions for how the next level of API strategy can help enterprises meet this urgency, while becoming flexible for however the ongoing “new normal” takes shape.
API Strategy: Supporting an urgent need for Digital TransformationCurrent circumstances make the future even more uncertain for large enterprises. A common theme we’re now seeing is a greater urgency for rapid digital transformation, as the world emerges out of lockdown and we begin to work out the “new normal”.
Just before the pandemic hit, IDC published some interesting research on how “digitally determined” most large enterprises are. They found that the majority (63%) are in-fact digitally distraught, i.e. lagging behind with their digital transformation. More so, only 12% of those that are digitally determined (37%) are at a suitable level of ongoing transformation.
Positivity during the current uncertainty can be difficult, but it does give us all the opportunity to step back, and think more strategically about what we could be doing better as we move forward.
It is widely accepted that APIs and Microservices are a key part of a successful digital transformation – whether you are building a transformation capability above your existing IT systems, or planning to replace them.
So, what exactly does an API strategy look like for a digitally determined enterprise, who’s flexible and responsive for ongoing transformation, and adaptable for whatever the future and “new normal” brings?
Scaling beyond API strategy 1.0The good news is that the majority of large enterprises are well underway with what we at digitalML call the first phase of their API maturity, or API strategy 1.0.
First and foremost, API strategy 1.0 involves a mindset change as to the importance of APIs. Next, we see the implementation of runtime API management systems.
Once these foundations are laid, your enterprise is most likely looking to scale up both the numbers and coverage of APIs (especially internal APIs), as well as extending the API lifecycle beyond developers to a wider audience (most notably business product managers) within their business ecosystem. However, a gap in the framework becomes exposed if you’re trying to scale up in a secure and consistent way, while maintaining speed.
API design/development tooling in 1.0 is usually comprised of basic code editors, where developers churn out APIs and upload them into the Source Code Management (SCM) system – enterprises usually have to pick either quality or quantity. To try and meet the scale required for the next level of maturity with this tooling and process approach, will inevitably result in inconsistent APIs that are not well-governed, and with lots of duplication of functionality and effort. This inefficiency not only builds up a new level of technical debt, but also slows down your ability to launch new digital applications – and vitally, be adaptive and flexible with the ones you already have. It also requires a huge developer task force –, which, at a time where a need for remote working means many corporate security policies have restricted the number of developer contractors (as they are not allowed to access systems remotely), creates a major issue.
Another key requirement for API strategy maturity is to be able to scale the API lifecycle beyond developers. To do this, SCMs are unsuitable to be the system of record – the API’s details are held deep in implementation-specific code, and therefore undiscoverable beyond the most highly technical audience. Some enterprises look to developer portals as the answer, but these have been designed for exposing only a few public-facing APIs and don’t scale easily to the number of internal APIs needed for the digitally determined enterprise.
Enterprises need a way to meet these requirements, to be able to rapidly mature their API efforts. This is where digitalML’s API strategy 2.0 comes in.
API strategy 2.0 leverages abstraction of APIs (and other types of Services) to enable:
- Rapid scaling of API development:
- across numbers and types of APIs (and Services) – from 10-100 Public APIs to 1000s of bundle-ready building blocks (reusable business and IT capabilities represented as APIs and Services)
- by widening the audience of APIs – throughout the enterprise and including Product Managers
- Organizing and normalizing APIs – to provide reconfigurability for reuse and lifecycle management
- A force multiplier for hard-to-find Developer talent – enablement for Developers through built-in governance and adherence to security standards
How do I get to API strategy 2.0?You may well now be thinking “this all sounds great, but my enterprise is some way off – how do I actually get to this so-called API strategy 2.0?!”
As discussed earlier, there is a clear gap in large enterprises’ existing frameworks which fails to meet key requirements: the API lifecycle upstream of CI/CD and runtime. The recommended approach to addressing this gap is to implement a platform like ignite, which combines:
- A holistic and abstracted catalog
- Management of the upstream API lifecycle
- Alignment of both catalog and lifecycle to a maturity model (governance, standards, security, business/IT taxonomies etc.)
In ignite, all Services are managed as Designs and Specifications that are abstracted away from any particular coding format or runtime specific implementation code. They are normalized (i.e. conform to enterprise standards) and organized into different Service types.
Examples of Service types include:
- Reusable business capability building blocks (e.g. Payments and Account management).
- System IT building blocks (e.g. secure sign-in)
- Third party building blocks (e.g. partner APIs)
A much wider group can see what APIs/Services there are, how to use them, who owns them, and how mature your coverage is relative to your business capabilities.
With this in place, it’s fast, easy, and safe to reconfigure and combine different building blocks in support of new applications, and to modify services used by existing digital applications.
The Specifications contain all the technical information for the API/Service and are detailed enough to be directly used to generate code artifacts that are normalized, consistent, and comply with all of your coding standards (e.g. security). These runtime-ready artifacts are deployed to your SCM and into the CI/CD pipeline.
For more about the ignite Platform visit our platform page.