I get a chance to work with CIOs in various capacities that usually involve major business challenges their organizations are facing and how IT can collaborate with business to address those challenges. These discussions are generally a precursor or follow-up to a strategic assessment, which tends to surface the expected technological challenges along with a few surprises. The surprise is not that IT has layer upon layer of fragmented, heavily redundant application and data architectures built on aging technology. This is unfortunately the norm. The surprise lies in why these problems keep multiplying and attempts to address them often turn into the next failed project. The fact is that issue analysis, problem definition, planning and funding all begin with the business and more often than not, these concerns lie behind a shroud of organizational siloes, fragmented customer perspectives and myriad business dialects.
The haze that clouds our understanding of issues, solutions and scope is evident in research and in practice. For example, Standish Group has been telling us for years that the number one reason behind failed or “challenged” projects is the inability to understand what the business wants. This is no surprise. The business does not speak in a common voice, has limited ability to see from one business unit to another and funds solutions based on vertical funding models that are, by definition, scope constrained. The defense mechanism business units use for launching fragmented projects is that they don’t want to “boil the ocean”. But in reality, these projects are piecemeal fixes to larger problems that can easily be decomposed into manageable solutions. In other words, the boil the ocean analogy does not hold water.
Consider a full service insurance and financial services company that has multiple divisions and product lines. A given customer may have products from several divisions, but views the company overall as a single business. Yet individual business units view that same customer from their own narrow perspective, oblivious to cross-product line impacts. This is just one example of viewing customers and issues through a narrow lens. There is little visibility into a wide range of horizontal challenges, yet business units make major investment decisions every day that fail to address the underlying issues and ultimately degrade the overall customer experience.
The CIO sees the big picture because the IT organization is responsible for ensuring that cross-functional business solutions are deployed to address customer experience, competitive requirements, regulatory demands and a host of other issues that are often beyond an individual business unit’s line of site. The CIO cannot deliver cross-functional strategic solutions, however, when each business unit is funding and driving narrowly defined point solutions to horizontal problems, with no visibility into the big picture.
The bottom line is that the inability of the business to speak in a clear, consistent voice and articulate critical root cause problems and investment focal points from a holistic perspective is causing IT to deliver more fragmented, redundant and counterproductive solutions. Sometimes these projects fail, but more often than not they end up jamming piecemeal fixes into the existing patchwork quilt that characterizes most application and data architectures.
Now back to the CIO and business architecture. Many CIOs have heard of business architecture and may even have people working in this discipline – but this is not enough. In one example, a CIO understood that the business could use business architecture to improve business transparency, problem analysis, issue resolution, planning and funding activities. The CIO provided his business peers with some light reading on the topic of business architecture along with assessment reporting results highlighting the challenges stemming from this lack of transparency. He recommended that the business document its business architecture and begin using it as a basis for issue analysis, planning and a host of follow-on activities. As a result, business leaders commissioned a business architecture team and drafted a cross-functional set of capabilities, value streams and related documentation. This organization is well on its way to breaking logjams in delivering business solutions that have been in place for over a decade.
While other CIOs are following suit, not all CIOs welcome business engagement in business architecture. In a counterexample, another CIO saw business architecture as a threat and froze all work and discussions on the topic. Business architecture allows the business to reestablish its ability to drive strategic transformation and the CIO was not on board with this thinking, for whatever reason. Even the assessment report that highlighted the serious competitive and regional threats facing the business was not enough reason for this CIO to take action. In this example, the business will have to come to its own realization as to the importance of business architecture. Hopefully this will occur before it is too late.
For other organizations, the message is clear. The CIO is a change agent and plays an important role in motivating the business to establish a business architecture to provide the cross-business transparency needed to address a wide variety of cross-functional business challenges. In this way, the business wins and the CIO can get back to solving well defined business challenges based on a significantly more enlightened business perspective.
