Sixty percent of Global 2000 organisations have yet to discover the power of enterprise architecture (EA). Taking time to discern the "system of systems" view of an organisation as well as the fit of IT within holistic solutions and business processes is daunting. Concerns ranging from "It ain't broke, so don't fix it" to "That's just not the way we do business here" to "We're still focused on meeting service-level agreements" weaken support for EA.
Recognising IT misalignment and misallocation of IT investments during economic downturns or periods of intense industry competition, such IT organisations (ITOs) wish they had addressed future-state needs and a holistic perspective beforehand. Irate business leaders, all too late, demand an answer to where the ITO’s leadership went awry. However, forecasting negative outcomes does not assuage IT leaders' view of EA as a wasteful use of resources during the "good times" (eg, the times when business leaders are not asking the difficult questions concerning the proper allocation of IT investments to meet year-over-year goals).
Examples: US federal government and private-sector companies leading the way
Whether in "good times" or "bad times", EA is not a matter of survival for the US government. It is, in the words of John Zachman (considered by many the "father" of EA), “...recognition that the design of the system is the design of the enterprise; and if the system can't change, the enterprise can't change!"
Development and instantiation of enterprise architecture is evolutionary, not revolutionary. In 1998, the US Air Force engaged in the Combat Information Transport System (CITS) to deliver a common network infrastructure, management and protection platforms across 108 air bases around the world. Conflict arose when bases and squadrons in command of their own funds decided to "do things their way" at odds with the common direction that CITS provided. Political wrangling and finger-pointing rose through the ranks until the senior management at the Pentagon shared the mandate "resistance is futile". Compliance with change requires governance escalation paths that end with the senior-most levels of the organisation seeking to enact the change. If the CIO cannot gain support from business counterparts, EA dies a quick death or is persistently thwarted by lines of business and individuals not committed to change.
The 1996 Clinger-Cohen Act demanded a systematic process and ensuing output to consistent IT investments for the US government. The result is that EA is now a critical input to both investment decision-making and the IT staff and outsourced organisations that deliver IT solutions and technologies to US government processes. Government entities - typically lambasted for being bureaucratic, intransigent and resistant to change - have turned out to be leading examples of the usage and power of EA. However, this change has neither been easy nor without challenges. Process definition and inclusion in critical processes, such as IT investment decision-making and capital planning, have been part of a cultural shift beyond the population of a framework to one of a process of discovery and application.
Public corporate entities have not missed the need for EA, either. However, such entities are naturally reticent to expose their challenges or successes in the development and instantiation of EA within their organisation. EA defines the critical linkage and road map for IT to support the differentiators of their public businesses within the context of industrial competition. Resulting artefacts are not typically shared publicly with others due to the belief that such exposure will give insight to strategic direction and dilute the value proposition of the EA guidance.
Unfortunately, such reticence serves to reinforce non-believers in the low value proposition of EA to their situation. Few forums exist for public exchange of such private examples other than the Digital Consulting Institute's Enterprise Architectures Conference. Non-believers would do well to seek the private-sector companies that have shared their successes and failures in this forum. Examples of attendees in 2003 include Lockheed Martin, DuPont, Bank of America, Fidelity, Dow Chemical, Motorola, WW Grainger, Procter & Gamble, Cigna, Toyota Motor Sales USA and New York Life Insurance. Such company is good to keep in seeking the path for organisations lacking EA.
Fear factor: The cultural change hurdle
The hurdle for organisations seeking to engage in EA is contentment with the status quo. Sponsorship and commitment to EA begins with, at minimum, the CIO. Complacent cultures with few performance standards and the absence of visible crises, in the perception of those who lead the organisation, are the death knell to any change in IT practices.
It is easy to state that one must discover which pain points (eg, project failures, bad investment leverage, increased business competition) the business is feeling and illustrate the relationship between these leadership disciplines and a successful outcome to solve such pains. The reality is much different. In fact, not all journeys are alike, and each organisation's path varies based on politics, culture and pain points. The common approaches of discovering allies, influencing stakeholders, and leading a committed effort all apply, as they would in any change effort.
An honest appraisal and assessment of the current-state situation, an analysis of the critical constraints inhibiting success, and a succinct and pragmatic set of next steps are needed to introduce these disciplines within an ITO. CIOs considering embarking on these leadership disciplines must take stock of their current situation, determine the scope of their next steps, and perform stakeholder analysis to determine the degree to which they can frame these efforts in the context of their own organisation.
Business impact: Enterprise architecture defines future-state guidance for leveraging year-over-year investments in information technology.
Bottom line: Real-world enterprise architecture success stories abound. Enterprise architecture development must be based on organisational needs - not because "everyone else is doing it".
Analysis by META Group analyst Philip Allega.
Publisher: Meta Group
Source: Meta Group Insights - IT Web

