More Related Content Similar to APIs in the Enterprise - Lessons Learned (20) More from Apigee | Google Cloud (20) APIs in the Enterprise - Lessons Learned 1. APIs in the Enterprise - Lessons Learned
Ian Cooper
Platform Architect, Thomson Reuters 1
Dhananjay Tripathi
Senior Enterprise Architect, BUPA
4. 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
A
P
I
M
a
n
a
g
e
m
e
n
t
5. 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
6. LoB (Hosted)
How we Integrate...
6
©2016 Apigee. All Rights Reserved.
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
8. Apigee Org Structure
8
©2016 Apigee. All Rights Reserved.
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
10. Things to keep in mind…
10
©2016 Apigee. All Rights Reserved.
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
11. APIs in the Enterprise - Lessons Learned
Ian Cooper
Platform Architect Thomson Reuters
1
1
12. The views expressed in this presentation are those of
the presenter, and not necessarily those of Apigee
Corporation or the presenter’s employer.
1
2
14. ©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
1
4
15. ©2016 Apigee. All Rights Reserved.
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
1
5
17. ©2016 Apigee. All Rights Reserved.
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
1
7
18. ©2016 Apigee. All Rights Reserved.
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
1
8
19. ©2016 Apigee. All Rights Reserved.
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
1
9
20. ©2016 Apigee. All Rights Reserved.
‘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
2
0
22. ©2016 Apigee. All Rights Reserved.
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
2
2