This document discusses the journey of Vantiv and Accenture in developing APIs for their enterprise. It outlines the challenges they faced transitioning from shared services to API products, including API proliferation, lack of standards, and knowledge loss. To address these, they organized into API product teams, adopted API management best practices, deployed APIs on resilient platforms, and built long-running teams. Currently, their mature API program has established reusable APIs and aims to spread an agile development culture by integrating API developers into product teams. The next steps involve decentralizing governance while maintaining standards.

1. 1
APIs in the Enterprise: Lessons Learned
Hara Chakravarthy, Vantiv
Shawn McCarthy, Vantiv
Max Furmanov, Accenture

2. APIs in the Enterprise
Hara Chakravarthy
Shawn McCarthy
Max Furmanov
2

3. Introduction
3

4. Vantiv / Accenture - Introduction
Shawn McCarthy
shawn.mccarthy@vantiv.com
Director, APIs and Portals
Hara Chakravarthy
haragopal.chakravarthy@vantiv.com
Senior Manager, APIs
Max Furmanov
max.furmanov@accenture.com
Managing Director

5. Agenda
5
1. API Journey 05:00
2. Challenges 10:00
3. Addressing Challenges 10:00
4. What’s Next 05:00
©2015 Apigee. All Rights Reserved.

6. API Journey
6

7. API (R)evolution
7©2015 Apigee. All Rights Reserved.
Technology Enabler
API as-a-Product
Business Enabler
Standardize Integration
Data & Service
Monetization
“Stretch Your
Boundaries”
Outcome
Economy
Workforce
Reimagined
Intelligent
Enterprise
The
Internet
of Me
Platform
(R)evolution

8. • Transform into digital business
• Unlocking value through APIs
• API Management and analytics
• Empower developers
• Changing market approach to customer
experience driving product development
• Moving to a product centric delivery
• Viewing API as technology that empowers
innovation and creativity of the organization
What is the outside world doing?
8
Developer Key to
Digital
©2015 Apigee. All Rights Reserved.
* Courtesy of Apigee
“We will unlock the hidden value of assets, and participate in the digital currency ecosystem when we focus
on mobile and API first initiatives.”

9. Features of Great APIs
- Reiteration
• Centered on Developer Experience
– Easy to Discover
• Well defined contracts. Consistently named
• Comprehensive Documentation
– Easy to Use, Adapt to
• Abstract away complexity
• Self service registration, testing and certification
• Available Client SDKs
Key features Vantiv Developer Portal
Developer Portal P
Community P
Comprehensive set of sample
code
P
Sandbox P
Simple documentation P
Simple registration P
Developer Dashboard P
Social tools P
RESTful APIs P
API console P
Automated Certification P
Analytics P

10. Features of Great APIs
- A recap. Continued…
• Agile in themselves and aid in developer agility
– Short design cycles
– Iteratively layered features
• Built and hosted on resilient, self correcting systems
• Automating Certification and Analysis
– Automating certifications of API integrations
• Allow developers to streamline their integrations
– Provides feedback and analytics to developer
– Insights in process and sales engineering engagement
– Find out in real-time how your API calls to Vantiv are
measuring

11. Challenges
11

12. APIs in the Enterprise –
Multi Year Journey
July 2011 –
Vantiv
Separation
August 2011 –
EIS Team is
formed
2011 – 2012
Shared
Services .
Waterfall
Methodology
Fall 2012 –
Agile
Transformation
starts
2012 – 2014.
Staff Aug
Model. API
Proliferation
February 2014
– API As a
Product Team is
formed
Summer 2015 –
Partner APIs
align with Portal
Spring 2016 –
API Team
coalesces with
Product Trains

13. APIs in the Enterprise - Challenges
• Enterprise APIs are not different
• The organizational construct though, is different
– Hence requires a different mindset to execute
• Transition from “Shared Services” to “Enterprise APIs” to “API
– App Product Team is an evolutionary process
– Has a lifecycle, with stages of evolution
– Stages cannot be skipped

14. APIs in the Enterprise - Challenges
– Construct of a project/initiative
• API requirements delivered from within an initiative
– Success of initiative trumps elegant design. Eg., UI
concerns pushed to APIs
• Multiple initiatives have overlapping requirements, but don’t
agree on shared success
• In turn, leading to
– API Proliferation (read spaghetti)
– Lack of standards around cross cutting concerns (eg.,
security)
– Little consistency in API design
APIs
SharedService
team
• Focused on projects
• SOA not considered
• Did not promote reuse
• Project success

15. APIs in the Enterprise –
Multi Year Journey
July 2011 –
Vantiv
Separation
August 2011 –
EIS Team is
formed
2011 – 2012
Shared
Services .
Waterfall
Methodology
Fall 2012 –
Agile
Transformation
starts
2012 – 2014.
Staff Aug
Model. API
Proliferation
February 2014
– API As a
Product Team is
formed
Summer 2015 –
Partner APIs
align with Portal
Spring 2016 –
API Team
coalesces with
Product Trains

16. APIs in the Enterprise - Challenges
– Enterprise APIs are deployed on shared run times
• Non performant APIs end up affecting others on the platform
– API developers staffed in alignment with initiatives
• Leads to brain drain, loss of knowledge
– API teams are not long running
• Against the grain of one of the critical success factors of Agile development
Professional
services
• Shared runtime
• Projects staffed
• Teams changing
• Knowledge loss
• Consultant based

17. Addressing Challenges
17

18. APIs in the Enterprise –
Multi Year Journey
July 2011 –
Vantiv
Separation
August 2011 –
EIS Team is
formed
2011 – 2012
Shared
Services .
Waterfall
Methodology
Fall 2012 –
Agile
Transformation
starts
2012 – 2014.
Staff Aug
Model. API
Proliferation
February 2014
– API As a
Product Team is
formed
Summer 2015 –
Partner APIs
align with Portal
Spring 2016 –
API Team
coalesces with
Product Trains

19. APIs in the Enterprise – How we addressed the
Challenges
• Organized ourselves as API Product Teams
with focus on what make a Great API
• Ease of use
– API Reuse. Stable APIs make it easier for
developers to consume. Do not reinvent the
wheel
• Abstract away complexity by hosting on a
capable enterprise service bus with the
following capabilities
» Mediation, Transformation and Translation
» Enrichment, using available technology
adapters
» Support for multiple formats (XML, JSON,
flatfile)
» Support for multiple transport protocols
(http(s), mq, jms, ftp, pop3 )
» Process orchestration and visibility
» Process recovery and resubmission
APIs
Partner APIs
Card Services
Research and
Reporting
Risk, Fraud,
Third Party
Merchant
Lifecycle
Boarding
Underwriting
Terminal
Management
Core
Acceptance
Developer
Portal
CNP RESTful
APIs
CP RESTful
APIs

20. APIs in the Enterprise – How we addressed the
Challenges…
• Follow sound principles of service
orientation
– Consistent and intuitive interface design
– Separation of concerns
– Support Layering and Composition
• Self service registration
– Through a developer experience centric API portal
– That leverages a capable ESB to integrate with
Directory services and user entitlement systems
• Easy to discover
– Well designed, intuitive repository
» With organizational and asset taxonomies
– Thoughtfully laid out, consistent service contracts
» Leverage Swagger for RESTful services
– Rich Documentation
VantivAPIs
APIManagementPlatform
Payments
Card
Management
TxResearch
Fraud
Management
Merchant
Info
Boarding
DeveloperPortal
API
Marketplace
CodeandSDKs
Knowledge
Base
Certification
Dashboards
Solution
Runtime
PartnerDeveloper
Automated
Certification
Certification
StatusTracking
Dev
Automation
Tools

21. APIs in the Enterprise – How we addressed the
Challenges…
– Deployed the APIs on resilient, capable, self correcting platforms
• Enterprises require multiple service patterns. Capable ESBs provide the following with minimum
development effort
– Request – Reply
– Asynchronous services with guaranteed delivery
– Business event based notifications
– Business process orchestrations
• APIs deployed on a highly available, common platform. Unified platform reduces complexity, makes
it easier to administer
– With proactive alerting mechanisms
– Delivering against performance benchmarks
– Using common logging standards, leveraging enterprise logging platforms
DataPower
Tier 1
Client webMethods
Tier 2
WebSphere
Tier 2
RAFT
DB2

22. APIs in the Enterprise – How we addressed the
Challenges…
– With behaviors geared towards developer
success
• Agile API teams
• Focused on developer success
• Playing a consultative role
– Built as long running teams
• Teams built subject matter expertise as they iterated on
features
• Leverage the expertise to better advise developers and
help them succeed
API as a Product
Drive developer adoption
APIs that are easy to understand with clear
helpers and samples
Agility
API ecosystem that supports exposing our
set of API’s in multiple ways (SOAP, REST,
etc)
Ecosystem
Develop and grow strong ecosystem of
partners who can help each other through
forums and solution idea sections
Users

23. APIs in the Enterprise
Multi Year Journey – Current State
– Well established, mature, long running API team
• Organized by business domain or product
• Has the largest surface area in the organization. Uses this to best influence
positive outcomes
– Library of mature, reusable APIs
– Well established
• Security, logging standards
• Contract/Domain object models
• Technology specific components
– Team builds fine grained APIs and layers them – as opposed to
building monoliths

24. What’s Next
24

25. APIs in the Enterprise –
Multi Year Journey
July 2011 –
Vantiv
Separation
August 2011 –
EIS Team is
formed
2011 – 2012
Shared
Services .
Waterfall
Methodology
Fall 2012 –
Agile
Transformation
starts
2012 – 2014.
Staff Aug
Model. API
Proliferation
February 2014
– API As a
Product Team is
formed
Summer 2015 –
Partner APIs
align with Portal
Spring 2016 –
API Team
coalesces with
Product Trains

26. APIs in the Enterprise
Evolution – What’s Next
– API Teams to spread the “Agile App Development” culture
– “Enterprise API Organization” retains stewardship of assets. Develops patterns
– API Developers join the Product Development teams
• Platforms are consolidated along product lines
• API developers play the role of facilitators
– Educate legacy application developers
– Help them transition to the next generation thinking – “Think Agile”, “Think Layering”, “Think
Micro”
– Mature APIs are layered and composed to address platform requirements

27. Decentralized Governance
Police Policies and
Standards within their
trains
Self Governing
Cross Functional Team

28. Cross Functional Team
Asset Stewardship, Standards/Guidelines, Platform Architecture and API SME
API
Standards,
Guidelines,
Solution
Architecture,
SME
Solution
Architect
APIs
Solution
Architect
Portals
Solution
Architect
Products
Boarding /
Underwriting
Value Added
Services
Card
Services

29. Enterprise APIs
Layered Approach
29©2015 Apigee. All Rights Reserved.
Enterprise Applications
Systems of Record, Systems of Differentiation
Internal APIs aligned to agile trains
Open External APIs Partner APIs Product APIs
Systems of Innovation Partner (B2B) Product Ecosystem
Digital
Web
Value Add Enterprise
Partners Ecosystem
Developers Enterprise
Developers
Javascript APIs Javascript APIs / SDKs Integrated APIs
* Based on Forrester research – Randy Heffner
2
1
3
External Layer
Developer Portal
Centralized Governance
API teams
Teams aligned to
product/platform
Decentralized Governance
Product/Platform
Agile teams

30. APIs in the Enterprise
Evolution – Recap
30
Text
– API teams go through stages of evolution
– Stages cannot be skipped
– API teams are best placed to influence the maturity of the enterprise
• Centralization is needed to build the “Agile App Development” culture
• Decentralization is needed to spread this culture throughout the enterprise
and to better align with the products themselves

31. Thank you

32. APPENDIX

33. Standards
Standards
Imperatives Foundation standard explaining the verbiage and conventions that span all standard documens.
Continuous Integration Standard composed to direct personell regarding the way in which they should approach automated
builds and automated test for software developed within Vantiv and specifically the ODP team.
Component Naming Catalogs the set of unique identifiers that should be used when referring to a given component or cross
cutting technology used. Critical supporting standard for logging as it allows for disparate teams to avoid
term overload and promote consistency within logs.
Logging An application logging standard that grants uniformity to the logs and a shared set of search criteria that
can be used to pinpoint problem areas or trace application logic flow.
Logging - Addendum An addendum document that addresses standardization of the CorrelationId data element used to trace
request processing across different SOA components.
API Versioning A standard defining how versioning is managed for Vantiv web service APIs.
Error Catalog
33©2015 Apigee. All Rights Reserved.

34. Best Practices
Best Practices and Reference Architectures
Deliverable Lifecycle Foundation standard explaining the verbiage and conventions that span all standard documens.
Error Handling Standard composed to direct personell regarding the way in which they should approach automated
builds and automated test for software developed within Vantiv and specifically the ODP team.
SOAP Web Service Reference
Architecture
Specifies the topology and composition of a standard Web Service developed at Vantiv.
License Security Policy Reference
Architecture
Specifies the topology of the License Security Policy implementation model used at Vantiv.
34©2015 Apigee. All Rights Reserved.

35. Backlog
Backlog
Configuration Management Standard A standard intended to govern configuration uniformity towards the end goal of simplifying automated
deployment and configuration management across environments.
Web Service Authentication and Access
Control Standard
A standard intended to quantify the implementation considerations and patterns used to authenticate Web
Service clients and
RESTful API Design Standards and Best
Practices
Intended to document RESTful API Design best practices leveraged within the ODP team towards the
end goal of uniform API design to garner a more consistent experience for parties integrating with our
services.
SOAP API Design Standards and Best
Practices
Intended to document SOAP-based Web Service API Design best practices leveraged within the ODP
team towards the end goal of uniform API design to garner a more consistent experience for parties
integrating with our services.
RESTful Web Service Reference
Architecture
A reference architecture to detail the components and SOA patterns that should be used when building
RESTful Web Services within the ODP team.
Multi-Protocol Egress Gateway
Reference Architecture
A reference architecture used to illustrate the Multi-Protocol Egress Gateway pattern and illustrate its
benefits from an System Engineering cost savings perspective.
Notification/Subscription Reference
Architecture
A reference architecture used to illustrate the Notification/Subscription pattern which limits one off
integrations in the context of partner implementations.
Value Added Services Design and
Implementation Standards
An intended document with the purpose of providing guidance when designing and implementing Value
Added Service solution components.
35©2015 Apigee. All Rights Reserved.