Downloaded 142 times
Uploaded byApigee | Google Cloud
APIs in the Enterprise -Lessons Learned
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.
More Related Content
Similar to APIs in the Enterprise -Lessons Learned
APIs in the Enterprise -Lessons Learned
- 1. 1 APIs in theEnterprise: Lessons Learned Hara Chakravarthy, Vantiv Shawn McCarthy, Vantiv Max Furmanov, Accenture
- 2. APIs in theEnterprise Hara Chakravarthy Shawn McCarthy Max Furmanov 2
- 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 Journey05:00 2. Challenges 10:00 3. Addressing Challenges 10:00 4. What’s Next 05:00 ©2015 Apigee. All Rights Reserved.
- 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 intodigital 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 GreatAPIs - 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 GreatAPIs - 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.
- 12. APIs in theEnterprise – 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 theEnterprise - 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 theEnterprise - 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 theEnterprise – 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 theEnterprise - 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.
- 18. APIs in theEnterprise – 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 theEnterprise – 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 theEnterprise – 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 theEnterprise – 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 theEnterprise – 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 theEnterprise 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.
- 25. APIs in theEnterprise – 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 theEnterprise 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 Policiesand Standards within their trains Self Governing Cross Functional Team
- 28. Cross Functional Team AssetStewardship, 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©2015Apigee. 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 theEnterprise 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.
- 32.
- 33. Standards Standards Imperatives Foundation standardexplaining 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 Practicesand 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 StandardA 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.
Editor's Notes
- #9 Major shift to transform into digital business. Unlocking value by exposing hidden assets (through APIs). Standardizing on method (API Management and analytics) to expose and access hidden assets. Empower the developers. Internal/external developers treated the same way. Changing market approach from inside-out view (specific functional products) to an outside-in approach with the customer experience driving product development. Moving to a product centric delivery rather than today’s functional teams. Allow organizations to respond quicker to market opportunities. No longer viewing technology as a cost reducing mechanism but something empowers innovation and creativity of the organization e.g. first to market higher priority than reducing cost by x %.