Moving Toward a Modular Enterprise - All About the API Conference 2016
•Download as PPTX, PDF•
0 likes•346 views
A look at how APIs and microservices are driving the enterprise toward a more modular, connected approach to software development. Also outlines the key transformation steps used by CIOs and CTOs to address digital transformation and achieve a more modular enterprise.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (12)
Similar to Moving Toward a Modular Enterprise - All About the API Conference 2016
Similar to Moving Toward a Modular Enterprise - All About the API Conference 2016 (20)
More from LaunchAny
More from LaunchAny (18)
Recently uploaded
Recently uploaded (20)
Moving Toward a Modular Enterprise - All About the API Conference 2016
- 1. Moving Toward a Modular Enterprise James Higginbotham /@LaunchAny
- 6. We are now seeing the early stages of a transition from users going to the application, to applications going to the user
- 7. When APIs Meet Jobs-to-be-done
- 8. Offers API Inventory API Bookings API Identity API Accounts API Rewards API Partners Internal Developers Public App Developers Consumers Third-party Approved Apps
- 9. Transformation #1: Capture Capabilities with APIs
- 10. API Capabilities: “I want to…”
- 12. List Avail Inventory Distributor Add Product to Order Complete Order Cancel Booking Add Product to Inventory Update Product Qty Locate Booking Redeem Booking Point Of Sale Remove Product Customer Clerk Operator
- 13. Order Mgmt List Avail Inventory Distributor Add Product to Order Complete Order Cancel Booking Add Product to Inventory Update Product Qty Locate Booking Redeem Booking Operator Point Of Sale Remove Product Customer Inventory Mgmt Fulfillment Clerk
- 14. Order API List Avail Inventory Distributor Add Product to Order Complete Order Cancel Booking Add Product to Inventory Update Product Qty Locate Booking Redeem Booking Point Of Sale Remove Product Customer Inventory API Fulfillment API Operator Clerk
- 15. Availabilities - product - date(s) avail - qty avail availabilityChanged() Orders - bookings - order total created() updated() Products - name - avail schedule created() removed() updated() Bookings - product - date(s) - status redeemed() cancelled() Order API Inventory API Fulfillment API
- 16. Transformation #2: Become an API-Centric Organization
- 22. Transformation #3: Innovate with an outside-in approach
- 23. Modern web APIs are the ultimate “do-over”
- 24. Your API design should become the definition of your new target architecture
- 27. Transformation #4: Focus on the Developer Experience
- 28. APIs are a developer’s user interface
- 33. Transformation #5: Structure Teams For Delivery
- 35. Where are APIs leading us?
- 36. APIs are the new apps.
- 37. Either you serve the computer or it serves you. Either you are working on spec to create a commodity, or you are using new tools to create disruptions and to establish yourself as the linchpin, the one we can’t easily live without. - Seth Godin http://sethgodin.typepad.com/seths_blog/2016/07/the-computer-the-network-and-the-economy.html
Editor's Notes
- Nearing the end of the conference Talked a lot about designing, testing, and marketing APIs But why are they important? And where are APIs taking us? We will talk about this throughout this talk, including what it means to be a modular enterprise
- APIs connect everything that we do. They enable our enterprise to internally connect systems. They extend the reach of our enterprise to the web, mobile, IoT The value of an API is in the collaboration it creates between the end user and your product or service The arrows is where the collaboration is at Your API strategy must focus on this collaboration to deliver a great API
- Driving the focus toward APIs as the enablers of collaboration, rather than just data Messaging platforms such as Slack have been leading the way Slack not only helps teams to communicate via chat, they also provide an integration platform to provide access to important data at the right time
- In fact, a recent article makes the claim that some Slack users are spending nearly 10 hours in the app every day This is moving our workflow away from email and more to real-time collaboration APIs enable this collaboration
- If we look toward the Internet of Things, we are seeing APIs not only sharing data, but offering custom experiences Specifically, voice- driven devices are taking us to a similar place as messaging platforms Moving beyond typing and mouse clicks and into a new conversational user experience People are using their Amazon Echo and other voice-driven devices to perform complex workflows. More elaborate collaborations The devices engage in a conversation with us, applying our questions and following-up or delaying our involvement
- We are now seeing the early stages of a transition from users going to the application, to applications going to the user Mobile, IoT, voice and messaging platforms are driving the move to applications meeting the user via APIs
- Consider the things that happen around you on a day-to-day basis – your jobs to be done. The job-to-be-done often requires us to move around applications, most driven by API interactions with our data and business logic API collaboration really occurs when our APIs meet the job-to-be-done Platforms such as Slack and Alexa are often closer to where the job-to-be-done exists than the applications we use Why not decompose our enterprises into the building blocks that drive our daily collaborations?
- This is what I call the “modular enterprise” APIs shift companies from just writing code to digitizing business capabilities. Remember, APIs lower the barrier to do extraordinary things (e.g. machine learning) APIs used to be inward-facing, for assembling apps and SOA All of this has changed with the shift to modern web APIs Mobile app == product. The API is part of that product offering When companies open their capabilities for integration through APIs, amazing things can happen building blocks The value of an API is in the collaboration it creates between the end user and your product or service Your API strategy must focus on this opportunity for collaboration to deliver a great API This is the “modular enterprise” - the shift of strategy to an external view of APIs that enable collaborations between your business and internal, partner, and external developers. Let’s look at 5 key transformations that our business must go through to fully realize this opportunity to build a “modular enterprise”
- What is it that you do that helps others get things done? This may be at the business level - the products and services you offer This may also be at the technical level - how you enable these products and services to be delivered, including the data that you gather and create
- This is a screenshot from Zapier, a web-based automation tool It allows you to connect different kinds of APIs together, without writing any code You’ll notice that they don’t even talk about APIs. Instead, they focus on what you want to get done - the goal or outcome That is how we need to think about our APIs: what kind of outcome or collaboration is desired?
- When we take this kind of approach, we are then able to start mapping our capabilities to the needs of the market, translating them to API capabilities that we then deliver as API-based products to our partners, public developers, and internal developers So, how do we do that? Let me share briefly about the process I use with my clients
- The first step in the process is to identify all of the activities and desired outcomes This diagram shows an example of an ecommerce distributor site that acts as a broker between suppliers and customers We map out the activities, along with the actors that perform them
- As we fill out the map, we see logical groupings where common concepts gather We can then name these related activities In this example, we have Order Mgmt, Inventory Mgmt, and Fulfillment Use the boundaries to determine: - what has already been built in-house - what needs to be built in-house - what can be replaced by COTS, third-party APIs
- These groupings then become potential APIs that will offer the endpoints necessary to make these activities achievable The endpoints can be combined into a single or multiple API products as a result of this effort Focus on desired outcomes, composed of capabilities that are wrapped by APIs
- Results in resources Captures EVENTS
- The second transformation we must undergo is to become an API-centric organization Being API-centric means that you look for opportunities to wrap anything your organization has to do as an API endpoint to both drive automation Let’s look at some examples of how businesses have done this
- The best example of this is Amazon, which pushed for a heavy focus on automation through services Over time, they built APIs around their data center management, resulting in Amazon Web Services What started as a few services has now grown to a portfolio of services that cover all aspects of data center management
- Watson is changing the way we UNDERSTAND DATA LANGUAGE, SPEECH, VISION, and DATA INSIGHTS Another example is IBM Watson Watson takes the research done in artificial intelligence and offers it as an API for developers Using their APIs, developers can understand data, interpret speech, and apply computer vision to their software
- Capital One is changing the way we interact with banking and bank-level security They released 3 APIs publically during SXSW in March (2016) Each of the APIs tell a story of how developers can use their capabilities, including two-factor authentication, their rewards program, and prequalifying for credit offers that can help improve your conversion rates
- Additionally, Capital One is extending their business to the Amazon Echo, allowing their customers to check their balance and monitor recent charges This is all driven through APIs that capture their capabilities and externalizes them into a fresh experience for customers and developers
- As you have already seen, APIs are not reserved just for software companies Walgreens has taken their corner store and digitized them, essentially wrapping every store with an API
- The 3rd transformation is to move your organization to an outside-in, iterative approach to innovation
- APIs can be transformational to your software development processes as well By adopting an outside/in approach, we have the opportunity for the ultimate do-over
- Our APIs can instead define our target architecture for our business systems, hiding the details that exist today and the transformation that your systems will undergo as you re-architect specific areas of your business Brings HOPE to ADAPT EXISTING products can use this idea to drive toward desired change, applying what I’m about to explain moving forward
- As an example, assuming we have an existing system today that integrates with our data stores, > We can apply an API in front that hides all of the internal details. > Our external systems can then communicate direcly via the API, without worrying about how the internal systems work > If we design our API to use, but not specifically coupled to our backend systems, we can migrate to our desired target architecture
- Here is where you may be considering microservices, or perhaps have already started the journey Your APIs may be designed as microservices internally and externalized via API gateways to enforce your security and compliance to externally-facing systems In this diagram, we can see API gateways that deliver the functionality necessary for web and mobile apps, voice apps, and messaging platform integrations These gateways either pass requests directly to a backend microservice, or to composite services that manage calls across several microservice endpoints Let your APIs help you to drive your target architecture
- The fourth transformation is to focus on the developer experience of your APIs
- It is important to remember that APIs are the developer’s user interface This is what they interact with as they assemble their applications How easy you make this process will determine how fast they are able to get up-and-running
- Stripe is well-known in the development community for having a great developer experience They guide the developer through the process of understanding what they do, what capabilities they offer, onboarding, and making your first API call Typically, it can take 5-30 minutes to be up-and-running with their API in a sandbox environment
- Stripe is able to do this by delivering comprehensive documentation that is tailored toward guiding developers through this process Notice how they walk the developer step-by-step through the primary use case that developers come to Stripe to solve: register a credit card, associating cards to a new or existing customer, charge a credit card, manage plans, and dealing with recurring payments using subscriptions
- Once developers become comfortable with the core concepts of the Stripe, they then have comprehensive reference documentation that provides an overview, examples, and deep documentation on each of the API endpoints
- Stripe takes developer experience even further by ensuring that any changes to their API does not break existing API clients Instead, they maintain backwards compatibility. Currently they maintain approx. 65 active versions This is because they know that if they make a breaking change, they will impact the top line of many businesses
- The final transformation is to structure your teams for delivery Many organizations undergoing digital transformation are feeling the pain of their existing organizational structure Moving to an API-centric organization puts pressure on delivery in ways that organizations may not be prepared for
- I work with platform and product teams to coach them on including cross-functional delivery teams during the initial API design process This approach helps accelerate learning, as subject matter experts, architects, product, business, technical writers, QA, and developers are able to validate and execute on API delivery in tandem
- So, where does all of this transformation to an API-centric, modular enterprise taking us? If we consider today’s application architecture, we often associate data with an application This is why it is so difficult to decommission applications inside the enterprise They continue to be required as a result of the data and logic that they provide The services we built from our initial SOA initiatives have helped this some, but they often focus more on system integration rather than capturing business and technical capabilities
- I truly believe that APIs, when built around capabilities, will become the new apps As a result, applications themselves are simply a means to visualize and interact with them Applications will become more situational, perhaps used for months, weeks, or even days before being disposed of Businesses will continue to build products that deliver functionality in a generic way. These applications will require the kinds of user experience and UI design processes that we use today that attempt to find the right interface that works across a variety of customer personas However, I believe that we will start to see new applications built around specific personas or by individual citizen developers that quickly assemble applications that operate within their personal workflows These personalized apps will be driven by APIs that continue to manage the data and logic, no matter which variation of the application that is integrating with them
- I want to leave you with this quote from Seth Godin, which captures the essence of what I have been speaking about today <read slide> Apply these transformations and make your APIs the linchpin to something new and amazing