Last week, our Chief Architect Andy Medlicott discussed with us a few common misconceptions he’s heard around API design and implementation lately. It’s all part of a greater problem — developing with increasing complexities in a fast-paced and often changing world. Here, we discuss the solution to the problem: developing with Business Capability APIs.
What Exactly is a Business Capability API?
Business Capability APIs are an important level of granularity missing from many an enterprise API portfolio.
What are they, exactly? They’re the digital representation of your core business functions. They are used to expose resources ready to be used by API Products. Some choose to call them internal APIs, business APIs, or core capability APIs. If you’re working in a design-first lifecycle, you might see these as actionable API blueprints of your business capabilities. For this reason, within ignite, we call them Business Capability Building Blocks (see the gray boxes in Fig. A), as they’re typically grouped together to build larger API Products — although sometimes they can be consumed as is.
When you have each function singled out into plug-and-play design artifacts, you’re able to expose consumers directly to your business functions, rather than applications. So rather than calling monolithic strings of code when you really only need a small bit of information, you’re working with decoupled units that offer granularity and keep you free of the technical debt you get from spaghetti applications.
Business Capability APIs hold the greatest value of all your APIs
Business Capability Building Blocks are mapped to API Products and ready to be mapped to your systems. Developers can combine these globally visible building blocks with Third Party APIs and existing API Products to extend functionality for local relevance. They can opt to Reuse existing capabilities or propose new as new needs are discovered.
As your catalog gains more business capability coverage, your teams will reach an inflection point of speed, innovation, and possibility that will enhance the customer experience both, internally and externally.
You can group them together and wrap them up with third-party functionality for quick and quality API Products (see /Policy above, Fig. A) that will place you as the leader of your market. Our most advanced customers are well on their way to having an API for each of their best qualities.
What Constitutes a Business Capability API?
If you’re working in a design-first lifecycle, you might see these as actionable API blueprints of your business capabilities. Let’s take a look into the expanded browse view of ignite to explore the /Provider Business Capability Building Block.
Within ignite, business capability building blocks include business and technical details, such as:
- Production details
- Multiple capabilities (where else it’s being used)
- All of your endpoints (or whatever you wish to see/customizable)
- Additional classifications you wish to see
- Validation requirements (editable from this page)
- Documentation (this comes out of the box but can be altered)
Who is this kind of development for?
For organizations with ambitious digital, API Channel, and/or IT Modernization efforts (Cloud, microservices, AI, core system replacement & consolidation) the companies who need to provide direct access to their business capabilities without tying API users to specific applications — to those who need a greater system for API management.
Digital disruption depends on APIs, and the bigger your company, the more APIs you need. We typically see 400-2,000 capability APIs (far more in some industries, e.g. Payments), and as each of those have multiple (10-1,000’s) endpoints, it’s easy to see how complicated the logic can get in this brave new world — a world that promises to span a company to new countries, horizontal, and vertical markets that promise new complexities. So this is why we believe it is more critical than ever for the build to be more of an assembly for integration. So delivery is generated from design — developers shouldn’t have to handle the complexities of the new order.
Development driven from design causes a shift in the Developer role
With business capability APIs, developers are moving to a situation where, rather than having to code everything from scratch, they’re assembling existing building blocks that already check the boxes for security, governance, business needs, and proper classification. Because development driven from design puts the emphasis on implementation, rather than hardcoding to a platform, for the developer, it becomes more about integration; taking code snippets and plugging them in.
So there’s a shift in emphasis in what the developer role is trying to do. When you have a bunch of capability APIs that are well-designed and documented, you’re able to focus more on combining these modules and, choosing the implementation that best supports the initiative (API, messaging, events, files, etc.).
To some extent, the developer role becomes slightly higher-level. And that can be seen as a positive and negative thing. To that end, the difference is — you now have a clearer idea of what’s being asked of you. You’re moving to a world where your main purpose is reusing rather than building from scratch, so combining things, rather than inventing the wheel all the time. To scale, the modern API lifecycle treats Run as an extension of Plan, Design, and Build, and not the other way around.
Come back soon to read Part 2: Developing with Business Capability APIs: Pros & Cons.