API Integration

Companies must architect and design their technology as discrete sets of digital building blocks intended to be reused. The “API Transformation” involves strategically deploying services and platforms for use both within and beyond the enterprise.

APIs are an attempt to control the chaos by encapsulating logical business concepts like core data entities (think customer or product) or transactions (for example, “place an order” or “get price”) as services. APIs are consumed in broad and expanding ways. What’s more, good API design also introduced controls to help manage their own life cycle, including:

  • • Versioning. The ability to change without rendering older versions of the same API inoperable.
  • • Standardization. A uniform way for APIs to be expressed and consumed, from COM and CORBA object brokers to web services to today’s RESTful patterns.
  • • API information control.

A built-in means for enriching and handling the information embodied by the API. This information includes metadata, approaches to handling batches of records, and hooks for middleware platforms, message brokers, and service buses. It also defines how APIs communicate, route, and manipulate the information being exchanged.

API’s are the next chapter in abstraction in terms of the way business uses technology to move faster, maintain agility, and leverage its own data. We are currently in the phase were companies expose APIs to allow their customers to access the capabilities of their software. This is the first layer of abstraction: the software vendor provides an API that exposes objects and processes within their software. The API is an abstraction layer on top of the application and the APIs they provide functions in the context of their application.

The next layer of abstraction comes from the layer between the systems and your business, with the focus on the context of the business itself. Systems that your business run on have their notion of a customer as an example. Each of these systems has its own definition of what a customer is that differs from the definition of a customer according to your business. The components of your business are ultimately unique to you and they can be modeled and exposed as APIs.

APIs allow businesses to abstract the definitions of these key business objects out of the underlying systems and make them available directly within the context of the business. Invoices then move from something you talk to the admin of the financial system to obtain, and turn into a common business object that can be consumed. This abstraction allows the rest of the business to interact with the core business objects rather than having to concern themselves with the underlying systems.