So what do I mean by modular consumption? In the old days, you know, back in the 1990’s, most companies bought and deployed a full range of software products for running the business, including financials, human resources, supply chain, manufacturing, etc., mostly from a single vendor in a pre-integrated ERP suite. In some cases best of breed or new and innovative software was added to the ERP suite, and in many cases that software was from a different vendor, but in general, the 1990’s were the days of the one vendor suite deployments. This happened for many reasons, most IT departments had operated in single vendor environments in the pre-client / server days and frankly, integration in the early client / server days was hard (actually I suppose integration is still hard, although much less difficult with the current crop of SOA-based apps). To get the advantages derived from integrated business processes it was necessary to get large, siloed applications to work together, and this was most easily accomplished by a single vendor suite. These full enterprise suites were / are by design behemoths with millions of lines of code and lots of process complexity developed in the waterfall methodology with a release cycle of years at best. They do after all, have to accommodate a broad swath of industries, at least coming reasonably close to providing an operating base for each company. On top of that base of course, most companies added customizations, extensions, and custom apps to meet the specific business needs. The whole mess (and I use that term with the greatest affection) was large, difficult to maintain and even more difficult to change. Flexibility, if attempted at all, was mostly a long and expensive process of modifying / customizing the existing suite and maybe adding / integrating a new application with some new required features and functions.
Software as a service, which is now a dozen or so years mature, has pushed on many of these paradigms, changing release cycles to weeks instead of years and offering pre-packaged integrations that could allow cloud based apps to work with traditional suites. The original SaaS apps were very feature focused around a single business area (sales force automation, talent management, travel and expense management, etc.). To meet these new, faster incremental release cycles many of the SaaS vendors have moved to an agile development model build around collaboration, iteration, process adaptability and team work.
As the economy has remained unpredictable and the depth of the recession combined with many other factors have taught IT organizations new behavior patterns. In the past IT projects were often broad and deep, with long time lines and broad changes. Companies are simply not changing out suites in broad rip and replace projects anymore, it’s not an affordable model. Instead, more and more, we see companies adding modules of functionality around the edges of existing systems to get greater flexibility and add new innovative functionality to meet changing business requirements. This new approach is modular consumption. As a service has spread outside of apps as well, and more and more, companies have the option of adding more granular modules of services as needed, including storage, security, development platforms, and even compute power. Up and down the software stack we see more and more granular modules or components that can be assembled to give greater flexibility while more rapidly addressing changing business needs. Business strategy, once a process that might be adjusted every few years is becoming operationalized and is driving the need for system and organizational flexibility. To meet this new level of nimble business strategy, software must become infinitely more flexible.
This brings me to this idea of componentization of software. Modules of functionality must be more granular and integration more “plug and play” to give businesses the ability to modify business strategies in near real time as competition drives this new level of flexibility. The Internet, global connectivity and changing expectations on the part of customers, partners and employees add fuel to this need. The days of the development project to accomplish what now needs to be ad hoc configuration have to change. Businesses can’t afford this approach and must have the capability to adjust strategy in an ongoing way. Information work is about ad hoc processes and teams, and the flexibility to adjust to this ad hoc approach has to extend to the underlying systems. The platform of the future must accommodate plug and play components that can, in lego-like fashion, be snapped together in a near infinite number of different configurations. We’re starting to see this type of approach, particularly below the apps layer in the stack, but also in application components sitting on an underlying platform that facilitates this new requirement of flexibility. No change in enterprise software will happen overnight, there simply is too much invested in legacy systems that are good enough to see a broad rip and replace approach. The componentization process though, will open up more opportunity to leverage the existing, aging core of functionality in new ways by adding the new capabilities around the edges. Eventually this will lead to new platforms and those new platforms will accelerate the changes, replacing the old suites with a new modular, flexible as a service infrastructure and SaaS process components that allow for the needs of flexible business strategies.