We talk a lot about the goal state for enterprise API maturity here on the digitalML blog (and it’s a noisy topic elsewhere in the space too), but we’re also committed to demonstrating how you can actually get there with our ignite Platform.
Today’s article takes a proven use case from one of our banking customers (but is applicable to all verticals) and shows you how to move from complex application landscape to reliable APIs. We’ll look at 5 simple steps to making a complex change to a mission-critical application without affecting production APIs using ignite.
If you’d like to see the use case in action too, our recipe to manage complexity on-demand webinar is available to download.
Composability is the goal… but digital complexity makes it challenging
A composable enterprise is a target state for most large enterprises: business capabilities exposed as reliable APIs, Services, and Events, available to be rapidly combined and repurposed to support differentiated digital products and services.
If that’s you, you may well be working on maturing your API program and corresponding architecture; focusing on 3 key areas of digital efficiency, business agility, and IT modernization:
However, you’re also likely grappling with digital complexity, which can make moving from the “why” to the “how” quite tricky.
Complexity comes inherently as part of being a successful large enterprise (just ask our Customer Success Manager, Ashley Schultz, and Chief Technology Officer, Sayee Bapatla, who have recently joined from FedEx and Wells Fargo respectively and have seen these challenges first-hand)!
We’re seeing 5 levels of digital complexity affecting organizations:
- API sprawl – growing number and types of APIs across different platforms
- Complex IT landscapes that are ever-changing
- Complex ecosystems – changing providers, consumers, partners
- Complex API development lifecycles
- Ongoing technical debt (and the need to manage/minimize where possible)
And on top of that, you may well be balancing priorities in your API program: one one hand, the need to deliver projects right now, while on the other, the need to build out the digital design to deploy arm that gets you to your target state of composable building blocks.
ignite is a unique platform that can help with both of these priorities, all while tackling those 5 areas of complexity. We want to run through a proven specific example of just this: how you can use ignite to easily make changes to a mission-critical application without affecting production APIs and with no downtime. You can also follow along with these steps in our on-demand digital complexity webinar.
The use case: Put yourself in the shoes of a developer who’s new to the API team. Leadership have just made changes to the governance model, and it’s affecting a core application. You’re tasked with updating the Account Management Application API and are using the ignite Platform to quickly find and make the required changes. Let’s go!
N.B. We’ve taken this example from a banking customer working with Cards Technologies, but the use case itself can be applied to any industry.
Background: A connected relationship between the application reference model and existing and to-be-created APIs
Your enterprise architect started out with a unified modelling language (UML) diagram of the Account Management application. They modelled a bundle of APIs (each with their own set of artifacts containing documentation, metadata, methods, mappings, dependencies, business values etc.).
ignite has been used to connect this model to your API team and architecture, and the APIs that provide the functionality. The APIs have been aligned to the banking capability taxonomy and appropriate lineages defined in ignite. For more detailed background, download the ignite managing digital complexity guide.
Now it’s up to you to version our account management application from an existing API, and quickly make a change in a well-governed manner through a defined process.
Step 1: Find the API that needs to be updated
First thing’s first, you need to find the API version that needs to be updated. To do this, you can navigate through the banking taxonomy in the ignite Platform to find the Cards node. You find the appropriate Design.
Designs in ignite are an abstracted representation of the capability, and act as an umbrella for all technical representations (Specifications in ignite) of all formats (REST, SOAP, Event, etc.). This helps you understand what the API does, who provides and consumes the API, and how your change is going to impact other APIs or applications in the organization. Designs also help the business focus on the value the capability is generating, rather than the implementation they’re currently on.
You can see all the Specifications under this Design, and find the 2.1 version that’s approved for reuse. This is the one you need to version and update. Heading to the Specification (which contains all the technical and implementation details for the API), you can see that the governance checks are failing (due to the update in the governance model made by leadership).
There are two violations:
- One Method is missing an NFR (non-functional requirement)
- The security policy is not up to standards
Step 2: Understand data model and lineage dependencies for the API
Now you understand where the API exists and what it does, you need to understand the impact of making the needed changes to the API. You head to the Lineage tab on the Specification to learn how the Account Management App API exists against our architecture. You find out there’s an external call to an Account Management Service, and that our API relies on Account, ATM, Direct Debit, and Creditor Account APIs.
You can find further information on the provider/consumer relationships by clicking on the lineages, and you then bookmark this page so you can come back to it and update the lineages to the new API version.
Step 3: Create the new API version and implement the changes using a self-service governance and approval process
You can now generate a 2.2 version of the API. ignite will copy everything from the 2.1 version so you can go ahead and make the required changes.
The missing NFR and security policy can be added either manually or automatically based on your defined lifecycle process (ignite supports a configurable extended lifecycle). In the recorded walkthrough, this and the next couple steps were demonstrated manually.
Your updated version is now passing governance checks and ready to submit for approval prior to deployment!
Step 4: Generate proxy for CI/CD and Gateway, and track consumption and production changes with runtime integration
As you’re working with a core business capability API, it must be approved before it can be deployed. This helps the business ensure APIs pushed to production is compliant, complete, and consistent (although ignite’s governance is fully flexible and configurable, so this step may not be needed for all APIs). The Product Owner for the API gets notified and comes in and approves the API.
You can now push the 2.2 version through lifecycle states and deploy directly from ignite!
ignite’s feedback API can now take information from your runtime environment(s) and automatically update things like deployment record, lifecycle state, metadata etc. as the API is tracked and consumed over time.
Step 5: Update capability model coverage, data lineage and other clean-up for better experiences
Now that you’ve successfully created and deployed a compliant version of the Account Management Application API, it’s time to associate the lineage from before to this new version. This is quick and easy to do with ignite’s relationship builder.
Your 2.2 version has also been populated with the taxonomy classification, so we want to make sure any other users browsing the banking capabilities taxonomy tree finds only this latest version. Again this can be automated in ignite, but the process would be:
- un-approve the 2.1 version for reuse
- remove the lineage association for the 2.1 version
- remove the classification assignment for the 2.1 version
With this use case example, an ignite user can successfully make a complex change to a core capability API without affecting production services! The ignite Platform enables you to do so in a consistent and well-governed manner, with reduced overhead and increased speed. In fact, you can expect to design and deploy API versions 80% faster than following the equivalent manual processes this use case would normally involve, all while easily managing the complexity that comes with being a successful large enterprise!
The power of the ignite Platform for enterprises
ignite’s features and functionality have been specifically designed with large enterprises in mind. We understand API maturity is a complex evolution; that’s often different for each enterprise. If you have a specific use case you’d like to see in action in ignite, book a demo with us today.
