Friday Rant: What are the Benefits of a True Single End-To-End Platform or Suite?

I had a colleague pose this question earlier this week: what are the definitive benefits of a true single end-to-end platform/suite built on a common data model (one that is a platform in the true sense of the term, allowing for third-party development through open APIs and possibly even a defined configuration/development environment to enable third-parties to create their own applications on top of it)? Do you even need developers, or will technical business analysts do? Even though we've tackled this subject before, I thought it would make sense to list out all the benefits of end-to-end platforms.

Spend Matters readers should realize this list is extendable to just about any type of business application or technology area. It is not specific to the procurement or supply chain domain. Yet in this sector, end-to-end platforms are few and far between. SAP, Oracle, Emptoris and Ariba, as examples, each sell a set of solutions that may (or may not) be tightly integrated but are certainly not built or delivered on a single platform environment. In fact, in the case of SAP, platform proliferation (both internal and partner) has resulted in at least five separate platforms, by our count, even before the addition of the multiple separate platforms that Ariba will bring if the transaction closes.

In the procurement sector today, end-to-end single platform/suite models we're aware of include b-pack, Ivalua and the Intenda Solution Suite (all include areas such as spend, sourcing, contracts, eProcurement, e-Invoicing, supplier management, etc.) Coupa is headed down this path, but has a limited functional footprint outside of P2P. The same is true of Zycus. TradeShift is probably closest to the vision of building a true platform business model on top of which others can build additional capabilities within the broader procurement area, but their functional footprint is very limited today to e-invoicing and buyer/supplier P2P connectivity and document exchange.

Without further upfront analysis, here is a laundry list of integration benefits of single end-to-end platform/suite environments:

  • Integration (external systems) -- external systems integration (e.g., ERP) can be simplified by an order of magnitude across a suite, 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 will typically be 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
  • Greater power for internal analysts to configure solutions rather than requiring a development resource for configuration, customization and integration (even in the case of integrated SaaS capabilities with multiple suites, development and integration resources are much more likely to be required when third party systems integrations and linkages are required)
  • Integration (within the application suite itself) -- enough said. 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
  • Reduced integration costs between procurement 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
  • Single data model and single supplier master combination -- when taken down to the item level for spend analysis, this is a holy spend grail of sorts. Just don't sacrifice yourself as part of a crusade without knowing what you're getting into
  • Cross-module development speed -- typically faster release schedules as well as greater functional enhancements (integrated) with each release
  • An agile approach to configuration is possible -- Involve the user the whole time. New product functionality takes hours and days and not weeks or months, bringing flexibility to the client and accommodating fast changing world economy scenarios
  • Bugs-be-gone -- typically reduced bugs (and more quickly zapped) in upgrade process in a single suite environment
  • Upgrade speed and ease of upgrades to future integrated suite releases
  • UI consistency and navigation beyond single sign-on – this can vary dramatically in the case of integrated tools that appear to be a single suite but in fact are built on multiple platforms, especially in the workflow and data model/mapping trenches
  • No lost time on kludges (especially process or workflow kludges) between modules
  • Breadth of network and benchmark intelligence (in the case of cloud-based end-to-end platforms) cross-suite
  • 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. TradeShift, as mentioned previously, is the ideal archetype of this
  • Deployment agnostic. Deploy in the cloud, on your own servers in the cloud, behind your firewall or in a hybrid manner. True end-to-end suite and platform providers do not dictate deployment models, they follow your business and IT strategy. Mind you, very few end-to-end suites also take a truly flexible platform centric deployment approach. Most are obsessed with deployment in the cloud because that's where the valuations are
  • You are not dependent solely on your suite provider's roadmap and bug fix releases. It can happen on site, quickly and effectively. True single platform providers offer you the tools to keep versions, site-specific changes and upgrades in line. You do not loose your upgrade path

I'm sure we're missing some of the benefits of true end-to-end integrated suites and platforms. Chime in if you have anything to add!

- Jason Busch

Share on Procurious

Voices (2)

  1. Jay Merenda:

    The problem I am seeing with suite vendors is that "Best in Suite" never means "Best in Breed". Providers I am aware of are lacking good functionality in critical areas such as SIM, SPM, Risk Management, Spend Analytics, and true Category Management. In my circles I am seeing more of a shift towards Best in Breed with critical date (e.g. clean supplier data) sync’d accross them. I do not see a common UI being a driver as the Best In Breed are typically very intuitive and user base typically different.

  2. John Shaw:

    I’d like to add one:

    Common Nomenclature facilitates adoption: Every software application models business ideas using different logical concepts and follows its own standards. When the UI, key terms and common functions are the same across modules you lower the amount of content users must be trained on (Example: Searching is the same everywhere) and you ultimately reduce the amount of change you are trying to introduce in the organization because the gap from module to module is much smaller.


Discuss this:

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.