Vijay Alagarasan is a Principal Architect for the Enterprise Architecture and Strategy department at Asurion, a leading global technology support and protection company (www.asurion.com).
As a principal architect, his focus areas are services, API management and integration architecture across different business units in Asurion. His contribution includes defining the vision, strategy, reference architectures, and reference implementations, patterns, principles, and best practices for services, API management and integration. He tailored some of the industry reference architecture and principles to the organization needs, through which it realizes full benefits. He closely works with other architects and development teams to drive services and integration in alignment with the vision.
Vijay is a hands-on architect. Before he joined enterprise architecture for Asurion he worked as a Principal Software Engineer, Senior Developer, Technical Lead, Solution Designer and Developer for Asurion, Cognizant Technology Solutions, and Clerysys Inc. He started his career as a J2EE developer and transitioned to a hard code TIBCO developer. He graduated from the University of Madras in Chennai, India with Bachelor of Engineering degree in Computer Science and Engineering.
His special interests include Enterprise Integration Architecture, Service Oriented Architecture, Microservices, API Management, RESTful WebAPIs, Containerization and Service/API Governance.
API Management Introduction and Principles Published: April 3, 2015 • Service Technology Magazine Issue LXXXIX PDF
Abstract: This article is focused on providing solutions for common problems faced by large enterprises implementing SOA when they try to transform digitally as the market demands. It covers pain points commonly faced by such enterprises, and how API management product capabilities can be used to eliminate issues. In addition, the article also provides a set of principles to keep in mind when implementing API management for an enterprise.
Challenges faced by the Enterprises as they Transform Digitally
Today, enterprises that have adopted SOA in the past want their information assets and capabilities exposed without any boundaries as they transform digitally. Change at the speed of innovation drives enterprises to be flexible, adaptable, and accessible, with varying levels of security. Product development teams are aimed to get the new products into the market within a few weeks, and are prepared to fail fast and go back. On the other hand, service providers are trying to meet those new demands and timelines.
Large enterprises are desired to transform digitally and improve their agility in responding to market feedback. They want to get new features into the market within a week or so, just like startups. Enterprises want their minimal viable product (MVP) out before their competitors, and deliver the changes/features incrementally. This style of working demands small independent releases and favors A/B experiments in order to keep up with customer satisfaction.
While experimenting with new techniques, they must somehow preserve their established market share and revenue streams that still run on legacy applications where the core business rules and processes are bundled.
Most enterprises spent their dollars building SOA platforms in the last decade or so, and some of them are still in the migration process. Most of them bought expensive SOA suites, adopted one technology and built large SOAP web services. As their market expectations shift towards MVP, fail fast and faster response to customer feedback, first generation SOA principles are getting compromised at the service layer and the room for innovation is pushed out by a myopic focus on availability and stability.
It's not just application-to-application or business-to-business communication anymore. Today, it can be between thing-to-thing, i.e. machine-to-machine. To meet such demands, the services have to be mobile friendly, for example RESTful Web APIs. Large SOAP Web services are not mobile or machine friendly.
Some of the common challenges and question asked are:
Now product teams are all of a sudden expecting service operations and development teams to do this, and of course, they don't express in technical terms. If they have not yet asked for your enterprise, they will soon ask for it.
So, how do we address these? It's not the best idea to solve these concerns for every service individually, or by the technology by which they were developed, or by the environment in which they were hosted. None of these options will drive consistency. It will become more expensive and will end up in more overheads to service providers and operations. Solving the problem may add more weight than the problem itself.
API Management is the Remedy
So, how do we enable the enterprises to reach their goals? An API management solution, which resolves these pain points in a centralized fashion, represents the Big SOA services as a slim-down API that has real, meaningful agility results. A range of enterprise-level API management solutions are now available in the market, like CA Layer 7, Apigee Edge, SOA Software, Intel Mashrey, TIBCO API Exchange, Microsoft API Management, etc. The enabling technology should at least include capabilities around:
API Management: Conceptual View
Each API management solution available in the market achieves these capabilities differently. Each of them has different logical and physical product architecture.
In general, there are four components:
The diagram below purely represents the conceptual view of API management.
It's a logical and physical entity that sits between consumer and provider (backend services). Service providers are not visible to the consumers anymore; therefore all transactions must pass through the gateway services or proxy. In general, gateway exposes the backend services, such as Web APIs. However, it's not limited to Web APIs; they can also mediate SOAP, JMS, XMPP, AMQP, and WebSocket services. These capabilities will vary based on the API product, so the right product should be picked based on the enterprise needs.
The key capabilities that it provides include, but are not limited to, the security, transformation, throttling, caching and routing. It separates concerns from service providers and allows the enterprise to manage them centrally. It also reduces cost for backend service providers and improves consistency across organizations.
API Developer Portal:
It's a self-servicing portal through which developers can register themselves to gain access to the Web APIs. Every API must be published to the portal. The primary goal of such a portal is to eliminate human dependency quickly onboard the known and unknown API consumers/developers. Of course, APIs should meet the consumer requirements for whatever product that they are aiming to build.
Some of the key capabilities that are accomplished by the portal are API Key Management, Consumer/User Management, Subscription Management, API Discovery, API Lifecycle and API Documentation.
Every gateway proxy or service must be hooked up with at least basic analytics. Most API products collect inbound and outbound metrics as soon as the API is published or enabled, which is essential to measure the API consumption trend. Analytics provide transparency around consumer behavior and the backend service behavior, and allows the API owner to proactively identify and allocate necessary capacity and resources based on the consumption trend.
API Development UI:
It's a user interface where the API services are developed, deployed, un-deployed and migrated. The API development UI, in general, comes with several built-in policies that can be configured to build services. Policies are building blocks for a gateway service. However, when there are no built-in policies available for a specific need, developers can also build custom policies.
APIs are required to be classified based on their visibility and scope. This allows for layout of a strategy, security, SLA, and to measure their performance based on their objective.
Applied Principles for API Management
For any new components that are introduced in software architecture, it's good to define the boundary conditions so that the solutions are implemented only for the intended purposes. This provides a scale to measure the solution quality and measure the criticality of the violation in terms of impact to the enterprise goals and benefits. Further, it enables technical debts to be logged and resolved as part of subsequent iterations. Likewise, there are 8 applied principles, which should be kept in mind when developing and implementing an API management solution for the enterprise.
API management found its space in larger enterprises to keep them moving towards their digital transformation strategy. It adds a buffer to the transformation process so that the organization can migrate gracefully.
In addition, an enterprise should also consider investing in a thoughtful API strategy. This would enable the enterprise to monetize their capabilities and information assets, driving innovation from the third party developer community via Open APIs.