|
|
|
|
|
The Importance of Enterprise Architecture
|
The common saying "pay me now or pay me later...with interest" is applicable to most organizations. And, in a world in which complex IT systems are the primary enabler or strategic multiplier, it's even more true, as the following case study illustrates.
The Scenario
A 15-year old organization has three core divisions with three unique business processes: real property management and reporting, new facilities construction management, and facilities management. Through the years the divisions have leveraged the growing improvements in information technology (IT) to support their unique missions. At first, IT was a novelty and many people in the company created "neat" pilot IT systems in Visual Basic, MS Access, or Fox Pro. "Solve a business problem and learn a new marketable skill" were their goals.
However, the three divisions did not interact much and never coordinated system development efforts, even though much of the information tracked in their individual systems was relevant to the other businesses. Over time these "home-grown" systems became embedded into the organization. And because the "pilot" systems were never funded or managed in the first place they remained pilot-like in stability and scalability. Because the divisions were achieving their missions, company leaders let them operate in their stovepipes.
In the mid-1990s, the innovators who developed the pilots that had since become institutionalized left the organization to start dot-coms and took the technical and functional knowledge of the systems with them. And, by 1998, the organization had two additional issues to address: the Y2K scare and the Clinger-Cohen Act, which enabled all the COTS vendors to successfully market their wares to the organization.
In an effort to address these issues, and minimize cost and negative impact, company leaders implemented new systems the skimped on the requirements phase, did not reengineer, minimized documentation and training, and included minimal support services from the vendor.
The leadership's expectation was an effective new system after a 16-month project with fiscal year savings of $1 million.
The reality: The only good news is that the company successfully dodged the Y2K bullet (although it turned out to be a blank anyway) and the new CIO is happy to have COTS software to replace the home-grown versions. But there's more bad news than good. Three years and $10 million later, the requirements phase cost three times the original estimate because of lack of process and legacy documentation. Also, the CFO Act requires that the COTS real property inventory system meet 54 new system and functional requirements (detailed audit trails, blended funding support, row level security and system defined roles and responsibilities, etc.). The real property system COTS vendor has gone out of business with the dot-com bust; since the company skimped on the documentation, that went the way of the vendor. Company leaders are left with another stovepiped system with no support, closed architecture, and an inability to meet the mandates of the new CFO Act. In addition, the company has such high turnover in its user population that training users on the three separate environments is becoming cost-prohibitive. Inventive users are creating more systems to work around the existing systems creating data errors and complexity.
What Now?
This case study is by no means an exaggeration; it is, in fact, more the rule than the exception for most organizations. It reflects the current IT maturity level across many organizations in many industries. In attempts to speed up the development process, create competitive advantage, or respond to new legislative mandates, many organizations just forgot about strategic IT planning and governance. Part of strategic IT planning and governance is the enterprise architecture (EA).
What is Enterprise Architecture?
Enterprise architecture (EA) is an organized set of diagrams of an enterprise created to support management and change of that enterprise; it is the way in which the component parts of the enterprise come together.
In essence, the EA is a blueprint of how an organization does business and how IT systems enable the business. There are many frameworks or approaches to creating an EA, but all of them convey, on paper, what the organization does, who does it, how it is done, and when, where, and why it is done. On top of that, it maps all of that information to specific processes in the IT systems. EA marries the business to the systems and allows leaders to view the organization from the 10,000-foot level down to the 10-foot level.
The benefit of doing an EA exercise for an organization is that it forces the creation or the updating of REQUIRED process documentation. The good news is that this documentation can serve many other purposes, such like ISO 9001 compliance, BPR efforts, etc. It also forces the documentation of the IT systems, which serves the above purposes and provides the organization with documentation for future system enhancements or replacement. The ultimate use is documenting the current as-is EA and then creating a to-be architecture that is aligned with the organization's strategic goals. With strong EA, leaders can create roadmaps for getting to the to-be and measure performance toward that end.
The Zachman Framework© (presented below) is a popular EA tool.
Other EA tools include:
Had the organization in the above case study followed an IT strategy with an EA framework it would have:
Mitigated loss of corporate and systems knowledge due to staff turnover Identified problems earlier and projected cost better Executed on projects faster and with less expense; rediscovery and reverse system engineering is labor intensive Forced integration and consolidation, and reduced complexity across divisions Improved usability and user adoption, reducing user training costs Complied easily and with agility with Clinger-Cohen, EO 13011, Sarbanes-Oxley, and HIPPA.
|
Free trial
Subscribe Now
|
