Can you imagine this scenario? You?re monkeying with your app of choice, say from Apple or Microsoft or perhaps from any of the throngs of vendors pouring new apps in to the consumer market. The app in question is OK, but you?d really like it to do something else ? something it doesn?t currently do, and furthermore, the feature you want is likely only of interest to you. So you call the vendor. ?Hello Apple? Yeah, I?d really like to have this new doohickey in my iTunes app. Can you build a custom version of it just for me? You can? Hey, thanks.?
Not on your life! Getting a vendor on the phone at all is difficult enough. If you actually have the chutzpah to ask them to recode their app just for you, they?ll laugh you off of the Internet.
Yet while that scenario strains credulity in the consumer market, many enterprise software customers are used to asking for code customizations from their commercial off-the-shelf (COTS) software vendors. After all, such software in the enterprise space can cost millions of dollars in licenses, and many more millions over time in maintenance. And what is software maintenance, when you get right down to it? Sure, it?s regular updates that everybody gets, but that?s not why maintenance costs you the limbs of your firstborn. The COTS vendors realize you?ll be asking for code customizations, so in many cases, maintaining such customizations is where the maintenance dollars go.
Of course, this problem is as old as the COTS marketplace, and vendors have been gradually getting wise. The reason customization is such a bear to deal with is that every code customization branches the code ? making regular updates difficult or impossible. As a result, over the years vendors have reworked their software to be increasingly configurable.
The goal of configurability is to provide customization and personalization for customers while maintaining a single, easy to upgrade codebase. As long as the updated codebase is backward compatible with older configurations, then everybody?s happy ? in theory. But in reality, it?s virtually impossible to shift all possible customer customization requirements to the declarative configuration layer. True, today?s enterprise COTS packages typically have configurable user interfaces, and perhaps offers features an administrator can turn on and off for different users, but more sophisticated customization requirements still require changing code.
The good news is, it?s possible to solve this agility-killing problem via the part of the Bloomberg Agile Architecture Technique I call a Business Agility Platform, for want of a better name (the marketplace may do better, but I?ll stick with the moniker Business Agility Platform in the meantime). I introduced this platform in a previous blog post when I introduced the notion of the tool-building platform (see the figure below).
Instead of expecting vendors to offer configurable software their customers can use to create customized configurations, I introduced a third layer. The tool-building Business Agility Platform offers affordances to developers who use it to create configurable applications by building abstract models of those applications. As a result, a wider range of users (perhaps developers, perhaps not) can use those application-building tools to build their applications via configuration alone.
In this model, upgrading the Business Agility Platform is straightforward, as all upgrades will simply add affordances ? but existing affordances will remain, making the platform fully backward compatible. Furthermore, when a customer requires a change to a tool that they cannot make via their application configuration capability, then developers can customize the application-creation tool by changing the abstract model, which is inherently a reconfiguration, as the abstract model consists solely of metadata the underlying tool-building platform can interpret. Problem solved.
This three-layer approach is relatively straightforward, and each element of the approach ? even the abstract models ? leverages existing, well-established software approaches. The obvious question, therefore, is why aren?t more vendors building their offerings this way?
The answer: it?s not the software part of this story that?s new and different. It?s the architecture. This vision cuts across existing architectural silos, including software architecture, systems architecture, business architecture, and enterprise architecture, to offer a specific approach for building software that supports enterprise business agility requirements. And changing architecture is hard, especially when the new approach cuts across different specializations. The good news: the world is ready for Bloomberg Agile Architecture.
