Even though we’re a bit less qualified to write about apps and platforms compared to some truly geeky technologists we know, it’s important for general Spend Matters readers (on the procurement and supply sides) to understand the massive scale of how the application and network market is going to be transformed in the coming decade. This will occur as companies make buying decisions for applications as much on the networks and platforms on which they’re built — and/or integrated with — as the functional capability of the provider offering the particular fit-for-purpose tool (e.g., eProcurement).
This represents an emergence of the platform or stack to center stage — even for business users. Historically, most folks in procurement didn’t care what underlying platform a solution was built on. With one exception: a solution might be somehow tarnished by being built on Microsoft technology versus Java, Ruby, or something else (which we’ve all gotten over, thankfully). Except for biased software companies themselves, no one – I repeat no one – has ever bought a procurement technology based on what it was developed in. Rather, functionality, usability, scale, experience, reputation, interoperability, and many other factors came into play in past technology buying decisions. And the MSFT question no longer matters, thank goodness.
Yet looking ahead, precisely the opposite is going to happen. “Apps” – not applications – will be purchased on top of platforms (a different sort than just development platforms of the past), and the best platform (or the one that achieves the most scale and reach) will emerge the victor. This has already happened in B2C commerce and fulfillment with Amazon emerging as the winner with its broader platform merchant game (which now extends to financing, warehousing, fulfillment and other value-added services), not to even mention its Amazon Web Services (AWS) cloud hosting, and virtualization capabilities. And it’s also happened in the mobile world, with Apple serving as the most important gatekeeper to developers through its App Store interface (Android also factors into this argument and equation, although from a different standpoint).
So far, however, we haven’t seen companies in a business-to-business or procurement/supply chain setting put the platform decision ahead of buying applications, despite distinct advantages. This will change more quickly than you might imagine, we believe, because with the right “gatekeeper” model, platforms can ensure interoperability between all of the data models, workflows and processes with the apps – both third-party and those built by the platform company itself. Imagine, for example, plug and play connectivity for e-invoicing, eProcurement, supply chain financing, contract management, and related applications on top of a platform regardless of which provider builds the individual app.
To get somewhat technical for a minute, this requires an externalized services oriented architecture (SOA) approach. As we’ve written about in the past, a platform built in this manner has a number of advantages:
- Integration (external systems) — external systems integration (e.g., ERP) can be simplified by an order of magnitude across a suite or set of apps, given a common underlying data model and simplified API/web-service integration environment. Integration can also be better with external systems because of the ability to expose third-party systems data anywhere in the application
- SOA and Web Services are typically a design principle rather than being slapped on afterwards. This on its own brings easy and simple integration methods to the suite. Suite providers see traditional complex integration taking a week or two, not months
- Integration (within the platform suite itself). Don’t discount the out-of-the-box benefits, for example, of integrated supplier management and sourcing capabilities that are built on the same underlying data model and architecture, or those native to a particular platform ecosystem
- Reduced integration cost between products/modules. For example, item or vendor master integration that links a supplier portal, supplier management toolset, supplier master(s) and item master. These integration costs can be very significant in the case of a multi-suite/toolset environment even within just procurement-related applications
- Third-party apps and development capability to enable outside individuals and organizations (even clients) to rapidly develop custom “apps” that are fully integrated across the platform environment; including apps developed by internal IT departments!
A true platform approach delivered through a network would allow the best-suited vendor (for a particular customer) in each app area to serve customers on top of the platform with all data working together (e.g., with workflow, permissions, matching, validations, archiving and synchronization happening both on the app-level as well as in the network).
As an example, such a model would allow a company to chose Coupa or Ariba for eProcurement, Basware or ReadSoft for e-invoicing, CombineNet or BravoSolution for sourcing, Aravo or Hiperos for partner/supplier management, and SciQuest (Upside) or Novatus for contract management and have all of these future “apps” interoperate out of the box. It would also allow for more niche solutions to work together with the network and these broader functional applications as well (e.g., discounting/payment, total cost modeling, transfer pricing optimizers, risk alerting, etc.)
In Part 2 of this post, we’ll explore how connectivity and multi-tier components of this vision begin to work their way into the network/platform equation – and prove transformative for our businesses in the process.
How should procurement and supply chain leaders think about systems architecture? Spend Matters PRO Subscribers can also read:
- The Trouble With Tribbles and the Problem with Portals (Procurement Information Architecture Part 1)
- Procurement Information Architecture Part 2: Portal Infrastructure
- Procurement Information Architecture Part 3: Analytics
- Procurement Information Architecture Part 4: Master Data Management
- Procurement Information Architecture Part 5: Workflow (System of Process)