CIOs: Have You had Your Annual Application Checkup?
Many of us do a physical with our doctor on yearly or biennial basis. The question that I pose today to CIOs is why don’t you have a checkup for your applications on a regular cadence too. Now, it is worth noting that CIOs tell me that they ask their enterprise architecture team to be the forward, business facing component of their organizations. And architects clearly do need to create a regular structure for IT based on the service and product line functions/capabilities. However, I believe CIOs need to be in the middle of how their future state of architecture meets their future state operations. They need as well to make sure that their organization is working to modernizing their enterprise architecture.
So the question should be why isn’t there a yearly applications/service audit. COBIT 5’s guidance to IT organizations is that they actively manage the level of satisfaction of business executives with IT’s responsiveness to new requirements and the average time to turn strategic IT objectives into an agreed-on and approved initiatives. As well, COBIT 5 recommends that IT teams optimize their IT assets, resources, and capabilities by the frequency of capability maturity and cost optimization assessments.
Reality is different from best practice
Unfortunately, in my discussions with a leading consultancy on application retirement, I have learned that practice is often different than expectation. It typically takes a significant event of some kind—a sales drop, a merger, or another type of business change—for an IT organization to significantly reconceive their IT environment. But is this really a good thing for IT’s business stakeholders? For me personally, the proof that an audit of applications and application architecture is needed regularly is in the fact that most IT organizations still spend well over half of their budget on “keep the lights on” expenditures. And this is at a time when businesses need greater business agility as well as new business capabilities to respond to quickening marketplace changes.
At a large insurance company, they told me that 11 months after they had successfully brought up a new version of their sales force automation tool, they were still maintaining two versions back of a prior system. The new instance was running great, but the business, without understanding the implications of their request, had IT keep the outdated prior versions running because their might be some data that wasn’t successfully transitioned. Meanwhile, at a large manufacturer their CIO told me that they had data-marts that were created for a business priority that may no longer even exist. In both companies, without an IT/business audit huge sunk costs remained for systems that did not have continuing value to their enterprises.
Regular review increases business agility and decreases business cost
From an enterprise architecture perspective, these approaches limit the enterprise in cost and in business capabilities. According to Jeanne Ross, “traditional approaches to IT development occurred in a set of silos. Individually the applications work fine. Together they hinder company efforts to coordinate customer, supplier, and employee processes—they do not form a foundation for execution. And the company data, one of its most important assets, is patchy, error-prone, and not up to date” (Enterprise Architecture as Strategy, Jeanne Ross, page 7).
Process standardization, however, can create efficiencies across business units as well as greater business agility. “Implementing standardized, digitized processes benefits are simpler technology environments, lower cost operations, and greater agility”(Enterprise Architecture as Strategy, Jeanne Ross, pg 11). And it is more and more clear that “business agility is becoming a strategic necessity” (Enterprise Architecture as Strategy, Jeanne Ross, pg 12).
Regular review drives enterprise architecture maturity
At the same time, according to Jeanne Ross, there is a clear evolutionary process for enterprise architecture. The only way to move through each step, however, is to be conscious about where you are in the process and where you are ready to go. Each step requires a regrouping on enterprise architecture and applications. Each is a point for the checkup and cause for reconsideration of applications within the service portfolio.
As you can see maturity moves from a business silo architecture to first standardizing the technology that is used within the architecture. This step can create immediate cost reduction because there are less systems types to support. In the optimized core step, companywide data and process standardization occurs as appropriate for the company operating model. Let it be clear, the operating model selected relates to how connected or not a company’s businesses are. And lastly, the company enables the reuse of loosely coupled IT-enabled business processes to preserve global standards while enabling local differences. So in summary, step 2 fixes hardware. Step 3 fixes architecture. And Step 4 creates software component reuse while allowing for appropriate differences and tailoring. This final stage fits well with what one CIO told me recently. “CIOs need to become the orchestrator of business services vs. the builder of operational services. Cloud and loosely oriented partnerships is bringing vendor management to the forefront”.
How to optimize the core
If a significant portion of your IT budget is still tied up in retaining and maintaining legacy applications then it could make sense to consolidate what you have. The important thing is to look for points to evaluate your application portfolio. If appropriate, your legacy data, as well, should be compressed, consolidated in an archived while retaining secured access. This allows you to take out cost while you assure compliance to your corporate data governance. Whether your applications are custom built, legacy mainframe, on premises, or in the cloud, if you’re implementing, updating, migrating, retiring, or consolidating your application portfolio, you need to make conscious decisions about your applications and data. Many times, a new architectural approach is needed to ensure existing and new applications co-exist without excessive complexity. Without this, application data migration can fail. By having an architecture, functionality, visibility, and methodology you can manage all your application data, this streamlines processes, accelerate projects, reduce costs, and eliminates business risk.
IT organizations need to increasingly to have a regular application checkup and to use this as an opportunity to set goals and drive business agility and improvement. To do this, I have suggested a number of things to consider along the way. One additional element is to consider the cost for current approaches versus other alternatives.
Blogs and Articles