apis in the enterprise - lessons learned

APIs in the Enterprise - Lessons Learned

Ian CooperPlatform Architect, Thomson Reuters 1

Dhananjay TripathiSenior Enterprise Architect, BUPA

2

Apigee @Bupa !Dhananjay Tripathi

Senior Enterprise Architect – Bupa UK

Apigee @Bupa

3

4

Then.. Now…

Consumer 1

Consumer 2

Consumer n

LOB 1

LOB 2

LOB n

\\Fileshare

Queue

Web services

Messaging

Web Services & ETL

Consumer 1

Consumer 2

Consumer n

LOB 1

LOB 2

LOB n

API

Management

How we Integrate…

5 ©2016 Apigee. All Rights Reserved.

LOB System

Native APIs

LOB System

Native APIs

LOB System

Native APIs

Messaging

API Management Layer

Bupa Digital Channels Third Party LOB Systems (i.e. CRM)

Service Bus

LoB (Hosted)

How we Integrate...


LoB (Cloud)

Apigee plays a fundamental role in our drive to reuse data and services across the enterprise and share data with our partners securely

Partners Digital Channels

Apigee Helping in...


Apigee Org Structure


Dev QA UAT NFT PROD

Bupa

BUPA-DEV

DEV MU-1 DEV MU-n QA MU-1 QA MU-n

BUPA-NP

UAT MU-1 UAT MU-n NFT MU-1 NFT MU-n

BUPA-PROD

Prod

Account

Org Org Org

Env Env Env Env Env Env Env Env Env

Apigee Capabilities in Bupa


API Centric

Organization

Things to keep in mind…


Keep Apigee Layer Simple

No Cross referencing of APIs.

No Aggregation of Data and keep it RESTful.

Business Rules in Messaging layer or in

Native API

Authentication and Authorisation

Authentication in Apigee and

Authorisation in LoB

Organisation Structure

Dev, Non-prod & Production

environments created in separate

organisations

Adoptability within Enterprise

Different Stakeholders have different

interpretations of Apigee and its usage. Arrange Information sessions to

inform and address concerns

APIs in the Enterprise - Lessons Learned Ian CooperPlatform Architect Thomson Reuters

11

The views expressed in this presentation are those of the presenter, and not necessarily those of Apigee Corporation or the presenter’s employer.

12

Background

13

©2016 Apigee. All Rights Reserved.

Thomson Reuters and APIs •  Thomson Reuters are the leading provider of information to professionals and businesses •  4 Business Units

•  Financial & Risk •  Legal •  Tax & Accounting •  IP & Science

•  Deliver information through bespoke applications and websites and/or via APIs •  APIs extremes range from real time market data using proprietary wire formats through bulk

downloads via FTP - and lots in between •  Moving towards a unified technology operation, ~15,000 people strong •  Our API Program makes API Management available to the whole organisation •  Exclusively on-premise at the moment

14


Federated API Management •  Huge technology operation •  100s of internal APIs and high 10s of external APIs across the business •  Not feasible to centralise all API development

•  Too much activity •  Highly specialised content sets require lots of domain specific knowledge

•  Very difficult to even centralise all API management •  Don’t want to be a bottleneck

•  Chose a federated API Management model •  Teams bring their APIs to the platform & do the work to get them up and running •  Our team provides general guidance and on-boarding •  Architectural guidance provided where required

15

Lessons Learned

16


Lessons Learned - Federated API Management

•  Federated API Management brings a certain set of issues •  How to drive consistency? •  How to ensure APIs are secure and well designed?

•  API Provider Toolbox •  Maintained corpus of information on how to build APIs on our platform •  Covers main topics that groups should encounter, with links out to the very good Apigee

documentation for advanced areas •  Base Proxy ZIP files

•  Vanilla proxy configuration in a pre-packaged ZIP file, deals with API Key verification with our standard key identifier as header or query param, quota and spike arrest

•  Base Proxy ZIP with pre-configured external logging •  Target Servers

•  Multiple organisations with multiple environments, we don’t generally use Target Servers for load balancing but they do provide smoother promotion for API proxies

17


Lessons Learned - API Standards and Governance •  Historically not a lot of stick, all carrot, to keep teams on the straight and narrow •  Spend time generating and maintaining a set API Standards which fit into our API Strategy

work stream •  API Standards provide an entry point for teams to engage with us •  They build trust with the wider Thomson Reuters technology organisation •  It is much, much easier to on-board well designed APIs onto our API Management

platform, so not completely altruistic •  Tackle topics such as RESTful API design, API documentation standards, security

standards and expectations as well as thoughts around API Management in general •  Because groups are not ultimately forced to adhere to the standards or use the API

Management platform we provide we have to continually try to keep engaging with our audience, corporate memory can be short lived, so the message must be continuous

18


Lessons Learned - Automation via Swagger •  Just getting into automation around Apigee Edge to help facilitate the Federated

Development model •  Wish we had the opportunity to start on this path at the beginning •  Only now are we seeing real traction with Swagger (or OpenAPI Initiative) documented

REST APIs •  Primary automation focus is on generating Apigee Edge proxy definitions directly from

backend Swagger specifications •  Options to generate with API Key or OAuth 2.0 client credentials to start •  Take the target Swagger definition as is and manipulate it and host inside API Proxy on

Edge with dynamic ‘host’, correct ‘basePath’ and injected security •  Add all resources in Swagger definition and then provide 404 handling in Edge for API calls

that do not match a defined resource •  Allow groups to incorporate into their build processes and release to QA, not to prod

19


‘Flavours’ of API Management •  API Management means different things to different groups •  Sometimes it is difficult when a term gets too overloaded •  Different providers focus on different aspects of API Management, there is a spectrum of

capabilities •  Low level, technical management of API traffic, very technical focused, little to no workflow

around the management of API consumers and quotas - AWS API Gateway very infrastructure like, maybe not a surprise

•  , much more focused on the management of API service tiers and managing which consumers have access to what tier

•  Product Centric, all about the business, dealing with commercials, defining SLAs and legal considerations

•  Linked back to the API Standards and Strategy work stream, important to ensure that there is clarity around the concepts and understanding about where we sit with our API Program

20

Conclusions

21


Conclusions •  In a federated model look to automate - make it easy for API providers to do the right thing •  Keep engaging with the wider community - published guidance, standards and API design

best practices can help engagement with your API Management program •  Ensure that there is crystal clear understanding about what problems your API

Management program is solving, API Management has become an overloaded term •  Try to keep abreast of the fast moving API Management space, groups look towards your

program for thought leadership so it is important to understand what is happening in the market

22

Thank you


apis in the enterprise - lessons learned

Technology