James Higginbotham recently spoke at APIStrat 2016 in Boston, where he shared some insights into how enterprises are using APIs and microservices as part of their digital transformation processes. What does this mean for software architects in today’s enterprise? Let’s first look at the transformations underway toward a composable, modular enterprise. Then we will consider some of the impacts it will have on our day-to-day efforts as software architects.
What is the Composable Enterprise?
The composable enterprise is one that strives to capture business and technical capabilities as APIs, seen as modular components across lines of business. Apps and integrations are built upon these APIs by the enterprise for internal, partner, or public use. A composable enterprise combines commercial off the shelf (COTS) packages, SaaS platforms, and custom development to address market needs quickly.
Coming from a software background, I tend to think of it more like a modular enterprise with APIs that can be combined to create new and interesting solutions:
Capital One is one enterprise moving in this direction by releasing a few public productized APIs, with the rest remaining for private or partner consumption.
Moving Toward an API-Centric Architecture
Within the enterprise, APIs are traditionally viewed as bolt-on solutions. They connect internal systems together, or offer enterprise data to remote mobile or web apps. However, reuse isn’t the goal of an integration API, resulting in one-off APIs scattered across the organization. In a composable enterprise, APIs are designed first, becoming the outward-facing contract that hides all of the internal details:
Legacy systems can then be transitioned to a new architecture or replaced with a new solution over time. Whether you are wrapping a commercial product, monolithic application, or a microservice architecture – it doesn’t matter.
APIs Should Focus on Capabilities
APIs in a composable enterprise focus on delivering business and technical capabilities. This requires that we shift our thinking from databases and code to helping people achieve their goals. Users don’t care how we organize our database schema, what programming languages we use, and what the current hot server or client-side framework may be. They want to get things done and move on. As architects, we need to focus on both the business and technology – APIs are the key deliverable that is shared between them. Our API designs should focus on delivering desired outcomes, not just data.
Manage Your API as a Product
The traditional view of APIs results in APIs being treated the same as internal code, with limited access or visibility. Applying product-thinking to APIs requires a shift toward developer portals, self on-boarding of developers, and a customer-driven approach. Most importantly, architects must monitor API usage, making adjustments to the API product based on consumption patterns.
At the center of a product-driven architecture is an API gateway and management layer. The gateway routes incoming API requests to internal processes or microservices. The management layer provides security, role-based enforcement, rate limiting, and usage metrics. A variety of commercial and open source solutions exist to fill this gap. Tyk is an open source solution that offers a cloud, hybrid or on-premise option to solving this problem.
Want to Learn More About the Composable Enterprise?
You can view the slide deck from the presentation, available via Slideshare.
