One of the advantages of being in the software industry for a long time is that I can watch trends come and go. Some of them many times. Take the buy versus build argument: is it better for an organization to build a system (for its own use) using best-of-breed components, or buy a best-in-class monolithic system from a single vendor? As with all things software, the answer is “it depends”: it depends on how well the company’s needs are accommodated by a single-vendor solution, and how much the company’s needs are expected to change on an ongoing basis.
Almost every end-customer organization that I talk to now, either in my consulting practice or through industry contacts, is deploying an in-house digital automation platform that allows them to quickly assemble capabilities into new business applications. Since business applications tend to be process- and case-centric, organizations have often ended up with a BPMS (or what Gartner might call an iBPMS) as a single-vendor solution for the core of their digital automation platform, although ERP and CRM platforms such as SAP and Salesforce are also making a play in this space.
BPMS — once (more or less) single-purpose systems for modeling and managing processes — have, Borg-like, assimilated so many other technologies and capabilities that they have become the monolith. If you sign up for their process management capabilities, you may also get decision management, analytics, event handling, user experience, social media and many other capabilities in the same box. This is what allows BPMS vendors to market their products as complete digital automation platforms, requiring only a bit of wiring to connect up with line-of-business systems and data.
If there’s one constant in how organizations work, it’s that they will outgrow their systems as their business environment (constantly) changes. And that’s exactly the problem with any monolithic system: there will certain capabilities that no longer meet your changing needs, or a disruptive new vendor or product that could replace specific capabilities with something transformative. Without the ability to decouple the components of the monolith, you may be stuck using the unwanted capabilities; at the very least, you’ll still be paying maintenance and upgrades for the entire suite rather than just the parts that you’re using.
The result of all this is that I’m seeing organizations starting to build their digital automation platforms with much more granular components, and BPMS vendors offering their products in a granularity to match that. It’s this pattern that I’ll be talking about in my bpmNEXT keynote in Santa Barbara on April 16, “Best of Breed: Rolling Your Own Digital Automation Platform using BPMS and Microservices”. Hope to see you there.
Hi Sandy, interesting to hear. My take is that large corporations AND their technology partners are less competent than ever in managing the complexities of technology and application integration and while some may be foolish enough to try and build a digital transformation platform of their own they will fail miserably. The problem is that the partners who recommend that really do not care how much it costs and if it ever will work differently. The new paradigm is not to develop anything at all and not having to integrate and not having to chose between BPM or ACM or any other acronym. A certain pragmatic approach that will provide a communication-focused user interaction between staff, partners and customers will be the future. Software development or complex integration is not a solution … IT IS THE PROBLEM! All the best, Max
Hi Max, thanks for your insights. I work with a lot of organizations on a consulting basis, and have found a definite split between what works for small and mid-sized companies, and what works for large companies. I agree with you that building a platform is NOT the solution for most small and mid-sized companies (assuming that their business is not software development), and that they should definitely be looking at the all-in-one platforms to help them build business applications. For large organizations, however, things are more complex in part because of the legacy of software development that they’ve had for decades. In some cases, they have built most of their own system from the ground up because nothing better existed at the time, or because they thought that their needs were very unique and they could build software platforms better than a software company.
Whether or not that is true (usually their system requirements are not that special compared to their competitors, and usually their software development practices are outdated), they have an existing infrastructure created from their own development, off-the-shelf software, and bespoke applications created by third parties but not maintained. Scrapping that and moving to a monolithic new platform is almost never an option, and they need something lighter-weight that can piece together their existing components while allowing for the easy introduction of new capabilities as they age out the old stuff.
In a perfect world, organizations would buy a perfectly-fitting off-the-shelf solution to their system needs, and it would be updated with exactly the features that they need as time goes on. Unfortunately, that’s not the case: there’s so much customization for some all-in-one systems that you could spend the same or less effort assembling the same capabilities from best-of-breed services and end up with something more flexible and extensible. I’m seeing the best-of-breed trend emerging in many large organizations now, and plan to talk about some of the ways that that’s happening successfully as well as some of the pitfalls.