November 8, 2005 By Gene Leganza
John Zachman, the originator -- some call him the father -- of enterprise architecture (EA), said EA programs employ formal processes to consciously design enterprisewide approaches to business, information, application and infrastructure architectures. When implemented correctly, EA programs can significantly improve the business value of IT investments.
EA is the blueprint for designing and implementing information technology solutions to serve current and future business functions. It can enhance coordination, reduce diversity, promote data sharing and boost efficiency in the development of business solutions.
But EA is not just an IT initiative -- Zachman himself is quick to note that EA is a top-down program that, to succeed, must impact strategic business planning processes and enterprise governance.
EA programs are a huge factor in how CIOs get their IT projects approved -- federal agencies claim to implement EA to get their business cases approved by the Office of Management and Budget (OMB).
State CIOs also have EA on their list of issues to tackle, and large local jurisdictions have EA on their radar screen -- if it's not part of their IT strategy already.
While no exact figures exist on who's using EA, it's safe to say that almost all organizations with a significant investment in IT have some form of EA program.
The question is: Are participants in EA programs actually forming their enterprises from the top down? The answer varies according to who's doing it and how. Forrester Research found that:
Innovation Plus Governance Equals Effectiveness
The most effective approach to business architecture (BA) -- a component of EA -- marries iron-clad repeatable processes with the innovation possible when business and technology subject matter experts work together to solve problems. Formal planning processes ensure that the best business and IT minds available apply their knowledge to solving business problems. Governance processes make certain that only high-value projects obtain resources. Performance management processes consistently measure business value. Combinations of two critical dimensions -- the degree of IT/business interaction in planning, and the degree of formal process implementation -- define four states that characterize organizations on the journey to optimized BAs:
Engaged. When a BA is in the engaged state, great care is taken to link IT planning to business planning, but the organization uses a waterfall model. This means IT is simply the recipient -- and sometimes the custodian -- of business plans and decisions that flow through a series of phases with major IT implications.
Process-oriented. When a BA is in the process-oriented state, executive support and implementation of best practices in project selection and portfolio management put muscle into governance processes. IT strategic planning is closely aligned with business planning, but still uses the waterfall model. Systemic performance metrics show that the effect of tight linkage to business planning and tight governance processes is consistent: CIOs will gain business value from IT projects.
Innovative. When BAs are in the innovative state, collaborative business IT shows flashes of brilliance. Confidence in IT's capabilities in some business areas sets the stage for savvy CIOs who communicate in business terms with their agency partners to collaboratively develop breakthrough solutions with high business value. A low degree of comprehensive process orientation, however, makes such successes the exception rather than the rule.
Optimized. When BAs are in the optimized state -- which is the ultimate goal -- the best characteristics of the innovative and process-oriented states combine to guarantee a high-performance culture and continuous improvement. Well established processes ensure consistent collaborative planning, tight governance and performance management.
What makes EA interesting is that both the public and private sectors approach it similarly, especially when addressing technology strategies. They differ, however, when dealing with business strategy. Public-sector EA programs initially beat private-sector programs to addressing BA as a formal initiative by taking a top-down approach that begins with cataloging business processes. Typically private-sector EA programs start with a bottom-up, technology-centric approach.
The best way to understand how implementing EA can affect an organization is not through theoretical discussions, but by example. Forrester looked at dozens of large organizations with annual revenue or budgets of $1 billion or more, and found four exemplary cases where the organization's EA program successfully linked IT investments to create value. Though two are from the private sector, public-sector CIOs can learn how to maximize investments in their own architecture initiatives by observing how these organizations have integrated business and IT planning.
Case #1 -- Alberta, Canada
Well Structured, but Governance Struggles
The government of Alberta, Canada spends more than $340 million per year on IT and employs more than 26,000 staff in 24 ministries. The Government of Alberta Foundation Project was launched in September 2001, to establish EA as part of Premier Ralph Klein's call for increased cross-government initiatives.
Key aspects of the Government of Alberta Enterprise Architecture (GAEA) include a comprehensive, top-down approach; performance metrics designed up front; and priorities established for common services.
By December 2002, the Alberta Foundation Project built a team of more than 130 staff, including a core team with experts from IBM Global Services, governance committees, subject matter experts and extended business contacts. They defined business, application, data, technology and security architectures; implemented a custom-built central repository; created a governance model; conducted a gap assessment; and created a plan for the transition to future state architectures.
From the outset, the team defined a capability maturity model and a balanced scorecard to track progress.
In addition, the architecture team's analysis of each ministry's business processes identified 106 common business areas; 73 shareable areas in the data architecture; 69 application components; and 101 technology services as targets for development, standardization and sharing.
The foundation project laid the groundwork for rationalization of business processes and IT resources across governmental silos. The architecture provides a vehicle for continued work to streamline services and reuse assets.
Alberta's program has three chief notable characteristics.
First, it has a formal, highly visible foundation for change. The GAEA is a classic example of a Zachman-influenced EA program that is very large in scope. The foundation project was managed like a well oiled machine, with detailed planning and metrics.
Second, its governance model lacks teeth. According to John Chandler, Alberta's chief enterprise architect, governance of alignment with the architecture is "more mandate than authority." The core architecture team must work to overcome the "what's in it for me?" attitude of skeptical project sponsors.
Third, it has success stories, one project at a time. In a recent project, architects persuaded reluctant business participants to take a GAEA-driven approach. The design project was completed on time, on budget, with more functionality than originally planned and with more than 30 percent of the target data designs reused from the GAEA data architecture. The business partners now help strengthen the value of GAEA processes.
Alberta is in an advanced engaged stage in the BA effectiveness framework. The province displays a strong process orientation, governance being the exception. Further improvement along the process continuum depends on senior management's willingness to give the GAEA-defined governance model more teeth.
Case #2 -- Entertainment UK
Entertainment UK (EUK) is a modest private-sector concern with the equivalent of about $2 billion in annual revenue. Its 90-person IT unit includes 15 business analysts. The EUK architectural approach is the brainchild of Greg Smith, the head of IT development. Smith began defining architect roles three years ago, and recently raised the skill level of the analyst community, pulling analysts from the business side and defining a process model across the business.
Key aspects of the EUK BA program include a business IT relationship based on credibility, a communication model that masks complexity and jargon, and a six-week workshop to map business processes.
After a false start, Smith waged a careful campaign to address known business problems and demonstrate the business value of IT. This gave him the credibility he needed to proceed with his comprehensive process model initiative.
Smith takes great pains to communicate in business terms and avoid abstractions. "The MD [managing director] doesn't think he's sponsoring EA, he's just aligning business strategy with IT work ... even calling things 'process models' and 'process domains' doesn't work. Calling it a business model, capability, opportunity -- that works."
The credibility Smith gained for IT has enabled him to engage business executives in a previously unthinkable activity -- senior business staff, business analysts, Smith and a facilitator will participate in a six-week intensive workshop to develop the process model Smith needs to plan a transformation of IT and EUK's capabilities.
EUK's business is highly competitive and volatile, and it's positioned between large suppliers and large retail chains. The key to survival and success is to convince firms upstream and downstream that it's easier to go through EUK than around it. That means flexibility.
The EUK architecture program has three chief notable characteristics.
First, it has an ideal level of business and IT interaction. The business trusts IT because of its past performance and because IT talks in business terms. The culture is one of business subject matter experts working with IT experts to solve business problems.
Second, it's dependent on personalities, not lasting structures. As with any small shop, relationships are fundamental. It is doubtful that, in Smith's absence, another IT manager would command the same respect and cooperation.
Third, it's building a process model in an environment hostile to abstraction. Smith's ability to gain business leadership's participation in a formal process model workshop is remarkable -- it shows the power of credibility and trust based on the delivery and communication of business value.
EUK's approach to business architecture is highly collaborative, with business and IT subject matter experts contributing their unique perspectives in a forum conducive to finding the right answer to business pain. As Smith stated, anyone can find a solution to pain, but finding the right answer requires the circumspection only available from the architecture perspective. Smith's move toward formal modeling will lay the groundwork needed for envisioning the future state in detail, and for using that vision to plan and justify investments.
EUK is a solid innovative organization in the BA effectiveness framework because of the firm's collaborative planning process that regularly produces business value. EUK will progress along the process continuum toward optimization by completing the process modeling workshops.
Case #3 -- NOVA Chemicals
Linking Strategic and Operational Planning
NOVA Chemicals is a commodity chemicals manufacturer with operating centers in four countries, and manufacturing sites and research centers in North America and Europe. It is a $5 billion company with a 275-person IT shop. The company has an eight-person central EA team consisting of three technology consultants and five architects, each specializing in one of five areas: business, application, data, infrastructure and security. Director of Enterprise Architecture Bill Blinn, who leads this group, reports to the VPs of application and infrastructure to ensure cooperation and participation. Blinn feels strongly that a strategic, top-down approach to architecture must be pursued simultaneously with a bottom-up approach to architecting IT services.
Key aspects of NOVA's BA program are its synergy between the CEO and the head of EA, its three-tiered approach to architecture and planning management, and a project management methodology that mandates process analysis.
Two years ago, Blinn saw the value of introducing EA in response to difficulty keeping technology current and aligned with business drivers, and he began evaluating approaches with the CIO. Meanwhile, President and CEO Jeffrey Lipton realized the key to beating much bigger companies was a business process innovation culture, and he began pursuing formal approaches to innovation. NOVA has developed and refined its processes over the past two years, and now has architects embedded in key business planning processes -- in IT and in the business.
An annual planning workshop creates one-, three- and five-year visions, feeding the one-year vision into the portfolio management process. Out of the portfolio management process flow projects managed by solution sustainment processes, and Blinn's architects participate at all levels.
NOVA's project management methodology mandates a review of the affected people, processes and tools. "We baked into our project methodology -- not just for IT but in business projects too -- an engineering approach that begins with clearly defining the current state," Blinn said. "We document the workflow using value chain diagrams and value maturity assessments of key processes.
"The business architect will work through the business flow and planning processes, helping the business team at the workflow level," he continued. "That's when we start looking at ways to apply technology to solve problems. We have metrics to monitor the health of projects, and to see that we got the desired value out of the new processes."
As a commodity chemicals manufacturer, windows of opportunity and margins are tight. NOVA must respond quickly to market conditions and manage rapid change. Project business cases focus on the value of process improvements.
NOVA's architecture program has three chief notable characteristics.
First, NOVA has a classic EA charter and scope, but EA is integral to business planning. The EA team members handle all technology strategy coordination of a typical EA group, and actively participate at all formal business planning levels. Each architect from the EA group has a seat at an annual planning workshop, monthly portfolio management meetings and ongoing solution sustainment activities.
Second, the business owns processes and architects facilitate change. "The business architect is only in the position of facilitating the process: identifying the opportunities and determining how to categorize them, put them into a portfolio, prioritize them, and fit them into the strategy-planning cycle," Blinn said. "The reason we haven't encountered difficulty is that we're not taking over."
Third, NOVA has relationship managers in pivotal roles. The firm uses, in all planning and management activities, internal IT/business coordinators who are full voting members of governance activities, such as portfolio management.
NOVA is in the optimized state of the BA effectiveness framework because the firm has formally structured collaborative planning processes, tightly linked planning and governance processes, integrated BA and EA processes, and a solid metrics program to track success. Since NOVA's architecture program became integral to executive management's comprehensive agenda to implement a business process innovation culture, business and IT management implemented processes rapidly.
Case #4 -- U.S. Environmental Protection Agency
The Business of Managing Information
The U.S. Environmental Protection Agency (EPA) has more than 18,000 employees and spends $400 million on IT per year. Its EA team is a group of six to eight architects in the Office of the CIO. This office, labeled the Office of Environmental Information, is led by Chief Enterprise Architect John Sullivan. He coordinates architecture issues across the EPA with business unit members of an architecture working group. The members, according to Sullivan, "get the right person to the right committee at the right time."
Key elements of the EPA enterprise architecture program's BA include an early start on formally modeling the EPA's business, a comprehensive top-down analysis and a good fit with the Federal EA (FEA) -- a holistic governance process that includes the business units, and a repository linking investments to EA components.
Three drivers helped form the EPA's initial architecture effort: a change in their business model as states took over the operational aspects of environmental protection; a change in focus from simple things like smokestack emissions to tracking complex ecosystem management issues; and the continuing evolution of technology. With its operational processes gone, the EPA's business became that of managing environmental information and exchanging it with partners. "We looked around and liked what Intel was doing with RosettaNet, and we developed schemas for sharing information," Sullivan said.
The shift in the EPA's business model forced a close examination of its business processes, including value chains and service components. "We were doing these things when the architecture thing happened in the mid-'90s," said Sullivan. The OMB's FEA reference models mirrored the EPA's approach to analyzing the agency's business. "The whole OMB model really validated what we were doing -- it became an external structure that we could use internally," Sullivan said. "It resolved some terminology issues."
The EPA's EA governance model is inclusive, keeping business units in the loop and ensuring that program goals drive all IT decisions. The EPA's goal is for all IT projects to have a solution architecture, be compliant with EPA and FEA reference models, be designed for reuse across the FEA and the federal government, and to not duplicate an EPA or federal government service component.
To store the IT investment portfolio and link investments -- such as pending Exhibit 300s -- to current and target state architectures and reference model elements, the EPA uses Metis, a software product from Troux Technologies. This linkage enables a line-of-sight analysis from IT investments to program goals.
Sullivan and his architects responded to the EPA's evolving business model by embarking on a detailed analysis of its business processes, data model and application portfolio -- before EA was a buzzword inside the Beltway. When the OMB began recommending that agencies develop a line of sight to connect investments to program goals and performance metrics, the EPA revised its budget structure and human resource planning process, and linked IT investment planning to the agency's strategic plan.
The EPA's architecture program has five chief notable characteristics.
First, it provides a clear model of the agency's business. The EPA's EA program had a jump-start on providing a formal view of the agency's business at a detailed level, and its models enable visual analysis of internal dependencies.
Second, it is perfectly in sync with the FEA for cross-agency coordination. The EPA has carefully changed its Capital Planning and Investment Control (CPIC) processes to map to the business architecture as represented in the EPA's EA and the FEA. The EPA states, in its 2003 EA Status Report, "We fast-tracked the mapping of the new FEA models with EPA's own models to serve the needs of this year's CPIC submissions -- and those of the architecture. Within two weeks of the latest FEA releases, we provided CPIC proposal preparers with draft alignments between their own individual proposals and both the EPA and the federal reference models ... the process was so successful that we are sharing our CPIC/EA alignment tools with other agencies."
Third, it has already contributed strongly to achieving program goals. The EPA's business model became one of moving information across horizontal business entities -- state EPA offices. "We put up a science channel, a lot of scientific research, and channeled it to our partners -- we're the portal to access everything in the environmental protection space," Sullivan said. "To pull that together, the Office of Research and Development really used the architecture to have that dialog." The EPA's Environmental Information Exchange Network provides a standards-based collaborative exchange of information across state EPA departments.
Fourth, the EPA has a solid commitment to a shared component model -- with governance. "We're moving to a component-based architecture -- we'll have enterprise services for data collection, business intelligence and data warehouse," said Sullivan, who is spearheading continuing work on the EPA's governance model to ensure that the target architecture uses shared components whenever possible.
And last, collaborative strategic planning is still in the EPA's future. While the EPA has been very successful in linking architecture planning to the strategic plan, Sullivan said, its basic business planning process has not changed. "It's a five-year planning process -- we're working on making it happen more dynamically."
The EPA is well into the process-oriented quadrant in the BA effectiveness framework because the agency has tightly linked governance processes to both BA development and IT investment processes. The EPA's EA implementation is conceptually perfectly aligned with the FEA, and it sets the stage for comprehensive integration of planning and execution processes through EA governance mechanisms.
You may use or reference this story with attribution and a link to