Recomendados
Más contenido relacionado
Destacado
Destacado (15)
Último
Último (20)
Commerce.codetalks - The API Economy as an E-Commerce Operating System
- 1. The API Economy as an E-Commerce Operating System Sebastian Weikart - sebastian@suchcommerce.com Code.Talks - Commerce Special
- 2. Agenda • A Brief Introduction… • What are APIs and what is the API Economy? • Why are APIs so great? • What is important to consider when selecting an API Vendor? • What is the E-Commerce API Ecosystem & How can I use it as an E- Commerce Operating System? • So how does it fit all together?!
- 3. A Brief Introduction • E-Commerce Architect since > 10 Years • 7 Years in London working with leading Retailers and Brands - House of Fraser, ASDA Direct, Clarins Group, TM Lewin, Labelux Group and more • Now living in Berlin, working as Product Owner, Architect and Tech Lead • sebastian@suchcommerce.com / @sebbbulon
- 4. … and what is the API Economy? What are APIs?
- 5. What are APIs? A short history… • Since the beginning of time: Libraries delivered as Binaries for propriety platforms, delivered on discs or CDs • Late 1960s: Remote Procedure Calls • 1991: CORBA • 1998: SOAP • 2000: REST • 2001: JSON • since mid/late 2000: The Rise of Software-as-a-Service / Cloud-based Products and Platforms that deliver Functionality through an API and are billed by Usage and other Metrics
- 6. A Definition… • An API Product is delivered through Cloud-based Software-as-a-Service • All or the great majority of the Products features & functions can be used through this API • They use common Internet Protocols such as HTTP(S) • Largely standardised interface by implementing REST or similar Protocols, commonly using JSON as a Format • All or the great majority of Functions are documented and accessible publicly (no Pay-Wall or Exclusive Club) • Self-Service Sign-Up, Free Tiers, Usage based Billing • Sometimes API Products also known as “Headless” because there is no front-end or templating layer
- 7. What is the API Economy? • APIs provide Software and Functions like Utilities (Gas, Energy) • 3 Ways to take part and benefit from the API Economy: • You provide an API Product • You consume an API Product for your own Product, and leverage the additional generated Value for your Profit • You provide features and functions that are not covered by certain APIs and offer it to it’s wider Ecosystem
- 8. Why are APIs so awesome?
- 9. Why are APIs Great? • You are standing on the Shoulder of Giants: Give you powerful functionality without you having to implement them or needing to provide computing power • They are Universal: No proprietary Language or Technology, use the one where you have the greatest Expertise, connect all applications in your Organisation • Easy to understand with minimum Documentation due to REST Protocol and human-readable formats like JSON • Billed by Usage like Utilities • Deliver new Functionality continuously without paying extra or needing to upgrade
- 10. It’s a great fit for Omnichannel E-Commerce • How does a classic Omnichannel E-Commerce Architecture look like? Order Management System Storefront Warehouse Management
- 11. Tear down the Silos - Connect all your Devices and Systems, Enabling REAL Omni-Channel in Real Time
- 12. Use your CMS as the Leading System to deliver the Content. Or go Serverless in the first place… • JavaScript integration can turn a static HTML Website into a transactional one by adding an Add-To-Cart Button ShopRocket: SnipCart: Moltin: Commercetools:
- 13. How to Select API Vendors
- 14. What’s important when selecting API Vendors? • SDK Support - make sure the vendor you are about to choose is committed to your particular development platform and to Android and iOS by updating the respective SDK regularly • Regular release cycles, non-breaking upgrade process • Fast response times (< 100ms) and great uptime (> 99.9%) • Data Center / Point of Delivery available within German Jurisdiction if this is important for you
- 15. What else do I need to look out for? • Carefully check features - does it have a Search or do I need to look for a Search on top of the provided features? • Can I configure Web Hooks? • Can I import / export Data in differerent formats like CSV or do I need to develop this on top of the service? (can be tricky…) • Does it have a comprehensive user interface that covers all the offered functionality? • Is their documentation open and available?
- 16. What’s sometimes not so Great? • They don’t work offline - naturally • Extensibility / Flexibility of delivered Functions can be limited • Many API Vendors lack tools: “Guys, it’s an API, build from developers for developers, you can do everything yourself” - On-Boarding suffers • Your clients might say: “Hey, back in the day when we had the PL/SQL Application running directly in my Oracle Database, I could import / export this huge amount of data much faster” • Often engineers have to adopt new Programming Paradigms they might not yet accustomed to like Asynchronous, Parallel, Message Driven, Reactive, Stateless etc… to leverage the full power of APIs • Data flow needs to be designed carefully, as they are distributed among many systems
- 17. An Overview of the E- Commerce API Ecosystem
- 18. Content PIM Carts Inventory & Order Management Warehouse Mgmt Payment Analytics / Data CRM / Marketing Braintree Stripe QuBit Salesfore Klarna Paymill Google Analytics Nutshell many many more… many many more… many many more… Salsify Contentful Prismic The E-Commerce API Economy (Excerpt) Commercetools Moltin Snipcart Osmek YaaS ? fulfil.io Shoprocket
- 19. E-Commerce API Platforms • YaaS.io (Hybris as a Service) • Oracle CommerceCloud • Commercetools • Moltin • Shoprocket • SnipCart • Mozu
- 20. PIM & OMS Solutions • Salsify • fulfil.io
- 21. Delivery on Demand APIs • UberRUSH were the first on the market to actually offer a working on-demand delivery API
- 22. Integration Platforms • sometimes known as iPaaS • MuleSoft Anypoint Platform • WSO2 • elastic.io • Tray.io • Zapier
- 23. How does it fit all together?
- 24. Thank You! sebastian@suchcommerce.com / @sebbbulon Stock Photos (CC0 1.0) by NASA via Unsplash, Roy Fielding Image taken from Roy Fielding’s Twitter, Douglas Crockford Image taken from Douglas Crockford’s Google+ Page
Notas del editor
- Hello, I am Sebastian. I am here to talk to you about APIs and the API Ecosystem. A brief introduction to myself….
- I will quickly explain what we actually mean when we talk about APIs. Who of you knows what APIs are? I hope I am not going to bore you Then I will give you my perspective on why those APIs are so awesome. I will dive a little bit into what the market has to offer to help you build your e-commerce business- how can I use the API ecosystem as an E-Commerce Operating System? And finally I will give a brief view on how everything fits together from a system architecture perspective. This is probably a topic for a whole other talk, so I can only go into it very briefly.
- House of I like to learn more about you, would you mind giving me a quick show of hands? Who of you is working for an E-Commerce Retailer or Brand? Who of you is working for an Agency or System Integrator? Who of you is working for an E-Commerce Technology Vendor? Is anyone in the audience a developer or solution architect? Are you already using APIs, or planning to use them?
- so…. what are these ominous APIs that I want to talk about, and what is this API Economy?
- What are APIs? Well, when I started working as a software engineer, that was at a small company called Signsoft back in 2003 in Dresden. This company had a product. This product was actually an API that helped other developers to develop their project or product more easily by abstracting the database access layer. However, this API was written in Java and delivered as a Java Binary. On a CD. In a cardboard box. And you had to buy an actual license from Signsoft that granted you the rights to use this API in your application. But also since the beginning of computing, smart people thought about delivering functionality and data not only through the classic Stagecoach approach, but also remotely through networks. So really since the 60ies already we had Remote procedure calls using more or less arbitrary formats and protocols. In the 90ies we started to have efforts to standardise formats and protocols and this lead to the creation of CORBA as a binary protocol, and later SOAP. What these standards had in common where that they were usually convoluted and required a lot of documentation, plus the data formats were usually hard to read and understand. So in 2000, this guy came around. Does anyone know who this is? Yes, this is Roy Fielding. He said, “hey guys, why don’t we use this great protocol called HTTP, which gives us all the means we could possibly need to develop an application interface? “ Furthermore, in 2001, THIS guy came around - who is it? Yes - Douglas Crockford - one of the main contributors to JavaScript - postulated the JSON format. And it was finally easy to read and understand the payload of a message, plus it was really easy for browsers to interpret the data. Furthermore, since probably the mid 2000s - with the arrival of cloud computing - the real beginnings will probably remain shrouded in the mysteries of time - we have actual software products that are offered as a software as a service - that deliver functionality through the Internet using Web APIs based on those techniques and technologies. Often they are billed by Usage or other parameters, effectively offering functionality just like gas or power out of the socket. The actual business of exposing APIs, consuming APIs and delivering functionality for API platforms we call the API Economy. So there are many ways to contribute to the API economy - offering an API, building a product using APIs, offering 3rd party extensions etc…
- For the purpose of this talk, let me define what I consider as an API or an API Product. First, they are delivered as a cloud-based saas! This means I did not consider any on-premise solutions for my research or frameworks that I need to host or deploy myself Furthermore, they deliver all or a huge amount of their functionality through their API. And that’s really important as there are many products out there that implement an API as a second thought- which means that only a subset of functions of the product will be available. The best API products are really the ones that have been conceived API-first, and all their functions are accessible through this interface. They commonly use HTTP(S) and other internet protocols - but really HTTPS due to it’s universal power is the de-facto standard. The majority use REST or similar application protocols. REST is really great because it makes it much easier to understand for developers from the start. There are some other variants such as HTTP API that provide a slightly different interface, where the application logic is coded more into the actually application payload through update actions. Furthermore, you will find JSON as a format in most cases. Very rarely you will still find an XML interface, but JSON becomes really universal because it is in fact much easier to read, debug and understand. Another thing I consider as important is that there is no exclusive club and no pay wall to access the documentation. If an API vendor commits to this open and transparent way, they will benefit hugely from a growing ecosystem of developers because it’s lowering the barriers of people to get involved without needing to sign up or pay something. Most have a free tier, provide self-service sign-up and have a usage based billing. Regards to free tiers you will find different models - limited usage, limited features or limited time. Some allow you to use only a small subset of functions, some give you only a very small usage quota, some give you all the functionality but only for a very short time. You will also find the term “Headless” something - headless CMS, headless e-commerce, and this comes from the fact that these products really come without a front end and template layer
- Why do we call it API Economy? This comes from the fact that, just like in “classic” Manufacturing, you use raw materials and utilities like gas or energy to produce additional value. obviously you build a product that provides an API, and you bill ( or not bill) the users of the API you actually build your own product, that consumes one or more APIs. The product is generating additional value, and you make your profit from that to cover the use of APIs Some APIs are build like platforms, and you can build additional features and functions that are not covered by it, and offer it to it’s wider ecosystem. A good example is for instance Salesforce, which was build as a platform from the very beginning, and was one of the first that even launched it’s own marketplace force.com to enable partners and other vendors to offer their services as an addition to their own product. As some of the vendors I will talk about are indeed headless and don’t have a frontend or templating functions, there is a huge opportunity to provide exactly that for instance.
- so…. what are these ominous APIs that I want to talk about, and what is this API Economy?
- So, why are those APIs awesome? Why am I banging on about this? First of all, they offer sometimes amazingly powerful functionality that would require years of engineering for yourself to provide them - for instance fantastic search capabilities, machine learning, data analysis, and of course, since we are talking about e-commerce, they can provide perfectly working shopping carts, promotion engines, image optimisation, and much more. Also, you don’t have to provide the computing power to run this functionality - they do it for you. This means a tremendous relieve for your IT department. Another really important fact is that they provide functions independent of platform or languages, which gives you the choice to use the ones where you are best at. So you can use PHP, Java, JavaScript, Python, Golang or whatever you think is best for your particular usecase. This also means a particularly great benefit in our e-commerce world as well: You can connect not only your web storefront, but also your mobile apps, your Point of Sales systems, your Warehouse, your sales assistant hand held and so on… If they follow the REST protocol and use JSON data format, it means that they are much easier to understand however there are some APIs that partially deviate from REST and use an approach called HTTP API because some people perceive pure REST to be incomplete for their means - so they encapsulate protocols and functionality through certain conventions in the payload, which means that some functionality is more obscured, and they are usually have a steeper learning curve. Most APIs are also billed by usage as mentioned before, similar to utilities like Gas or Power. however - some APIs have different billing models, for instance percentage of transaction volume (Carts, Orders, Payment), some APIs have a tiered approach to the offered functionality - i.e. you have to pay more if you use certain features A lot of API vendors also have great capabilities of offering new functions in a non-breaking manner - and therefore you get free upgrades.
- I think APIs are an epiphany for omnichannel commerce! This is an example of an omnichannel e-commerce system. I am in this business for a while and I have drawn up diagrams like that by the dozends. For sure this will also look familiar to some of you? This is only a small excerpt, but it already defines maybe 20 or 30 interfaces that a really mature e-commerce organisation needs to implement. It’s convoluted, it’s complicated, it’s potentially fragile, a nightmare, since you got all those different protocols and formats, synchronous and asynchronous implementations, all the different transformations and more, and you got all those different “leading systems” owning different bits of data. The OMS will come around and say HEY I am the OMS, I own all the order data. But the Storefront might say the same, and it might even say, hey I own all the customer data, and so on and so on.. and this diagram doesn’t even consider a Content Management System, a Customer Relationship system, different marketing systems, analytics, business intelligence and more. It doesn’t even include things like mobile Apps, POS systems and so on. All these systems want to know real time about orders, customers, availability, stock levels, loyalty information and more. If you were clever, you sold your client an Enterprise Service Bus - but this was really just another piece of complicated software, another server to look after, that is designed to patch this essentially broken thing called Enterprise Omnichannel Commerce.
- Now I am not saying that things get much easier for you, but there is a gigantic benefit that through APIs, you finally have a largely standardised and uniform, universal interface to fix all those workarounds and not-so-great solutions in the past - and many broken omni-channel promises: It enables a radical tearing down of silos! Because of the universal connectivity and not being proprietary to certain platform and languages, APIs are the ideal means to connect all your systems and devices. You can implement a consistent discount and promotion programmes throughout all your channels and devices through one single backend, you can access customer data, loyalty data, order data, product data, images and brand content through a unified interface and therefore provide a consistent message and user experience easier then it has been ever before. And on top of it, it is much easier for you to access all the data generated through all the different channels, and enables you to act upon them faster and in real time. And lets not forget the IoT-enabled fridge, which will be able to order the milk and butter when it’s in danger of running out, by executing a Web API request to your supermarkets delivery service. Or of course something like the Amazon Dash button, which allows you to order your hot sauce just when you ran out of it with the push of a button.
- You can actually use your tried and tested Content Management System to deliver the content - or another option that is almost too crazy to consider: You can go serverless! What does that mean? Do you know what servers are? Anyone here knows what a server is? A server are those things that fail right in the moment when you are not looking at them! And, well, does anyone remember web development back in, say, 1996? Have you played around with HTML and things back then? How did it work back then? You were editing a static HTML file, that you uploaded somewhere with FTP, for instance Geocities, or somewhere else. There were no application servers or anything else involved. A static HTML page won’t fail at any given minute when you are looking into the other direction - it’s just there sitting in a cloud storage, say S3 or elsewhere, and will be downloaded to the browser that is requesting it. There is really not much that can fail at all. Let me make a crazy, very daring, maybe even potentially hazardous thesis here: Web development and architecture in the next 5 years will actually move back to where it came from in 1996. If you are a web developer, you will be designing a static HTML page, and with the use of JavaScript SDKs by your chosen e-commerce API, you will be able to add transactional add to cart buttons and things. Content pages can be generated out of a content API (a great example is for instance the contentful Jekyll example project)
- Ok assuming you decided to go down the API route and you want to get out there, evaluate and select API vendors to build your next commerce platform. What do you have to look out for? Well first of all, carefully check and make sure they support the platforms you work with - PHP, Java, Ruby, JavaScript, iOS, Android should be actively supported in the form of SDKs. SDKs can be really helpful in getting started quickly, it abstracts all the boilerplates, networking code, gives you nice objects you can work with and it makes the learning curve flatter. Check the release cycles and change logs- make sure you are satisfied with the frequency of bug fixes and feature releases. They should promise you an SLA with less than 100ms average response time (in fact, <50ms should be the bar), and an uptime of more than 99.9% (in fact the bar should be 99.99% or more) I know for many retailers it’s extremely important to have data stored in Germany so make sure the vendors of your choice do offer their services out of data centres located within German jurisdiction
- I will go into that in more detail in a minute but you will find that the feature sets greatly differ. A commercetools for instance offers a very powerful and comprehensive search included in their system, whereas Moltin doesn’t have a search. Can you configure webhooks? Web hooks are something like the hollywood principle for APIs - don’t call them, they will call you Can you import / export CSV data? Many retail organisations have their data presently in CSV or Excel spreadsheets, and often it’s also the format of choice to communicate with other systems like CRM, Marketing and Does it actually have a comprehensive user interface / dashboard? Currently, you will find solutions with varying degrees of maturity, where the dashboard / user interface is only an alibi or doesn’t keep up with the development of new API features Is all the documentation available and accessible? The change towards APIs also ususally means that documentation is not hidden behind a paywall or only accessible by an exclusive club. The best API vendors make all their documentation available for everyone on their website.
- Some things to consider when you start using APIs - these are the things you probably won’t find the sales deck of the vendors, and these are some lessons I learned the hard way: They won’t work offline. Tough luck. Also, another point that I often encountered when a client was migrating from an on-premise of custom build solution: APIs are not as flexible in a way that you can’t customise the behaviour beyond the offered options. Instead they cover the relatively narrow cases they have been designed for. Some vendors offer more flexibility than other. And of course the application that consumes the API can do some customisation. Some vendors lack tooling - lacking SDKs, lacking command line tools, lacking user interfaces, that enable to to hit the ground running. Therefore the on-boarding can be bumpy and problematic. You need a strategy to address that, I will give some ideas later on. One thing I came across is that the import / export performance does not quite match legacy applications your clients might be used to - of course this would be much faster if you are working directly on a database. But the content of this database is not integrated throughout your whole organisation and all your channels, right? So that’s a bit of a trade-off. That doesn’t mean that it is not possible though to implement performant mass data import / export processes though. Also from a technological perspective, developing with APIs requires adoption of new programming paradigms such as asynchronous , parallel programming, message drive design, reactive, stateless etc to full leverage the power of APIs
- so…. what are these ominous APIs that I want to talk about, and what is this API Economy?
- Lets say a typical e-commerce organisation needs to build great engaging content, it needs to manage product information, it needs to process orders, manage a warehouse, and of course process payments, collect analytics data and do some Customer Relationship management and marketing. I totally understand that there are solutions out there that don’t quite fit in either categories, or in between different ones. I really don’t want to to talk too much about CRM, Payment and Analytics, these spaces are well populated, I am sure we all know lots of payment providers and analytics engines. You won’t really find many standalone OMS or PIM solutions at all in the API space- maybe because it’s obviously something that should be provided by a core commerce system, and an API driven core e-commerce system will actually threaten to make standalone OMS and PIM solutions obselete. And most of the players here are more or less dabbling into these areas. However you will find with Salsify a great solution, and NetSuite acquired OrderMotion a while ago and leveraged it to an API solution
- So what’s obviously interesting here are the E-commerce API platforms - and in this space you will already find a larger selection of players with a varying degree of maturity. I can give you a very brief overview here. YaaS.io is a big effort from SAP to provide a comprehense new cloud commerce platform - it’s huge, enterprise ready and got a marketplace, and it’s self-service sign up with open, transparent documentation and all! Oracle are offering a similar service, but at time of research I couldn’t find any open and accessible API information. commercetools is a good contender which has a powerful, fast and enterprise-ready API, flexible data model, very powerful search included, great approach in delivering new features non-breaking, but at the time of research there was no iOS / Android SDK Moltin are also a good contender, who have everything to get started quickly, including shop boilerplates in PHP and Node.JS and other platforms. They don’t seem to have powerful search features though. shoprocket, snipcart are solutions designed to turn an existing website into a transactional one. One thing of advise though - you will find many of those vendors using your GMV - gross merchandise value - as the basis for calculation. This sort of calculation somehow breaks the API economy, and can turn your business model quite unfavourable, especially if you are a retailer working with tiny margins, a B2B or a marketplace solution. I would suggest you to negotiate with them. Well, let me tell you a secret. Please promise me that this won’t leave the room, ok? All these guys really need you as their client! Getting clients is their live blood, being a cloud SaaS business and all! So I am sure they will be open to negotiations.
- Salsify seems to be great in a way that it’s designed to help you enrich your product data, and also to actually syndicate that data to differnt other platforms
- So this is actually remarkable - and I expect many other players to pop up in this space soon. Uber allow you to use their fleet on demand, through an open & documented API, to to deliver goods at a certain SLA. This means you can offer your clients same day to 1 hour delivery in certain areas and actually compete with Amazon whith this level of service
- So this is actually remarkable - and I expect many other players to pop up in this space soon. Uber allow you to use their fleet on demand, through an open & documented API, to to deliver goods at a certain SLA. This means you can offer your clients same day to 1 hour delivery in certain areas and actually compete with Amazon whith this level of service