The Pros and Cons of Developing with Business Capability APIs.
Note to Reader: This is a follow-up article to a previous post entitled “Developing with Business Capability APIs“.
Today we discuss the pros and cons of developing with business capability APIs, or internal APIs, with our Chief Architect, Andy Medlicott. For more on the design-driven lifecycle, visit Why Design, Why Now?
Pro: No More Drowning in Details
Perhaps the most significant pro is the ability to get ahead of the details. Developers know the detail is too much. Details are where bugs creep in. Take what we saw in the electronics industry about 65 years ago; you found it was possible to build so many things with transistors, putting them and other electronic components together on boards, and everything worked fine… but it didn’t scale. Then came integrated circuits (IC) which conveniently packaged common designs into a single units. Rather than having to know how everything worked in detail, you played with these components instead… and things were built quicker, were more reliable and were cheaper!
Unsurprisingly electronics and software are similar… software boils down to machine instructions and opcodes – over the years we introduced assemblers, operating systems, compilers for higher-level languages and shared libraries and modules, all in the aim of reducing the detail a developer needs to know to make something work!
Same with the shift toward microservices and containers — people appreciate having the ability to build more complex systems. Before, you might have had a library you’d build and compile, but now you have a container, so your system as a whole has many more components, yet it’s actually simpler to understand. To some extent, it’s the same with microservices — developers have more flexibility and room to build higher-quality APIs from these canonical building blocks.
Pro: Simplifying Unnecessary Complexities for Speed
Software engineers use components to develop software to put things in packages so you can reuse them; by not getting bogged down with all of the detail you’re moving faster. The same thing applies with business capability APIs. Life is a lot easier when your capability APIs already align to the business, they’re already encapsulated so you don’t have to become an expert in every area in order to fit into the overall plan.
Take an example Delivery API — its job is to say, “This is the address where X needs to go to. This is the content of the order that’s being made.” The API will return all of the details. Whether it’s a case of next day delivery, or etc… as a developer all you have to do is call the API, see the result, make a choice .. So you’ve immediately offloaded the need to understand the subtleties. You don’t need to know about the complexities of a delivery schedule in Hawaii (which can get pretty complicated, when you’re adding islands and air travel into the mix).
It’s much better to build from well-maintained capability APIs. Laws change in every state! Not only are people using your APIs now, but when the rules do change, you can change the version and update it in all of the systems downstream. This delivery bit is especially important to retail.
Con: More Generation = Loss of Control.
Not having the ability to tweak around takes some getting used to. But in truth, with this new lifecycle, tweaking is rarely necessary. If you lose the ability to tweak, what do you gain? In actual fact, you’re going to get far more accurate results. Which will be great, professionally. Because the quality of your designs are so much better.
Con: But it’s Not as Efficient!
True. But what is the price of efficiency? What is the real cost? If you’ve ever used an IC then you’ll know it’s rare to use all the pins or features of an IC – yet you still use it. Why? Because it’s far more expensive to make it custom. You might be able to use a lower-spec IC to get it a little more efficient – but efficiency can become an ideology or rather than engineering an appropriate solution.
Pro: Lighter Load for DevOps
Because API developers are more likely to produce better APIs, it makes the DevOps role a lot easier. The capacity for human error is significantly reduced, because so much is automated — the correct security is baked in, the right access is assigned, even the mappings can be automated, so you’re always calling from the exact right domains.
Many companies don’t give their Business Capability APIs the attention they deserve. (See the hidden complexity of APIs.) But for those who do, they’re seeing the benefits of having that immediate access to versioning and lineage.
Pro: Greater Alignment
Business Capability APIs are also helpful in that they are designed to always support the business goals; and in a great API design, that definition should always be included within the API metadata so it’s always clear what the API is achieving.
For example, sometimes the business reasons are different from the tactical — Say you know you want to get to x and you decide your own route. The tactical reasoning might tell you to turn left and turn right for the quickest route. But you might lose sight of the business reasoning — if that route is taken by a travel company, who wants to take a scenic route for customers to see the greatest sights. Or for a company like UPS, who wants their drivers to only take right turns to save money.
By enabling people to concentrate on a business goal, you’re more likely to get it right. This pattern is just where software engineering is going. It’s only recently that that’s become viable. That’s a change ignite’s supporting. It’s not so much about the APIs — they’re just a means to an end. The API itself is not the end goal. It’s the advantage of always taking a business focus, rather than taking the very technical implementation.
Con: Yet Another Change
Adapting to change is never fun. We get that. But, with the industry changing as quickly as it is, how can we not change as well? These days the SDLC looks different every year… it seems every few months a new enterprise architecture pattern is recommended, and these paradigms are changing quicker than the organizations are able to onboard them. The good news is, if you’re coding from design, you can adapt quickly to the next coding language, or new technology — you’re still able always use what you’ve done before.
Pro: You’re Faster and Better at Your Job, With Better Lineage to Report it
The design-driven development lifecycle might be a change to the way you do things as a developer — though it’s the way it you always felt you should write software, it was just always too time-consuming! The fact is, you can now do your job much more effectively and more complete. You can focus on delivering a really great experience rather getting bogged down in the details. And if you’re really set up right, you’ll have the lineage to report it.
Because APIs support so many digital touchpoints, you’ll be able to track direct value from the things you’ve built. Our ignite platform also tracks the amount of time it takes to get from proposed idea to runtime, integrating with Jira to report back the sprints, so developers are equipped with accurate estimates of how long it will take to build a new API or experience.
Want to know more? Have something to share? We’re always glad to start a conversation. Let’s talk.