As your organization embarks on developing software to solve its specific business problems, it’s critical to have an API strategy. This will determine how you choose to architect your solution and will ultimately have ramifications for how sustainable and extensible your system will be as it grows in complexity in the future.
You could choose to build a large, monolithic application that is designed to address one major business problem such as providing a way for your customers to order products on your new website. Alternatively, you could choose to break that huge problem up into discrete reusable solutions that can be employed in many different ways to solve many different problems in the future — some of which you may not have even thought about yet.
Your company would never build a skyscraper without a blueprint. Similarly, you should never develop your IT system without taking time to develop a strategy that carefully considers the opportunities and costs of various design decisions, not only in the short-term but more importantly in the long-term.
What Makes Up Modern API Strategies
Modern API strategies are built around the use of microservices, which are fine-grained, highly reusable, loosely coupled services that are exposed with lightweight protocols such as JSON. However, before your organization can begin to create microservices, you need to ensure that you are defining these services correctly. This means understanding, from a business point of view, what an API fundamentally is.
API Business Strategy & Architecture
In its simplest form, an API is a solution to a narrow, very specific business problem. Before you bring technology into the discussion, the key to building a successful strategy is to make these solutions small enough that they can become building blocks to address larger, more complex business needs. For example, your business might need a currency exchange calculator on an ordering page. As the customer is placing their order, they may also need the ability to auto-suggest a city and state from a zip code. Each of these things are discreet pieces of business functionality that could be used not only on an ordering page but also in other areas to solve other types of business problems aside from ordering. In this example, the zip code functionality could also be useful for setting up a new vendor record. The currency exchange calculator could be used to translate taxes incurred in another country into the user’s currency.
Notice that in this entire discussion, we have not yet mentioned what software language, framework, cloud service platform, messaging infrastructure, or database these solutions will use. Once the business has defined a family of simple, reusable solutions to address its various needs, IT can join the discussion. At this point, IT has a critical choice.
One way would lead them to build an ever-growing, monolithic application. In the beginning, this may appear to be simpler and faster to build but will eventually grow into an incredibly complex and interwoven beast that will inevitably slow down development cycles, make regression testing more difficult over time, and eventually begin to falter under its own weight as it becomes unmaintainable.
A more modern, agile approach would be to use microservices. This involves taking those simple API definitions that the business originally came up with and building small, self-contained services that are highly reusable.
Even data itself could become a reusable asset. For instance, not only could product records be used to list products in your online store but could also become line items on your customer orders. The concept of a product record could be encapsulated with a microservice that could define basic CRUD (create, read, update, delete) operations. This data could be encapsulated within that product microservice. Existing product data could be migrated to this new microservice to decouple this from the rest of your system. The key then is to identify other business units that could take advantage of this reusable data asset to solve other problems that you may not have originally considered. In our example, your product service could be useful as part of your inventory management system. Overarching business requirements like this become loosely coupled collections of microservices.
As you decide which of these paths to take, either choosing to build a classical monolithic application or instead going with a modern microservices approach, think carefully about common patterns and issues that signal the need for replacement with newer, more agile approaches.
A hallmark of monolithic applications has been the point-to-point solution. For example, if your code is built around the implementation of a particular set of queries to retrieve order data, it could be expensive to change if you switch databases or decide to store orders in a hosted solution. A microservices approach would encapsulate that complexity away from the rest of the system so that your order APIs don’t know or care where the product line item data resides.
These monolithic systems are also very expensive to upgrade. If you need to move to a newer version of your development platform, this is an all-or-nothing migration. However, with microservices this can be done API by API, significantly easing the cost and risk of upgrades.
Choosing to use microservices can also help to avoid the risk of developing monolithic code that could eventually become unsupportable because nobody is left who understands the intricacies of interfacing with an aging, fragile and unscalable code base.
While it’s tempting to start coding from day one without any sort of plan, there are large hidden costs that your organization will end up paying years down the road when that small system has metastasized into a thicket of code that takes far too long to regression test even for seemingly simple changes. The most successful businesses always have a plan. Shouldn’t your IT system also be architected with a well thought out API strategy that will ensure it can expand and grow to support your organization’s evolving needs?
{{cta(‘ff538d1f-1dd3-400d-92ec-1101b3a7f95c’,’justifycenter’)}}