This Old Infrastructure: Enterprise Architecture

By Gary Bolles  |  Posted 01-01-2004

This Old Infrastructure: Enterprise Architecture

To download fact sheet, click here.


Think architecting IT is only about technology? Think again.

Enterprise architecture is the most-used and least-understood concept in IT. Disagree? Quick: What does "architecture" mean? Or, for that matter, "enterprise"?

The art of designing buildings began when the first nomadic hunter constructed the first lean-to. But IT architecture is only a few decades old, and to some it may still seem like building mud huts. Too often, people think of IT architecture as simply making sure the company has the right networking equipment. At its best, however, enterprise architecture brings consistent discipline to the process of defining how technology enables business strategy. The trick is to sift through the discipline's various approaches until you find one that best fits your organization.

But that sifting process is no easy matter. Definitions of enterprise architecture vary widely. The Institute of Electrical and Electronic Engineers Inc. defines an architecture as "the structure of the components, their relationships, and the principles and guidelines governing their design and evolution over time." The Information Technology Management Reform Act of 1996, better known as the Clinger-Cohen Act, refers to information technology architecture as "an integrated framework for evolving or maintaining existing information technology and acquiring new information technology to achieve the [organization's] strategic goals and information resources management goals."

And the jargon gets worse. Take this excerpt from a recent analyst group's e-mail message on the topic. "Frameworks are an instantiation of predefined, pre-integrated technologies used as a single unit (though not always sold as a single unit) for a specific purpose and containing a clear definition for standardized developer interfacing." Not exactly written to make your life easier.

At least there's agreement on what it entails, right? Not always. To some, an enterprise architecture is a graphical model that defines in painstaking detail a series of technologies and business components. To others, it's the actual software, such as middleware, that binds together the organization's disparate pieces of technology. To still others, it's more of a mentality than an explicit set of definitions. But that fuzziness allows the word "architecture" to describe just about any halfway-structured approach to organizing technology. Making matters worse, various industries have their own definitions and frameworks, and in many cases those approaches are still works in progress.

Click here for a nine-step whiteboard process on managing enterprise architecture.

At their most basic, though, most definitions of enterprise architecture require the development of three things: A clear picture of what exists today, a vision for what should exist tomorrow, and a road map for getting there. That probably sounds pretty generic, to the point that you may question whether enterprise architecture is any different from your current planning process. What is different is that enterprise architecture creates a blueprint that includes a set of standards toward which the organization gradually migrates, and it encourages process discipline that ensures no new technology is bought or developed unless it's directly linked to a specific business initiative. Enterprise architecture also defines a consistent language for describing the business, the organization's information and the technology used to create, manage and distribute that information. How those blueprints are created and managed, the ways in which the various architectural models are developed, and the processes for making architectural decisions—coordinating a portfolio of IT investments, for example—all of these need to be tailored to your organization.

Why bother? Federal government agencies don't have a choice. In order to receive funding, agency CIOs must create enterprise architecture plans that conform to federal standards and, in compliance with Clinger-Cohen, they have to update those plans regularly. In the corporate world, meanwhile, enterprise architecture can be a critical component of IT alignment, ensuring that changes in organizational goals are regularly reflected in strategic and tactical plans.

Enterprise architecture can also provide the discipline to help IT control costs. By continually funneling decision-making through internal change-management and standards-review processes, it can help to consolidate IT resources, thus enabling IT to scale with ever-increasing demands from the business. "For me, it's a matter of survival," says Tim Getsay, assistant vice chancellor for management information systems at Vanderbilt University. "If we follow the traditional IT patterns, we're not going to be able to keep up."

Tell Your CEO:

  • We need consistent internal processes for linking our technology plans to our business plans—and I need you behind that initiative.

    Ask Your Staff:

  • How can we start using enterprise architecture as the framework for our journey toward IT alignment?

    Ask Your Enterprise Architect:

  • When was the last time we reviewed the methods we use for developing and managing our enterprise architecture?

    Page 2


    For enterprise-architecture initiatives of any scale, involving the business side isn't an option. It's a requirement.

    If you're just starting out in your first disciplined enterprise-architecture exercise, remember that this is a journey, not a destination. Don't initiate a forced march across the entire company. "Enterprise architecture doesn't always imply that you're going to analyze the whole business top-down," says Jan Popkin, CEO of Popkin Software, a developer of software designed to help organize architecture initiatives. Instead, begin with a project that affects a single business unit. This will allow you to construct a flexible framework that's relatively comprehensive for that part of the organization. You'll then have the basic building blocks to roll out in other business units as new initiatives appear.

    Other companies will choose to begin an enterprise architecture with a project that has wide-ranging implications for the organization but that doesn't demand a comprehensive inventory of every single business and technical resource. "In our experience, [enterprise architecture is] most effective where it's driven by a specific initiative that also tends to touch on multiple points," says Nathaniel Palmer, vice president and chief analyst at Delphi Group. Good examples of horizontal initiatives would be the rollout of a content-management system, a customer relationship management application, or perhaps compliance with Sarbanes-Oxley requirements.

    Where do most companies go wrong? By taking on too much. The most difficult part of enterprise architecture is determining just how extensive your initiative should be. "Scoping out your architecture and your efforts is probably where people make the most mistakes," says Rick Thomas, CIO for the U.S. Army Community and Family Support Center, an organization that provides diverse services to 10 million servicemen and women and their families. Richard Buchanan, enterprise-architecture practice director for META Group Inc., agrees. "The key to success," he says, "is not trying to model everything at a granular level of detail."

    "We do it in baby steps," adds David Caddis, vice president of application infrastructure management at Candle Corp., an IT vendor that says it has conducted more than 2,000 enterprise-architecture engagements in the past five years. "When you try to wrap your arms around the whole thing, you go into panic mode because of the scale."

    Ask Your Business Constituents:

  • Can you be an integral part of the process to help ensure its success?

    Ask Your Architect:

  • How are we determining the level of detail that's being built into our architectural plans?

    Tell Your Staff:

  • This isn't a one-time effort. We're in this for the long haul.

    Page 3


    Enterprise architecture is first and foremost a people exercise. Make sure you know the best way to get others involved.

    CIOs, consultants and analysts all agree that enterprise architecture isn't initially about technology at all. It's about putting processes in place that enable people to reach agreement on thorny business and technology issues; and it's about making sure these processes continue to work over time. "Enterprise architecture may seem to be a tool for IT," Thomas says, but, "in reality, it is a tool to be used by IT executives to support the business owners."

    According to Caddis, the CIO has three challenges in putting together an enterprise architecture: "His people, and the technical battles that go on beneath him; the competing interests of various lines of business; and the board, or the CFO, or whoever's funding the infrastructure." All of these are people problems.

    Start with the business units. For an enterprise architecture exercise to succeed, business constituents must be involved from the beginning, because their priorities must drive the underlying initiative. "There needs to be a business sponsor, or at least a business partner, rather than something that's coming solely from the CIO," says Delphi's Palmer.

    Making sure business constituents are clearly defining business priorities and processes, however, may involve more work up front in articulating requirements. It's IT's job to convince them the extra work is worthwhile. Thomas describes one situation in which his group was able to demonstrate that users had requested the wrong custom software for a project. He was then able to substitute an off-the-shelf application that saved over $100,000, thus providing a rapid ROI for his architectural efforts.

    The next hurdle is within IT itself. Software developers can be the greatest enemies of architecture, because technical and departmental bigotry can sink any attempts to encourage the use of standards. But Don Buskard, senior vice president and CTO of AXA Financial Services LLC, a subsidiary of AXA Financial Inc., says his company had the right architectural components in place to bring internal developers into the fold. "You've got to write a lot of code if you don't use the architecture," he says.

    The final people challenge is the funding of architectural efforts. Your CFO might not see an obvious connection between a flexible architecture and saving money. The ultimate weapon: metrics. AXA Financial's Buskard says his company religiously tracked its architecture-related initiatives, and though this required AXA to spend about $35 million over the past 11 years on planning, development, testing, and implementation, the company saved $55 million by avoiding the need to create unnecessary software.

    Ask Your Project Office:

  • In which of our current business initiatives would it make the most sense to involve business constituents in an architectural exercise?

    Ask Your Architect:

  • Do we have the right incentives in place to help discourage "rogue" application development?

    Ask Your CFO:

  • If we can prove what we would save, will we be able to get the initial funding to kick off an architecture exercise?

    Page 4


    Software can help you keep your architectural plans in sync—but not if your design processes aren't already effective.

    Too often, definitions of business goals, business processes, and information and infrastructure architecture are locked up in a myriad of widely dispersed text files, and architectural plans are invariably defined in presentation slides that have been hastily thrown together in the last few minutes before architecture meetings.

    But a growing number of off-the-shelf software packages, often called EA tools, have appeared in recent years to help with the architecture development process. According to analysts, these applications can help make sure the right steps are being followed in developing and maintaining up-to-date information about the enterprise. They can also manage a database, or repository, of components that describe IT resources—things such as servers and applications, which then become the "widgets" that feed the architectural plans. When it's time to provide information to the various stakeholders in the renovation effort, such software can automate the display of architectural models so that different constituents can understand what's in it for them.

    But these applications are no panacea. Without the right deal between business users and IT on the table, such software can simply automate bad decisions, and fool all involved into believing they're on the right track for building great enterprise architecture. Also, these applications may not necessarily reflect the way your company views its enterprise architecture, so you may need to customize it to make it work for you.

    Users say it's most important to use EA tools to build an IT database that includes the architectural components of the organization. This will allow IT the flexibility to redefine how those components are assembled when new business initiatives appear. "A lot of these tools have their place as repositories," says META's Buchanan. And the Army's Thomas, a user of Popkin Software's architecture modeling software, adds, "The architecture is really the database that underlies the tool."

    But while such software has its uses, it can't yet make up for the relative immaturity of enterprise architecture as a discipline. "I think the technology that one uses to implement an architecture is mature," says AXA Financial's Buskard. "I don't think the practice of implementing architectures is mature." Yet he insists the effort is worth it. "You have to have a little bit of organizational and personal stamina to stick with the program," he says. "Once you have it there, the only time you get value out of it is when you continue to use it."

    Ask Your Architects:

  • How can software help us manage our architecture processes better?

    Ask Your Enterprise Architect:

  • Could such an application help to weave together the plans from our various divisions?

    Ask Architecture Software Vendors:

  • How easily can your software be adapted to our unique requirements?

    To download fact sheet, click here.