EA Voices

My old friend Dan French penned an interesting blog last month. He was thinking about how the common answer today to the question of how to drive efficiency (and thus profit) in big companies is around transformation and standardisation in common proce…

My old friend Dan French penned an interesting blog last month. He was thinking about how the common answer today to the question of how to drive efficiency (and thus profit) in big companies is around transformation and standardisation in common processes, a shift to shared services and common, single instance global ERP systems. Dan pushes back against this orthodoxy using the metaphor from a sailing friend, suggesting the very interesting question to ask with all these initiatives is “will it make the boat go faster?” A leading indicator of success in ocean racing is to have a fast, and consequently light boat, and the corollary in business is the question of whether independence and individual business unit responsibility actually delivers more than enterprise level process standardization?

Dan doesn’t actually answer the question, he merely asks how many global leaders in their industries take this particular “road less travelled”?

I discussed the metaphor with one of my customers the other day and he said that in his enterprise, individual business unit responsibility has been a disaster in IT terms. The huge number of legacy applications represent years of local decisions, of reinventing the wheel over and over again. He used another interesting metaphor – suggesting his enterprise was like a tractor pull – where the more successful they were, the greater the weight they had to drag behind them, and slowly and surely that ever-increasing weight is killing them.

And of course this question is relevant to pretty much every large enterprise in the world. As you get big and successful, the agile operating models of early years need to be matured. But frequently these enterprise level transformation initiatives fail, or take excessive time and cost to deliver. The promise of standard COTS products frequently turns into a multi-year nightmare of lowered expectations and massive increase in costs and under-performing business processes.

So enterprises engaged in tractor pull like efforts need transformation, but would probably prefer a fleet of individual racing yachts to a single Titanic. But surely there are other options? Is there not a middle course?

At CBDI we ourselves advocate a service architecture supporting a hierarchy of services with more stable, standardized services in the lower (business state managing) layers and more agile, adaptable services in the higher (capability and process) layers. In this model, variations across business units are managed by patterns that vary behaviors depending upon context and business rules. And there are numerous highly successful examples of this strategy. But is this sufficient? Is this model sufficiently lightweight and agile like a racing yacht?

What I see emerging is an evolution of SOA, in which everything, at all levels, is componentized managed in a framework that coordinates concurrent standardization and differentiation. The figure below shows the key to standardization and differentiation is the configuration catalog that governs the use of components as configuration items.

Probably the most important element of the framework is the Reference Model. Frankly most companies invest insufficient effort in this area. A good reference model is NOT a clone of an OASIS, CBDI or TOGAF meta models, it’s an enterprise specific model that defines how a specific enterprise works. By all means use existing models for the basics, but they must be customized to reflect the specific enterprise. Good reference models are hard work, but they have incalculable value – because you are doing the heavy lifting at the very earliest stage. The reference architecture then clarifies the types of component and their relationship to delivered business processes and solutions.

The central part of the framework is to establish the mechanism by which standardization and differentiation are managed. A Configuration catalog is effectively a logical version of the CMDB. It records the Configuration Items available for a Capability (and it’s a long list including business process, workflow, services, implementation components, portlets, templates, policies and so on). Each Configuration Item is attributed with flexibility options and crucially constraints (policies). The Configuration Catalog is effectively a Software Factory Schema, except that its scope is much broader than software development, covering the entire range of artifacts including COTS products, internal and external services as well as custom applications. The Configuration Catalog is the core driver of architecture integrity, providing active governance over the configuration and reconfiguration of components. If a business unit believes it must diverge from the standard configuration, the question will be, is this purely localized behaviour, or is the localized requirement actually part of a broader demand signal? Can the localized behaviour be accommodated within the enterprise reference model, in which case further configuration is not compromised, or is this a genuine one-off?

Over the years I have advised many companies on setting up asset repositories in pursuit of asset management and reuse. While the asset repository is important in recording capability and dependency, it is typically not used as an integral part of active governance right throughout the life cycle, commencing at the planning stage.

For large companies with extended, federated operations, the Configuration Catalog capability represents a significant capability maturity improvement over “basic SOA”. In fact it’s an implementation of a broader component based model that orchestrates a broader range of assets. It allows active management of standardization and variation across business units and geographies; to encourage freedom of action where it’s appropriate and to exert mandatory standardization where necessary.

Managing standardization is not a trivial task – it is a 15 letter word after all. But mandating de facto industry standard COTS packages for strategic business operations is unlikely to drive competitive advantage. Active governance over localization and standardization will allow a concurrent loose / tight enterprise which facilitates a heterogeneous portfolio incorporating, if you will permit the metaphor, fast ocean racing yachts alongside super tankers to accommodate a range of business requirements. And it will make the overall boat go faster!

Ref: Dan’s Blog