For large enterprises looking to mature their API strategies, role enablement across the API and Service lifecycle is key. In this post we’ll take a look at 2 API development strategy options – top-down and bottom-up – and provide recommendations on how to deliver a force multiplier for developers, architects, product owners etc., for each scenario.
The need for role enablement in a mature API strategy
If you’re a large enterprise, you’re likely focusing more on your API and Service development strategy, as part of a wider digital strategy, to support digital transformation and other digital initiatives.
The majority of large enterprises have laid great foundations for their API strategy, but are now looking to move to the next phase of maturity, also known as API Strategy 2.0. This involves building and delivering APIs at speed and scale, where those APIs are discoverable, reliable, reusable, and compliant.
A key factor in enabling this move to API strategy 2.0 is role enablement in the API and Service lifecycle, and utilizing this to ensure your catalog of APIs and Services expands in the correct way.
When we talk about role enablement in the API lifecycle, you may automatically think of API provider/developer enablement, which of course is important for speed and scale. But to become a digital leader, you need to extend the API and Service lifecycle, and take an approach that empowers multiple roles across business and IT for a collaborative enterprise, where multiple roles are providing and consuming APIs and Services at scale.
We’re typically seeing 2 scenarios for this vital role enablement:
- Top-down API and Service development – driven by business and IT stakeholders with a product or capability requirement approach
- Bottom-up API and Service development – focusing on developers building APIs in an environment that maximizes their efficiency and enables transparency into their work
It’s important to look for a solution that supports both these scenarios, and provides flexibility for the development approach which is right for your enterprise:
- You might already be starting to implement a top-down approach, but need to support existing bottom-up while you transition.
- You might be looking to ensure all greenfield development takes the top-down approach from the outset.
- Or, you might be looking to optimize bottom-up for the longer term, with future-flexibility to move to top-down if appropriate.
API strategy maturity isn’t only achieved by the top-down approach; it’s really about role enablement and optimization of API and Service development in whichever scenario suits your enterprise.
Supporting top-down API and Service development for role enablement
With a top-down approach for API and Service development, you can enable business and technical roles to work collaboratively in a plan, design, build and deploy-focused lifecycle. Top-down takes a business capability-driven approach that combines domain driven design and/or product-driven requirements, to align business stakeholders with developers (and also alignment with other roles like analysts and architects as well as Business and IT value chains).
Moving to top-down API and Service development enables a multitude of roles, but it also requires a big mindset change – thinking of APIs as a platform for business transformation, and their own channel, instead of a by-product of individual projects/solutions. Your enterprise may well already be working towards this mindset.
In addition to the mind-shift, when utilizing a top-down approach to enablement, you need to be able to support the following aspects of your API and Service lifecycle:
- API and Service Discoverability and Coverage – business and technical users need to be able to understand what APIs are available, and what coverage the enterprise has
- To enable this, we recommend abstracting your APIs and Services into a set of Designs and Specifications within a holistic catalog, tagged to classification taxonomies
- And have rich metadata including owner, region, lifecycle surrounding each API and Service
- Enterprise API roadmap – proper prioritization and estimation
- To enable this, we recommend using target state Designs to create a visualization of what your new APIs/Services will eventually do (i.e. their functions), attached to versioned Specifications of the real implementations
- Information model management – consistent payload data structures for new APIs and Services
- To enable this, we recommend enabling developers to use approved model objects from information model(s) to build request/response structures
- Automated API governance and approval flows – replacing manual processes
- To enable this, we recommend aligning all stages of the API and Service lifecycle to a governance model
- And provide commentary and change state tracking
- Legacy service modernization – make brownfield reusable via mappings, SOAP to REST conversion etc.
Supporting bottom-up API and Service development for role enablement
With a bottom-up development approach, you can enable developers to continue to work in whichever development environment they’re most productive in, and help make it easier for them to do so in a clear, consistent, well-governed manner (producing APIs which are reliable and consumable). But this approach can enable other roles too (e.g. product managers), because it can provide more insight into developers’ activities and the API and Service catalog as a whole.
When utilizing a bottom-up approach to enablement, you need to be able to support the following aspects of your API and Service lifecycle:
- Productivity and transparency – so that developers can continue to work in their most productive environment
- We recommend developers import their APIs (which have been built elsewhere) into a holistic catalog and organize by taxonomy classification
- And only allow valid swagger to be imported
- Compliance to standards and API governance – align APIs to an API governance model after import
- And provide an easy way to address violations without developers having to manually manipulate the code
- Driving reliability, reusability, and standardization
- Searchability of existing assets in the catalog – to drive reuse, extend/update and bundle before creating new
- To enable this we recommend enabling catalog searching based off metadata
- With reusable APIs and Services clearly marked
- Easy runtime deployment from the catalog – downstream integrations to CI/CD and run
- And enable up-front utility selection
- Future-flexibility of APIs and Services – abstract away from code
- We recommend abstracting objects in the catalog so you’re not hard-coding to one platform or framework, rather you’re abstracting into bundle-ready building blocks for future use
The ignite platform is unique in that it supports both top-down and bottom-up API and Service development
ignite offers a holistic API and Service catalog with extended lifecycle management, and is unique in that it can support role enablement through both top-down and bottom-up API and Service development.
How do you know you are successful at role enablement?
When assessing success in either API development strategy, there are a few key results which should be achieved:
- You have normalized code and faster deployment across your APIs and Services.
- APIs and Services are discoverable, reusable, reliable, and consistent
- You’ve provided an exponential force multiplier.
- There’s the force multiplier for the individual teams, but there’s also the exponential multiplier to the organization by looking at a catalog holistically and not only looking at it in terms of its workspace, impacted teams, or owners. By exposing the catalog holistically, all Services are viewable and transparent across the organization. Every team you bring has its own value-added, but the organization as a whole has value-added by that team being exposed and a new set of value can be brought by their Services.
- (For top-down): business and IT collaboration and business value chain alignment to API and Service efforts
- the APIs you’re delivering are no longer a hopefully good by product of a project, instead they are prioritized, planned, and delivered as part of that capability driven business value change prioritized initiative.
- (For bottom-up): Developers are using the environment they are most productive in, but you’re getting an alignment check (to the API governance model) as part of the process, and because of that, you’re not spending time chasing bugs or explaining to customers any inconsistent experiences.
Whichever approach to API and Service development you are taking, or would like to move to in the future, role enablement across the lifecycle and across both business and IT is critical to becoming a digital leader.
