For a number of years now I have watched CIOs attempt to get to a simplifed IT portfolio, and recently I have begun to think that this goal has been both a chimera and wrong in principle.
Rather than trying for some abstract level of simplicity, I are coming to think that the real challenge for CIOs is to choose which type of complication, which type of complexity the enterprise can most easily live with — and then stick to approaching that as a goal.
Complexity in Packages: For many organizations, a simpler IT portfolio is one that is almost completely composed of packages, preferably from major, stable vendors.
In one case I examined recently, a reduction of 90% in the number of applications in the portfolio was considered, through consolidation into a core (ERP base) package, a secondary industry-specific core package, and a limited number of other single-purpose packages and occasional in-house applications.
While this reduction certainly achieved the goal of simplification and cost reduction (some 900 point solution applications and bridging spreadsheets or data extract & reload operations would have been eliminated), it created a new type of complication: upgrading the packages that remained.
The core package, for instance, would have served the needs of over 40% of all functions in the enterprise, and in addition to using a much larger number of available components from the vendor further components were to be authored (so as to use the embedded information architecture and services).
Coordinating an upgrade cycle of this unit across that many disparate user areas would have put the IT organization into an annual or biannual major freeze cycle — and a failure to stay current would have undone the architectural benefits offered by the vendor’s own plans to achieve a full service architecture and integrated univocal data model within its offering.
Coordinating, in turn, the necessary bridges between the two core packages would have required a change touching nearly 80% of the firm and taking weeks to test properly at each change.
This, by any measure, is complexity: the gains in software simplification have been overshadowed by the needs of change management unleashed by such concentrated service sets.
Complexity in Applications & Services: The other approach is to rationalize the portfolio — often reinvesting across the board — but producing a company-specific architecture with unique services and a corporate single data model into which such packages as are purchased must be fitted.
More complicated on the surface, this approach can actually offer the enterprise the ability to manage change in smaller and more focused “chunks”.
Care in the selection and use of core packages must be taken so as to not duplicate function (SAP, for instance must run its financial components to run any others, so if SAP is used it should become the financial core, even if a Oracle/Peoplesoft for HR, etc. is used) and good design of application connections, using journalling bridges that allow for items to change (and be backed out if necessary) will be required.
The result, however, can be clear in purpose and design, despite the much larger number of components involved.
What is most important in tackling complications and complexity is to open the ability to engage in change while minimizing future risk and disruptions, so as to be able to leverage the IT value chain fully.
Architects should be challenged to model (at a high level) both approaches so as to conduct a proper risk assessment and determine where on the continuum between the small number/big block approach and the large number/small block approach the needs of the enterprise can best be met.
This — not some arbitrary number of items in the portfolio — is the true definition of simplicity.