Flash forward a few years, and I was able to cut my chops a bit in the real world of business applications analysis. During this timeframe, I learned quite a bit not just about basic architecture (database structure, web server, application server, etc.) but also third-party integration and a healthy dose of network and systems management, all tossed in for good measure. This early education has served me well as I've begun to take a closer look at both popular and niche Spend Management applications in the market. This is one reason in particular a new entrant in the spend analysis space has been so successful in ramping their customer base and beating incumbents. In this case, it turns out the architecture and design around classification -- and the ability to classify any type of dataset to multiple taxonomies without requiring a multi-hour or day wait to update the set -- does matter in the real-world for organizations that want to engineer in flexibility to spend analysis deployments.
Yet in the broader world of enterprise applications, including P2P systems, I believe the importance of true service oriented architectures (SOA), when it comes to driving both deployment flexibility and external integration, is extremely important. A lack of a SOA model is the reason one of the best known vendors in the sector has had such a challenging time with anything-but-vanilla external systems and data integrations across its SaaS/cloud-based products, not to mention making its latest SaaS enhancements available in the supposedly same code base for CD customers. Perhaps this organization should have listened to Amazon's CEO, Jeff Bezos, who, according to a former employee who ranted in an internal note with his next employer that his former boss changed everything when he required the following:
- All teams will henceforth expose their data and functionality through service interfaces.
- Teams must communicate with each other through these interfaces.
- There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team's data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.
- It doesn't matter what technology they use. HTTP, Corba, Pubsub, custom protocols -- doesn't matter.
- All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.
Of course it's a philosophy like this that enables a technology organization to truly build a platform, not just a set of loosely coupled applications or web storefronts. In the Spend Management space, we're facing a lack of true platforms in this sense of the definition. Yet by prioritizing a true platform in the sense of the word when they seek to build out their Spend Management architecture -- rather than just the feature/function capability that business applications expose -- organizations can begin to engineer in true configurability, virtualization, integration, lower total cost of ownership, usability and ultimate flexibility in the UI layer.
Yet of course if you go down the traditional Spend Management applications route -- even with popular "cloud" solutions today -- you'll be pouring concrete that can certainly grow with your business. That is, if you take the sledgehammer to the old top layer and slop on a new surface, hopefully not damaging anything underneath or around it, let alone trapping the corpses of others who were trying to desperately shore up the foundation at the time of the updated "pour." When I come around to exploring this topic again in the next installment of this rant, I'll delve into the specifics of how true platforms and service oriented architecture models can drive the type of value that CPOs, VPs, directors, category managers, analysts and just about what anyone who touches procurement is looking for, but is often left wanting after traditional roll-outs and deployments, SaaS, cloud or otherwise.