Part 2 of this series shows how to scope the project, set up the development team, and form a target architecture vision. Frank J. Armour, Stephen H. Kaisler, and Simon Y. Liu
ARCHITECTUREARCHITECTURE
Building an Enterprise Architecture Step by Step
I
n our last article, “A Big Picture Look at Enterprise Architectures” (IT Pro Jan/Feb. 1999, pp. 35-42), we made a case for establishing an architecting roadmap and urged organizations to look at building an enterprise architecture from a very high level perspective. None of this is natural or easy. In fact, once you’ve had a high-level look, the tendency is to close your eyes and climb back down the ladder.The scenery can overwhelm you. When architects are at high levels, they see more things—and everything they see they model. This big bang approach to information engineering is one of the main reasons many efforts fail. If everything is important enough to model at once, where do you begin? What’s really the priority? In fact, for most organizations, getting started may be the hardest part of building an enterprise information technology architecture (EITA). One reason is that people have only a hazy idea of how to use a systematic architecting process to achieve Why Use a Systematic specific goals. The entire idea Process? of enterprise architecting How Different Stakeholders seems grand and out of reach, View the Architecture so they feel more comfortable chipping away at it with What Do We Mean by patches. Unfortunately, these ‘Enterprise IT patches evolve to something Architecture’? only slightly more sophistiResources cated. Some efforts never get that far. The architects get
Inside
1520-9202/99/$10.00 © 1999 IEEE
caught in a never-ending series of analyses— “analysis paralysis”—and end up with nothing but a long to-do list just as the money runs out and the CEO expects to start seeing a return on investment. Analysis paralysis is caused partly by not knowing how to scope the architecting effort. Once you understand what you want, the process itself is straightforward. In this article, we take you from the start of a project to designing the target architecture. In the next article, we describe how to plan the transition, implement and refine the new systems, and set up an effective maintenance and evolution strategy.
SYSTEM OF SYSTEMS DEVELOPMENT People often ask us, “How does building an enterprise architecture differ from building an individual information system?” Perhaps the best way to explain the difference is that that the enterprise architecture is the big picture—how major information systems across the entire organization work together. In that view, an enterprise architecture is a system of systems. Each system has its own environment of people, subsystems, and data—plus it must work with other systems to support business operations. This means that in addition to traditional software development concerns, EITA builders must define the scope and boundaries of each individual system, including its major application areas and user groups. Architects must determine what is needed for the systems to interoperate smoothly, define inforJuly ❘ August 1999 IT Pro
49
ARCHITECTURE
Figure 1. Steps in enterprise architecture development.
1
2
Initiate the process
• Scope the project
Characterize the baseline architecture
Infrastructure view
Function view
Information view
Work view
• Build the team • Establish a target vision
m
ul Be tip g le in lo op s
Validate views with user survey
5
Plan architecture implementation
3
Develop (update) target architecture
Define target business view
Define target architecture view
Develop individual systems
Development process planning and administration (review boards, conflict resolution, training, and so on)
4
Infrastructure view
Function view
Information view
Work view
Plan architecture transistion
mation exchange protocols, and specify any global constraints (the desired global level of performance or security, for example) on the information system architecture. This sounds like more than any one development process can handle.And in a sense, that’s true.The process must be flexible on many levels—flexible enough to accommodate a range of architectures and function areas. It must also be robust enough to handle as many iterations as needed to refine activities. The development process we created for the US Department of the Treasury (see Figure 1), since customized for the US Senate and the US Census Bureau, 50
IT Pro July ❘ August 1999
Building an enterprise architecture starts with the particular architectural framework—either an existing framework or some customization of a framework you’ve created. The first step is to get organized, which consists of scoping the project, setting up the development team, and defining a target vision. The dashed arrows represent hazy initial relationships. You won’t know much about how to implement the target architecture until you have completed at least one iteration of steps 2 through 5. What you decide about implementation will affect how individual systems within the architecture are developed, and certain technology constraints on individual systems may affect architecture implementation planning. This is iteration at a high level. But iteration also occurs within steps. Steps 2 through 5 each have their own loops. (The loops in steps 4 and 5 are not shown because we will cover them in the next article.) Within step 2, for example, you may go back and forth between two views or loop through all the views more than once. Through all the steps, you’ll be planning and refining the development process, using mechanisms like architecture steering committees. You can develop high-level views relatively quickly to provide insight for key decision-makers, who can then focus development on the areas with the greatest need.
initially handled 10 to 20 systems. But it is equally suitable for smaller, more focused efforts such as integrating a supply chain or larger efforts such as integrating 30 to 40 systems over five years. Loops within each main activity provide flexibility on multiple levels. For example, within the Characterize the Baseline Architecture step, you may move back and forth between architectural views or traverse through all the views more than once.
STEP 1: GET ORGANIZED An EITA must accommodate both legacy and new systems. Just thinking about how to box and label all the
required functions can be painful. Many organizations get mired at this stage. To avoid becoming overwhelmed, quickly decide what you want and how much time you have to do it. Then select people who can do just those tasks in the time allotted. Establish a formal target vision. Remember, the EITA demands continual refinement, so plan to police the architecture once it’s established.
Scope the project
jobs is to help determine how the enterprise views its information technology. Establishing this vision is key because the rest of the team must communicate it to everyone else in the enterprise. In addition to system architects, the team should include experts in the functional areas that will be affected by the architecture. These domain experts bring specialized knowledge to the team.With a mature application domain or for small projects, you might need only one or two experts. If you’re restructuring the human resources management system of a large distributed company, you need at least four to six. For a project with 50 to 100 systems, we’ve seen a nine-month effort involve 50 to 100 people. Functional experts will be on the project part-time.
Always start with the doable and the critical.Aim to get a target architecture definition in three to six months.You can get a good idea of what parts of the architecture to concentrate on from the results of business process reengineering (BPR) and from strategic IT plans. Look for processes that are not working well or that must be upgraded to meet a critical business need. If a retail dis- Establish a formal target vision count store must upgrade its supply chain or develop an A target vision puts everyone on the same page and Internet-based procurement solution in six months, its focus becomes obvious. In this case, time to market is driving the architecture definition, and this project does not need to tie up the company’s rearchitecting specialists. Many regard building an enterprise architecture as a five-year On the other hand, if you are describing a new project, which is why commercial organizations often avoid a EITA to support the long-term growth of your systematic approach—and why frameworks and development business in new geographic markets, obviously processes are received with more than a little skepticism. A you should spend more time on architecture company may want an integrated supply chain in six months. planning. The architects look at the enterprise architecture framework Of course, these descriptions are a little simand development process and say, “Forget it. We don’t have time plistic. There really is no one-size-fits-all for this.” approach to scoping an EITA project.The target The truth is that, once you understand some basic activities, architectures differ too widely, as do the funca development process can be as long or short as tional capabilities that must be you want. Don’t avoid it simply because it has modeled. It helps to remember steps. The existence of steps should be comfortthat every EITA effort has two ing, not intimidating. dimensions—depth and breadth. Chances are that you’ve already built someIf you must span a large organizathing according to a process; you just can’t define tion, you aren’t going to have time it. You performed some set of activities, and you to go terribly deep in specifying got some outcome. You might have made it up as your architecture. But if you only you went along, but so what? It worked, and it need to revamp your e-mail and worked quickly. That’s the nature of undefined intranet, you can go into much processes; they’re great short-term fixes. But in a more detail. few years, this ad hoc fix is going to cost your organization more Architecting is defining what to do, not how to than the time it would have taken you to use a defined process. do it.The how details are more of a concern when Software developers eventually learn the folly of comproyou design the individual systems that will meet mising the development process after they build one too many the target vision. “perfect” systems that no one will use. And we’ve seen enough
Why Use a Systematic Process?
Build a team The core members of the development team—we recommend four to six minimum— should work on this project and nothing else. The leader is the chief system architect. Look for a proven leader who can overcome unforeseen problems and provide strong, focused guidance. One of the chief architect’s most important
false starts in enterprise architecting to realize that the same rules apply to information systems: No one can build a successful enterprise information technology architecture (EITA) without a defined development process. There is little chance of getting consistent results or being able to monitor progress. And forget about improving the process itself, because, well, how do you improve something you can’t see?
July ❘ August 1999 IT Pro
51
ARCHITECTURE
How Different Stakeholders View the Architecture Stakeholders
How Their Views Affect the Development Process
Customers
Customers pay for the effort. Their views help determine the scope of the architecture, serve as a basis for acceptance criteria, and aid in estimating schedule and budget as well as feasibility and risk. Customers are also interested in how the architecture will support the enterprise’s growth.
Users
Users will use the systems developed from the architecture. They are interested in how the architecture meets their needs. They help in validating its performance, reliability, and interoperability.
System architects
Architects create the architectural definition. They need to be able to trace requirements to individual system development. They need information about the architecture to support the trade-off analyses required to select technology. Architects help assess the architecture’s correctness, completeness, consistency, and coherency.
System developers
Developers build the individual systems according to the architectural definition the architects provide. They need a foundation with sufficient detail for system design. They use the architecture as a reference for selecting and assembling components and for assessing and maintaining interoperability with existing systems.
System maintainers
Maintainers evolve the architecture. They use it to guide system and software modification and to assess and maintain interoperability with existing systems.
Customers, users, architects, developers, and maintainers influence the development team because each sees the architecture differently. These views also span levels of detail. Customers want to view functions at a high level, so the architecture must be understandable at that level. Users need only enough detail to see that the system will work as intended. System designers need enough information to map the architecture to a system design and implementation. Accommodating all these views often means representing the architecture in multiple ways— high-level focused models for the customer and user; and more detailed and elaborate descriptions for the system architects, developers, and maintainers.
makes it easier to keep the project on track.Although most teams fully intend to develop a shared vision, they frequently fail to do so—most often because they did not involve key players. One way to establish a shared vision is through an Architecture Steering Committee (ASC).The ASC is composed of upper-tier managers from the functional areas and the domain experts.Typically, each organizational area the 52
IT Pro July ❘ August 1999
architecture crosses should have an ASC representative. We will address this issue in more detail in a future article. To form a vision, begin by asking six simple questions: • Who are the stakeholders? List them by title and function. Briefly describe how they will use the architecture. • What problems are to be targeted or solved at the enterprise level? Briefly describe the problems’ business areas and how the solutions will affect the bottom line. Do you
•
•
• •
need to create business processes? Fix broken ones? Have IT advances (Web-based customer service, for example) affected existing business processes? What priority does each problem have? The ASC should prioritize problems and commit the necessary resources. Priorities are driven by business objectives, cost, and personnel issues, such as retraining. What documentation and publishing standards do you plan to use? This can be a simple list of source documents that will dictate the common language (terminology, packaging, and so on) the team will use to communicate important concepts. What tools will you use? Once you identify them, order them right away. Where will the team work? Be sure to specify any needed training or mentoring.
Things to watch for
ect failure is overscoping so that analysis drags on for years. Adjust the breadth or depth of your architectural effort so you can produce concrete results in six months. Devaluing the project. This seems obvious, but we’ve seen projects fail because key people were put on them part-time. Good people will always be in demand, but defining an EITA is a full-time effort.
STEP 2: DESCRIBE WHERE YOU ARE NOW In this step, you describe the baseline architecture—the information systems the enterprise uses now. Many teams try to skip this step. Don’t even think about it. You can’t implement a new architecture without knowing where you are now. People have told us,“We don’t really have an enterprise architecture.”This is a misconception. If you use information systems, you have an enterprise architecture.You just haven’t taken the time to formally recognize it as such. Also, keep in mind that “enterprise” may not mean the entire organization (see “What Do We Mean by ‘Enterprise IT Architecture?’”). As you create a baseline description, you are in essence creating an inventory of information systems and their components and evaluating their relationships. You can use it to identify hidden assets, gaps, and redundancies; manage business costs; determine who is using what and why; and classify the business assets related to IT.
Making informed decisions about key issues while you’re getting organized helps to ensure your project’s success. Nonexperts developing the architecture. Bad architectural decisions have a far greater impact when they are made in the context of an enterprise architecture than in the context of a single system. In the end, it will cost less to get knowledgeable people who understand how to build an architecture that will fit the mission. Good consultants can help you execute the architecture development process, as well as offer expert advice, facilitate meetings, and train the team. They also give the project credibility, particularly if this is a first-time effort. Failure to establish good communication mechanisms. Begin the project with an agreed-on methodology and standards. People tend to forget We have seen the phrase “enterprise IT architecture” used “small” details like this in their hurry to get to the in many contexts. It can be the architecture of the entire organproblem-solving. Midway through the project, ization, encompassing all its systems. But it can also be the archithey wonder why no one seems to be communitecture of a specific process or slice through that organization cating. Be open. Don’t hide the (for example, a supply chain process or a comarchitecture team away or stamp pany-wide intranet). In both cases, the term everything confidential. Invite “enterprise IT architecture” is valid, since the participation and circulate drafts architecture crosses multiple systems, multifor review and discussion. ple departments, and functional groupings Lack of senior management with the organization. commitment. We’ve seen efThe confusion comes from the evolving forts succeed or fail on the basis nature of the term “enterprise.” An enterprise of this one issue. Architecture now frequently includes the suppliers and cusbuilding often crosses organitomers, as well as their IT assets. A good defizational boundaries. The team nition of “enterprise” is any entity that has a must be able to capture the bottom line and a set of goals to meet it. In that information they need. In a sense, an enterprise can be an agency, a division, a marketing large, distributed enterprise, this is a tall order. department, or a chain of geographically distant organizations. Your team will need cooperation on many levThus, if the goal is to integrate a supply chain, the enterprise is els, which means they need a strong champion. all the elements of that chain and what they require to be part If the enterprise’s senior management doesn’t of an integrated chain. support the effort, don’t start it. Overscoping. One of the chief causes of proj-
What Do We Mean by ‘Enterprise IT Architecture’?
July ❘ August 1999 IT Pro
53
ARCHITECTURE
Resources These books are particularly helpful during the initial development steps. For more general resources, see our first article, “A Big Picture Look at Enterprise Architectures,” IT Pro Jan./Feb. 1999, pp. 35-42. ➤ Building Enterprise Information Architectures: Reengineering Information Systems, M. Cook, Prentice Hall, Upper Saddle River, N.J., 1996: Describes, among other things, a process for applying the Zachman framework. ➤ Constructing Blueprints of Enterprise IT Architectures, B. Boar, John Wiley & Sons, New York, 1999: Provides guidance on notations and presents detailed templates for capturing IT architecture descriptions. ➤ Global Software Teams: Collaborating Across Borders and Time Zones, E. Carmel, Prentice Hall, Upper Saddle River, N.J., 1999: Guide to managing and organizing teams across the wide geographic areas. Two articles on the Zachman framework are also good references: ➤ “A Framework for Information Systems Architecture,” J. Zachman, IBM Systems J., Vol. 26, No. 3, 1987, pp. 276-292: Seminal article describing and defining the need for EITA frameworks. ➤ “Enterprise Architecture: The Issue of the Century,” J. Zachman, Zachman Int’l, 1996, http://www.zifa.com/zifajz01.htm: Updated description of why frameworks are important and their status.
The best approach is to organize information according to architectural views, such as the ones we described in our last article: work, function, information, and infrastructure. (The business view covered in the last article should be reflected in these four views.) This need not take a lot of time. We recommend that you try to arrive at an initial description in less than a month for smaller projects and in one to two months for larger ones. Plan to refine the description throughout the project as you begin to get a clearer idea of your target. During this step, you will be estimating the difficulty of getting to the target vision.The results will help you gauge progress as you transition from the existing environment to the target architecture. Remember that successive iterations are easier because the information in the baseline architecture will feed into the new target architecture. 54
IT Pro July ❘ August 1999
Characterize the work view Begin by characterizing the enterprise in terms of the products and services it offers (or produces) and receives. By “characterizing,” we mean describing as succinctly as possible the current state of automated support for the enterprise’s business operations. You need only enough detail to determine what information systems and data you have so that you can plan what you need. You should be able to do this in five short steps: • Identify the relevant products and services produced or offered within the scope of the business processes you have defined. • Identify the customers (clients, stakeholders) who receive the products and services (customer service reps, the external customers, and so on). • Identify providers and their products and services that are critical to the business. • Relate customers and providers to major organization units through their products and services. • Identify business functions and key processes by noting their mission and objectives and relating them to major organizational units. Possible sources of information are documented business processes, department mission statements, organization charts, strategic plans, and individual system documents.
Characterize the function view Next, analyze current IT applications that support the business functions. Also, document the data and information entities the applications use. Describe applications at a high level, showing logical dependencies and relationships among functional areas. Include each application’s scope and interface and identify specific work groups and application users, their relationships to information, and their placement or possible distribution across types of locations and technology platforms. The result should be a high-level description—not a specification—that you can correlate to the development process. If the team members are not functional modeling experts, train or retrain them in functional modeling methods, such as structured analysis or use-case modeling.
Characterize the information view The information view describes relationships among the information the enterprise uses. It includes all information forms and notes how their placement and distribution support users and IT applications.The team is essentially capturing the corporate data model and data dictionary, which requires some sophistication in data or object modeling methods, such as entity relationship (ER) or Object Modeling Technology (OMT). Again, take the time to train or retrain the team.
Characterize the infrastructure view
ate the target architecture, you will return to capture addiCapture the information in this view by surveying the tional baseline information you did not know you needed. For now,ask these questions:Does the baseline specify the information systems in use.The components—hardware, software, and telecommunications—will provide enough set of functions the enterprise needs to meet its objectives? insight to identify the formal data stores and computer Does it allow for the planning and execution of the inforsystems available to the organization. Include current mation systems development strategy? Are processes application support and the potential for process defined from an enterprise perspective? You can be 80 perautomation.Assess current systems’ strengths and weak- cent accurate and still establish the baseline’s basic structure. nesses and identify the networking infrastructure and topology. STEP 3: DEVELOP THE TARFor each information The depth and breadth of the surGET ARCHITECTURE vey depends on the project scope, The target architecture depicts system, you need to but as a rule, identify and specify the vision of an enterprise’s future the systems that execute applicainformation systems. It describes know the system tions for each functional area.Many how the systems will interoperate configuration and organizations do not know what to support future business operainformation technology they really tions, and it almost always repreits interfaces to have or how it is used. For each sents enhancements to an existing other systems. information system, you need to baseline architecture—enhanceknow the system configuration and ments that add functions to supits interfaces (both logical and physport new operations. ical) to other systems.You must also know the business operTo develop the target architecture, use the same archiations it supports. To effectively plan the transition of a tecture views you used to describe the baseline architecture system—either by modernizing or replacing it—you will (see Figure 1). The difference is that the views should now need to know the resources it requires. reflect where the enterprise wants to be, not where it is now. The target architecture is driven by evolving business needs as well as by constraints on implementation,resources, Survey the users Once you describe the views, you will need some meas- technology, and schedules.The business view becomes a key ure of user satisfaction with the existing system. Review driver. For example, the enterprise may now need shorter problem area reports and correlate them with the base- business cycles.This translates into the business requirement line description to identify possible focus areas in devel- “Implement new services more quickly.”The corresponding oping the target architecture. How close is the technical target architecture objectives are then “Make the design quality of existing systems to the quality in the target modular” and “Emphasize component reusability.” Technology is also a driver. The enterprise may want to vision of the architecture? introduce multiple, heterogeneous solutions. This translates to the technology requirement “Meet interoperabilThings to watch for Watch for two common problems when you’re describ- ity standards,” which produces the architecture objectives “Use standard interfaces” and “Emphasize integrated ing the baseline architecture. Overuse of detail. Describe only the major functions design and implementation.” In step 3, you will begin to see the iterative nature of the and interfaces for systems you anticipate replacing. Capture detail only about legacy systems that will con- development process. The target architecture represents a tinue on. For these, you need enough information about complex reality that you will seldom define in one pass. As interoperability, data exchange, and how functions are you refine it, you will see more gaps in the baseline architecinvoked to make the new systems compatible. Legacy ture. Go back to step 2 and refine the baseline accordingly. systems are likely to evolve with each new EITA generation, so the work you do now could save you time Define the target business view later. You will also need more detail on information and The target business view adds structure and detail to the issues that cross system and functional areas. target vision by defining the business requirements. Overmodeling. Describe current processes, work struc- However, because business requirements change continture, information entities, and the state of automation ually, you are essentially capturing a snapshot. Don’t worry clearly and precisely. Quickly develop rough models of the about completeness at this point. Capture only as much architectural views. Don’t spend a lot of time validating detail as you can build into the current iteration of the them because you’ll be seeing them again. Capture just EITA development process. Look for major changes in enough to understand the implications of transitioning to strategic business objectives, new or updated services to the target architecture, and no more. Later, when you cre- clients and customers, or business unit reorganization. July ❘ August 1999 IT Pro
55
ARCHITECTURE
You can represent the target business view in business process models, detailed text descriptions, or BPR results. Many organizations have ongoing business modeling or BPR efforts. Duplicate these results in your target business view. In one large organization we consulted for, different groups were running the EITA development effort and BPR simultaneously, and the groups did not talk to each other. This is one way to guarantee that the target architecture will be out of sync with any new business requirements from the start.
requirements analysis? What design issues arose from considering the constraints on individual information systems?
Target architecture characteristics
To meet the enterprise’s mission, the target architecture must be modifiable, keeping pace with changes in business objectives and operations and with the evolution of infrastructure components. Develop metrics to monitor its success, basing them on quality parameters or the achievement of particular functions. Define the other target architecture views The target architecture views should also be traceable. The target architecture is not just an update of the baseInclude a mapping of architecture line architecture. It is more a forto the business view, the malization of the target vision The target architecture views relationships among work, funcbased on the views used to charaction, information, and infrastructerize the baseline. Update the usually represents ture views, and how critical views from the baseline architecenhancements to an business problems, architecture ture only as appropriate and pracconstraints, and architecture drivtical to reflect the change dictated existing baseline ers have been ad-dressed. This by the target business view. architecture that add helps in explicitly describing the The result should be a document relationships among components that includes the architectural functions to support across the views. For example, for overview, function area descripnew operations. a location defined in the work view, tions, conceptual data models, what data entities (modeled in the environment description, alternainformation view) are used? tives, risks, and key assumptions and rationales. It should also be enough for you to plan What functions (in the function view) are run on what and execute the development of individual information hardware platforms (in the infrastructure view)? When developing the views, be sure to cross-reference entities systems. that depend on entities in another view. Ask the following questions in each view: Mark discontinued organizational units and locations, • Work: Are there new organizational units and business replaced or eliminated functions, and old information locations? Are processes defined from an enterprise per- entities. Don’t delete them.You will need them when you plan the architecture transition.Also, note the alternative spective? • Function: Does the target view completely specify the approaches considered when significant issues were set of functions the enterprise must implement to meet raised. What decisions were made and why? Finally, the target architecture must conform to the prinits objectives? Have the common functions been idenciples and standards defined in the architectural framework. tified? • Information: Are applications to provide needed information in place? Are information resources evolved Things to watch for enough to satisfy the target business view? Have the Avoiding three common mistakes helps to ensure succommon information entities been identified? cess while you’re developing the target architecture. • Infrastructure: What existing information systems will Ignoring the business requirements. This is particularly be retained? Eliminated or decommissioned? What dangerous when legacy systems are involved (almost information systems are to be developed? If the busi- always the case). Legacy systems typically have been built ness objective is to grow 20 percent annually for the next in a stovepipe manner, with different technologies and spethree years, for example, can the infrastructure keep up? cific purposes. If you create the target architecture on the basis of these systems, it may not scale to the entire range You may not be able to fully capture the target infra- of systems the business requirements demand. The busistructure view because technology and business conditions ness requirements drive the rest of the target architectural change so rapidly.The idea is to present possible solutions views.Without evaluating the architecture relative to a set with sufficient clarity to let customers envision the pro- of business requirements, you have no basis for deciding posed solution. The target infrastructure may require which features in the existing systems you should preserve. redesigning the network infrastructure.What interface and Also, creating a target architecture is a process, not an interoperability issues were raised during the business event. Update it as business objectives change. 56
IT Pro July ❘ August 1999
Undermining stakeholder consensus. Reaching agreement on a target architecture definition in a large, changing, multicultural organization with competitive groups is difficult. The larger the organization, the more difficult it will be. Be sure to have all stakeholders validate the definition. Once you have consensus, stick with the agreed-on definition. Institute procedures for changing parts of it in an orderly fashion. Rigid representation. Multiple stakeholders must understand each other when talking about architectural concepts. A modeling approach with a formal notation and a welldefined syntax can help, but some stakeholders may not know how to evaluate it. To get the necessary consistency without sacrificing understandability, use multiple representations or relax the formality constraint. We have employed business use cases and graphical models to represent major information entities to high-level stakeholders and more formal object and data models to communicate with developers.The Zachman framework provides a nice organizational structure to represent different levels.
The next step is to plan the transition from the baseline to the target. During architecture transition planning, you will develop a comprehensive set of project initiatives and sort them by strategic value. The political battle is intense here because all projects must be completed and prioritized (which is why senior management commitment is so important). The last development step is implementation planning— the resources you need to make the transition successfully. But there is more to an EITA than development. Remember that an enterprise architecture is always evolving. To keep it close to the business requirements, you will need a plan to deal with the inevitable changes from technology, budget, or schedule.
TIME OUT
Stephen H. Kaisler is the director of systems architecture at the Office of the Sargeant of Arms, US Senate. Contact him at
[email protected].
At this point, you should have defined the target architecture from four views, as well as identified key relationships among those views.Take a breather and do a process postmortem. We like to gather all key personnel in an allday workshop off site to informally provide feedback on the process so far and brainstorm new development approaches.
Next issue: How to plan the architecture transition and implement the new architecture Frank J. Armour is an associate research professor of information technology at George Mason University. Contact him at
[email protected].
Simon Y. Liu is an assistant director of information management and security at the US Department of Justice. Contact him at
[email protected].
July ❘ August 1999 IT Pro
57
