SlideShare a Scribd company logo

Three layer API Design Architecture

•Download as PPT, PDF•
•
Harish Kumar
Harish Kumar

This presentation explains the three layer API design which organisations can use to get most out of there systems with less development and maintenance time spent on fixing issues as a whole in org.

1 of 13
The Problem Space • Every business need to integrate the above three actors and their engagement to systems for the best possible outcome
API-led connectivity: The evolution of SOA • While connectivity demands have changed, the central tenets of SOA have not, that is, the distillation of software into services that are well-defined, re-usable and discoverable • This problem lends itself to a service oriented approach in which application logic is broken down into individual services, and then reused across multiple channels. • Yet, the heavyweight, top-down implementation approaches previously noted are not a fit for the agility that today’s digital transformation initiatives demand. • Point-to-point application integration is brittle and expensive to maintain. Service-oriented Architecture (SOA) approaches provide some instruction in theory, but have been poorly implemented in practice. • The principles of SOA are sound: well-defined services that are easily discoverable and easily re-usable. In practice, however, these goals were rarely achieved.
API-led connectivity calls for a distinct ‘connectivity building block’ that encapsulates three distinct components • Interface Presentation of data in a governed and secured form via an API • Orchestration Application of logic to that data, such as transformation and enrichment • Connectivity Access to source data, whether from physical systems, or from external services
Experience API’s (purposeful API’s for Apps and Web) Process APIs (orchestration, composable APIs, Microservices) System APIs (legacy modernization, connectivity to SaaS apps, web services & Restful APIs) Central IT LoB Dev/ IT Apps Dev Accessibility & Ownership Three Tier API Layer Architecture
Layers and their frequency of Changes
“Three-layered” API-led connectivity architecture System Layer •Underlying all IT architectures are core systems of record (e.g. one’s ERP, key customer and billing systems, proprietary databases etc). •Often these systems are not easily accessible due to connectivity concerns and APIs provide a means of hiding that complexity from the user. •System APIs provide a means of accessing underlying systems of record and exposing that data, often in a canonical format, while providing downstream insulation from any interface changes or rationalization of those systems. •These APIs will also change more infrequently and will be governed by Central IT given the importance of the underlying systems. Process Layer •The underlying business processes that interact and shape this data should be strictly encapsulated independent of the source systems from which that data originates, as well as the target channels through which that data is to be delivered. •For example, in a purchase order process, there is some logic that is common across products, geographies and retail channels that can and should be distilled into a single service that can then be called by product-, geography- or channel-specific parent services. •These APIs perform specific functions and provide access to non-central data and may be built by either Central IT or Line of Business IT.
“Three-layered” API-led connectivity architecture Experience Layer •Data is now consumed across a broad set of channels, each of which want access to the same data but in a variety of different forms. •For example, a retail branch POS system, ecommerce site and mobile shopping application may all want to access the same customer information fields, but each will require that information in very different formats. •Experience APIs are the means by which data can be reconfigured so that it is most easily consumed by its intended audience, all from a common data source, rather than setting up separate point-to-point integrations for each channel.
Benefits of API-led connectivity Business •IT as a platform for the business: By exposing data assets as a services to a broader audience, IT can start to become a platform that allows lines of business to self-serve. •Increase developer productivity through re-use: Realizing an API-led connectivity approach is consistent with a service oriented approach whereby logic is distilled to its constituent parts and re-used across different applications. This prevents duplication of effort and allows developers to build on each other’s efforts. •More predictable change: By ensuring a modularization of integration logic, and by ensuring a logical separation between modules, IT leaders are able to better estimate and ensure delivery against changes to code. This architecture negates the nightmare scenario of a small database field change having significant downstream impact, and requiring extensive regression testing.
Benefits of API-led connectivity Technical •Distributed and tailored approach: An API-led connectivity approach recognizes that there is not a one-size-fits-all architecture. This allows connectivity to be addressed in small pieces and for that capability to be exposed through the API or Microservice. •Greater agility through loose coupling of systems: Within an organization’s IT architecture, there are different levels of governance that are appropriate. Separate API tiers allow a different level of governance and control to exist at each layer, making possible simultaneous loose-tight coupling. •Deeper operational visibility: Approaching connectivity holistically in this way allows greater operational insight, that goes beyond whether an API or a particular interface is working or not, but provides end-to-end insight from receipt of the initial API request call to fulfillment of that request based on an underlying database query. At each step, fine grained analysis is possible.
The building block of API-led connectivity powerful Mule core (policies, orchestration, transformation, caching) productized APIs (design, build, test, manage) ubiquitous connectivity (connect to any system or data source) API gateway (Manage all services the same way)
How to do it?
Experience API’s (purposeful API’s for Apps and Web) Process APIs (orchestration, composable APIs, Micro-services) System APIs (legacy modernization, connectivity to SaaS apps, web services & Restful APIs) Central IT LoB Dev/ IT Apps Dev Accessibility & Ownership How to do it? Mule API Layer facing customer/partner Mule API Layer doing business process micro-services Mule API Layer doing CRUD & System Integration
• Each layer is independent of other. • Each API is independent of other. • Everything is based on plug and play (Adapter design) methodology. • Advantage of vast connector library provided by mule to make out of the box connection to external systems can be used. • Out of box solutions of API design can be used. • Implementation of API governance and security is as simple as click of “policies” apply in “API Manager” • SLA’s on API can be applied with single click • Changes can be applied and deployed with zero downtime. • Creation of HA and cluster in Mule is super simple using Mule management console. • Moving from on-premises to cloud is super simple. • Exposure of on-premises API to external partners using cloud is easy. What does it mean?

More Related Content

Three layer API Design Architecture

  • 1. The Problem Space • Every business need to integrate the above three actors and their engagement to systems for the best possible outcome
  • 2. API-led connectivity: The evolution of SOA • While connectivity demands have changed, the central tenets of SOA have not, that is, the distillation of software into services that are well-defined, re-usable and discoverable • This problem lends itself to a service oriented approach in which application logic is broken down into individual services, and then reused across multiple channels. • Yet, the heavyweight, top-down implementation approaches previously noted are not a fit for the agility that today’s digital transformation initiatives demand. • Point-to-point application integration is brittle and expensive to maintain. Service-oriented Architecture (SOA) approaches provide some instruction in theory, but have been poorly implemented in practice. • The principles of SOA are sound: well-defined services that are easily discoverable and easily re-usable. In practice, however, these goals were rarely achieved.
  • 3. API-led connectivity calls for a distinct ‘connectivity building block’ that encapsulates three distinct components • Interface Presentation of data in a governed and secured form via an API • Orchestration Application of logic to that data, such as transformation and enrichment • Connectivity Access to source data, whether from physical systems, or from external services
  • 4. Experience API’s (purposeful API’s for Apps and Web) Process APIs (orchestration, composable APIs, Microservices) System APIs (legacy modernization, connectivity to SaaS apps, web services & Restful APIs) Central IT LoB Dev/ IT Apps Dev Accessibility & Ownership Three Tier API Layer Architecture
  • 5. Layers and their frequency of Changes
  • 6. “Three-layered” API-led connectivity architecture System Layer •Underlying all IT architectures are core systems of record (e.g. one’s ERP, key customer and billing systems, proprietary databases etc). •Often these systems are not easily accessible due to connectivity concerns and APIs provide a means of hiding that complexity from the user. •System APIs provide a means of accessing underlying systems of record and exposing that data, often in a canonical format, while providing downstream insulation from any interface changes or rationalization of those systems. •These APIs will also change more infrequently and will be governed by Central IT given the importance of the underlying systems. Process Layer •The underlying business processes that interact and shape this data should be strictly encapsulated independent of the source systems from which that data originates, as well as the target channels through which that data is to be delivered. •For example, in a purchase order process, there is some logic that is common across products, geographies and retail channels that can and should be distilled into a single service that can then be called by product-, geography- or channel-specific parent services. •These APIs perform specific functions and provide access to non-central data and may be built by either Central IT or Line of Business IT.
  • 7. “Three-layered” API-led connectivity architecture Experience Layer •Data is now consumed across a broad set of channels, each of which want access to the same data but in a variety of different forms. •For example, a retail branch POS system, ecommerce site and mobile shopping application may all want to access the same customer information fields, but each will require that information in very different formats. •Experience APIs are the means by which data can be reconfigured so that it is most easily consumed by its intended audience, all from a common data source, rather than setting up separate point-to-point integrations for each channel.
  • 8. Benefits of API-led connectivity Business •IT as a platform for the business: By exposing data assets as a services to a broader audience, IT can start to become a platform that allows lines of business to self-serve. •Increase developer productivity through re-use: Realizing an API-led connectivity approach is consistent with a service oriented approach whereby logic is distilled to its constituent parts and re-used across different applications. This prevents duplication of effort and allows developers to build on each other’s efforts. •More predictable change: By ensuring a modularization of integration logic, and by ensuring a logical separation between modules, IT leaders are able to better estimate and ensure delivery against changes to code. This architecture negates the nightmare scenario of a small database field change having significant downstream impact, and requiring extensive regression testing.
  • 9. Benefits of API-led connectivity Technical •Distributed and tailored approach: An API-led connectivity approach recognizes that there is not a one-size-fits-all architecture. This allows connectivity to be addressed in small pieces and for that capability to be exposed through the API or Microservice. •Greater agility through loose coupling of systems: Within an organization’s IT architecture, there are different levels of governance that are appropriate. Separate API tiers allow a different level of governance and control to exist at each layer, making possible simultaneous loose-tight coupling. •Deeper operational visibility: Approaching connectivity holistically in this way allows greater operational insight, that goes beyond whether an API or a particular interface is working or not, but provides end-to-end insight from receipt of the initial API request call to fulfillment of that request based on an underlying database query. At each step, fine grained analysis is possible.
  • 10. The building block of API-led connectivity powerful Mule core (policies, orchestration, transformation, caching) productized APIs (design, build, test, manage) ubiquitous connectivity (connect to any system or data source) API gateway (Manage all services the same way)
  • 11. How to do it?
  • 12. Experience API’s (purposeful API’s for Apps and Web) Process APIs (orchestration, composable APIs, Micro-services) System APIs (legacy modernization, connectivity to SaaS apps, web services & Restful APIs) Central IT LoB Dev/ IT Apps Dev Accessibility & Ownership How to do it? Mule API Layer facing customer/partner Mule API Layer doing business process micro-services Mule API Layer doing CRUD & System Integration
  • 13. • Each layer is independent of other. • Each API is independent of other. • Everything is based on plug and play (Adapter design) methodology. • Advantage of vast connector library provided by mule to make out of the box connection to external systems can be used. • Out of box solutions of API design can be used. • Implementation of API governance and security is as simple as click of “policies” apply in “API Manager” • SLA’s on API can be applied with single click • Changes can be applied and deployed with zero downtime. • Creation of HA and cluster in Mule is super simple using Mule management console. • Moving from on-premises to cloud is super simple. • Exposure of on-premises API to external partners using cloud is easy. What does it mean?