Download - Enterprise architecture: agile transition and implementation

30 IT Pro November ❘ December 2001 1520-9202/01/$10.00 © 2001 IEEE

Enterprise Architecture:Agile Transition andImplementation

Frank J. Armour and Stephen H. Kaisler

In our previous articles, we made the case forhaving an enterprise architecture (Frank J.Armour, Stephen H. Kaisler, and Simon Y.Liu, “A Big Picture Look at Enterprise

Architectures,” IT Professional, Jan.-Feb. 1999,pp. 35-42) and discussed the first phases of anarchitecture development process (“Building anEnterprise Architecture Step-by-Step,” ITProfessional, May-June 1999, pp. 49-57).The sec-ond article concentrated on describing the base-line architecture and defining the target archi-tecture. In this third article, we complete our dis-cussion of the methodology by focusing on tran-sition and implementation planning.

WHAT ARE TRANSITION ANDIMPLEMENTATION PLANNING?

Once you define a target architecture, the pri-mary question that many executives ask is, howmuch will it cost? The second question is, how dowe get there from here? Many executives thusconfuse the order of these two questions,attempt-ing to address cost issues before understandingthe path. You cannot reliably estimate resource

usage (people, funding, sched-ule, tools, and deployment loca-tions) until you know whatactions to take in moving fromthe baseline to the target archi-tecture.Planning is further com-plicated by long time frames,volatile business conditions,andchanging technology.

Transition planning focuseson deriving a time-phased set of

actions to achieve a given goal—in this case,implementation of the target architecture. Largeorganizations will remediate, renovate, or replacemany systems concurrently. In doing so, they mustrecognize interdependencies among systems andaccommodate them in activity scheduling.

Implementation planning has a different timeframe and a different audience. It maps resources(people, places, things, and funding) to transitionplanning activities.The transition plan provides ahigh level blueprint of the activities needed toachieve a goal; the implementation plan providesa more detailed and short-term allocation ofresources to start and complete individual activ-ities. Several factors can force transition replan-ning, including feedback from the individualactivities, insufficient resources,as well as changesin the business and technology. For this reason,our methodology separates the process of enter-prise architecture transition planning from thatof implementation planning.Although we suggestthat initially, these processes occur sequentially,companies are likely to perform transition plan-ning and implementation planning iteratively.Aniterative approach lets the actual implementationplanning occur in small increments, assessing theplan’s impact on activity scheduling and factor-ing in perceived changes in business conditionsand technology.

We have emphasized coordination with all ele-ments of the organization throughout the archi-tecture development process. For example, it isessential to involve information systems devel-opers during transition and implementation plan-ning.These plans address operation,maintenance,

Architects can’t just generate aplan and throw it over the wallto system developers. An effectiveprocess is holistic, adaptive, andteam oriented.

System TransitionApproaches

CommonOrganizational

Problems

Inside

November ❘ December 2001 IT Pro 31

cutover, and system removal—decisionsthat must involve information systemsdevelopers.

THE IMPORTANCE OF TRANSITIONAND IMPLEMENTATION

Should a systems architect really careabout transition and implementation?Many authors would argue that architect-ing is just planning; you can always writeanother plan if the first (or previous) onedoesn’t meet the organization’s needs. Ofcourse, we emphatically disagree with sucha notion.An organization can only tolerateso many failures before it returns to ad hocmethods of designing, developing, anddelivering information systems.

If you view architecting as separate fromthe process of designing, developing, anddelivering information systems, then yougreatly increase the chances of failure.

In contrast,we see architecting as a holis-tic process and a team-oriented activity.Architects cannot just generate a plan andthrow it over the wall to system developers:They must maintain ownership of the planand a commitment to solving problems asthey arise during development. Architectsmust work as part of an integrated teamwith developers, and this team must reactquickly.As the team designs, develops, anddeploys individual information systems,architects must become mentors and mid-wives for their architecture:not to carry outmost of the work, but to make it easier forthose who actually renovate, remediate,replace, or create information systems.Thearchitecture is often an inadequate guide todevelopers as they make critical decisions;because they focus on individual projects,they might not foresee how their decisionscould affect other projects.. System archi-tects serve as mediators and decision makers across mul-tiple projects, but are particularly important at theinterfaces.

At the end of our last article, we discussed how to definea target architecture using the methodology shown inFigure 1.We pick up our discussion in step 4.

STEP 4: PLAN THE TRANSITIONTransition planning prioritizes a set of development

efforts. In this phased and incremental set of efforts, sev-eral architectural management processes guide and sup-port the transition (and implementation), as Figure 2shows.

In transition planning, architects focus on risk mitiga-tion from the perspectives of technology availability andcomponent interdependency. This step addresses the fol-lowing questions:

• What technology does the organization require toimplement the functions and databases described in thefunctional and information views?

• Does the available technology have the right set of fea-tures to meet the prescribed nonbehavioral require-ments, such as performance, security, and capacity?

• What interactions among components impose interde-pendencies on design, development, and deployment?

Characterize thebaseline architecture

Validate views with user survey

2Infrastructure

view

Informationview

Functionview

Workview

Develop (update)target architecture3

Define target business view

Development process planning and administration (review boards, conflict resolution, training, and so on)

Define target architecture view

Infrastructureview

Informationview

Functionview

Workview

Plan architecturetransition4

Develop individualsystems

Begin

multi

ple lo

ops

Plan architectureimplementation5

Initiate the process

• Scope the project

• Build the team

• Establish a target vision

1

Figure 1. Steps in enterprise architecture development.

32 IT Pro November ❘ December 2001

A R C H I T E C T U R E

Figure 3 depicts the five activities that should occur intransition planning.

Analyzing architectural differencesThe first activity determines the differences between the

baseline and target architectures. Differences occur in twoways:What new work units, information systems, locations,

and databases does the target architec-ture add? Which does it remove?Although developers often focus onwhat’s new, they often fail to focus onwhat is no longer operationally useful.Failing to plan for the retirement ofinformation systems can lead to surpris-ing consequences.

We use gap analysis to identify the dif-ferences in the baseline and target archi-tectures from the five architectural views:business, work, information, functional,and infrastructure. Because an architectdoes not design a target architecture inisolation, the organization has probablyalready analyzed and identified many ofthe differences during the target defini-tion process. Gap analysis enumeratesthe components that an organizationneeds to change to help resolve each dif-ference.

Gap analysis must pay particularattention to legacy systems. Some ofthese will survive into the enterprise sys-tem architecture’s next generation, somewill go away, and some will change. Aprimary principle that architects mustapply is “Sum costs don’t count.”That is,legacy systems only have value in termsof their future contributions to the orga-nization’s mission versus future costs,not the sum of all costs, past and future.Under this doctrine, the organizationmust often determine when the futurecosts of maintaining a legacy system out-weigh the costs of replacing it.

The Year 2000 problem forced thisissue for many organizations. In manycases, it would have been harder to makelegacy code Y2K compliant than to justreplace the system outright. And, manyorganizations took exactly this course inmaking their information systems Y2K-compliant.

Assess technology maturityConcurrent with gap analysis, you

must assess the maturity of the technol-ogy available to implement a target architecture.The tar-get architecture prescribes a set of desired capabilitiesalong with their characteristics, but the technology toimplement these systems must be available.

The US Department of Energy (Information Archi-tecture: Volume III, Guidance, US Dept. of Energy,Washington, D.C., 1996) has defined five levels of techno-

Just-in-time training and mentoring

Knowledge management

Research and development center

Architectural processes and development guidelines

Chief architect and working group collaboration

Reference model of Internet services

Architectural principles and standards

Targetarchitecture

Baselinearchitecture

Transitioning to target architecture

A foundation of architecturalmanagementprocessesguide andsupport ISdevelopmentefforts.

IS development

effort 1

IS development

effort 2

IS development

effort 3

IS development

effort n

Enterprisearchitecturedefinition:

• Work• Functional• Information• Infrastructure• Dimensions

Figure 2. Framework for supporting the transition and implementation to

the target architecture.

Identifydesign

constraints

Analyzearchitecturaldifferences

Assesstechnology

maturity

Toarchitectureimplementationplanning

Selecttransition

opportunities

Definearchitecturetransition

plan

Figure 3. Architecture transition planning phase.

logical maturity.These levels,which Table 1summarizes, are useful in assessing theinformation resources described for anenterprise information system architecture.

The architect must assess the organiza-tion’s existing technology as well as newtechnology to determine whether the newtechnology can support the required capa-bilities. For example, it is highly unlikelythat an organization would use experi-mental technology for mission-critical busi-ness information systems. On the otherhand, although an organization could useobsolete technology to support mission-critical systems, identifying this technologyas obsolete produces a strong impetus toreplace it as soon as possible.

Assessing the maturity of existing tech-nology can be an eye-opener for execu-tives. An oft-heard query is, “But, it stillworks, doesn’t it?” Although the technol-ogy might work today and tomorrow, thekey issue is whether it will continue to workuntil your organization fully implementsthe enterprise architecture’s next genera-tion. Intergenerational failures of mission-critical technology that require an emergency responsecan destroy the careful planning for transition from onegeneration to another.

Identify design constraintsAlthough a technology for implementing a new infor-

mation system can be feasible, it might not be available orrobust enough in time to work for a particular informa-tion system.This is where constraints come in.

Constraints are factors that remain unaffected by archi-tectural changes.Constraints differ from requirements andgoals in that they can involve factors from the world out-side the organization as well as in-house resource andtechnology limitations. Use the following questions to fer-ret out particular types of constraints:

• Functional/behavioral. How often and/or how fast doesthe system need to run? How accurate must it be? Howis the system’s technology delivered?

• Physical. What does it take to physically implement thesystem? How big is it?

• User interface. How does the system need to look?• Operational. Under what conditions does the system

need to work?

These constraints do not consider cost, schedule, or otherresources.The implementation planning phase considersthese types of constraints.

A critical aspect of this activity—which is particularly


appropriate for e-commerce and dot-com enterprises—isto project characteristics of the future user population andthe growth of service usage. These factors affect robust-ness, reliability, scalability, and performance across anarchitecture.

Because they are not the stakeholders for the servicesprovided by systems, many system developers focus onindividual systems but fail to account for intersystem com-munication. Eberhardt Rechtin notes that the greatestrisks to system stability are at the interfaces (The Art ofSystem Architecting, CRC Press, Boca Raton, Fla., 1991).System developers tend not to consider the return oninvestment on either a system or architectural basisbecause they are neither the service providers nor theservice users. However, most systems today are heavilydependent on intersystem communications, such as W-enabled e-commerce systems that depend on differentcommercial-off-the-shelf software packages for imple-mentation and deployment.

Selecting realistic transition opportunitiesIn developing the target architecture, a company often

grasps at more than it can implement given the availableresources. As the architecture team reviews the gapsbetween the baseline and target architectures, and con-siders the dependencies and design constraints, it usuallysees the need to defer some projects. This activity’s goalis a conscious decision about what projects can proceedversus those to defer until the next iteration. The team

Table 1. US Department of Energy levels of technological maturity.

Level Description

Experimental Initial technology examinations, proof-of-principle pilot projects, and exploration of business benefits for a possible future architectural capability.

Adoption and Deliberate, planned architecture project implemen-expansion tations, developments, or deployments that add

to or even completely replace existing baseline capabilities.

Formalization Deliberate, planned architecture projects that continue to add or replace existing baseline capabilities.

Mature Deliberate, planned architecture projects and other initiatives that continue to provide established and proven baseline capabilities.

Obsolete Technologies and capabilities within the baseline that the organization is or should be considering for elimination or replacement.


should take an agile approach in which it determines pri-orities and addresses the highest priority functionality rap-idly. It can then use feedback from these efforts to refinethe transition plan on an ongoing basis.

Critical projects include stay-in-business transitions forinformation systems that run legacy applications (Bing Wuand colleagues,“Legacy System Migration:A Legacy DataMigration Data Engine,” presented at the 17th Int’lDatabase Conf., 1997, http://home.kst.dit.ie/~bwu/datasem97.pdf). The team must understand the perspec-tives and needs of stakeholders—including suppliers—toeffectively drive priorities and transition planning goals.

In selecting transition opportunities, the architectureteam must also review design constraints across all proj-ects. Because a design constraint can apply to multipleprojects, implementing a single solution—rather than mul-tiple solutions—could solve a problem common to severalprojects.

Finally, don’t pass up the opportunity for a fewquick hits—projects that take minimal effortand few resources, but make an immediateimpact on business operations. When the tran-sition time between the baseline and target islong, quick hits demonstrate progress and canhelp to alleviate problems while you developlong-term solutions.They can also help maintainstakeholder commitment to the transition plan-ning’s long-term goals as well as provide cus-tomer feedback to future projects. In selectingquick-hit opportunities, don’t be afraid to throwthe work’s result away once you complete the

full transition. Quick-hit opportu-nities might involve the imple-mentation of a basic enterpriseWeb portal, upgrade of user desk-top platforms, or deployment of aWeb-enabled resource requestform for all users.

Define the architecture transition plan

An architecture transition plan(ATP) describes the changes that each systemmust undergo to move from the current archi-tecture to the target architecture. In regard toindividual systems, architects have three basicchoices, which the “System Transition Ap-proaches” sidebar explains. An ATP also pro-vides a tentative schedule for modifications tothe baseline architecture based on changes toindividual information systems. This scheduleaccounts for the interdependencies among indi-vidual systems.The ATP must explicitly identifyquick hits, especially those that are only tempo-rary improvements.

Things to watch forAlthough traditional architecture frameworks for enter-

prise IT address the pressures of global and enterprise-wide scopes, key challenges arise when dealing with theother two pressures: business and technology changes.First, the idea of predicting “to be” or “target” enterprise-wide architectures becomes problematic given changingbusiness and technology drivers. A target architecturefaces consistent pressures both from the top—as businesschanges force the need for new systems—as well as fromthe bottom, when the underlying technology shifts.

Therefore, although it is possible to plan target archi-tecture objectives in the short term, longer-term (multi-year) targets are increasingly difficult to formulate. AsFigure 4 shows, the path to a long-term target vision canchange as the target shifts. Organizations must be flexibleand able to adjust to these changes. Challenges include


Three approaches—renovation, migration, or replacement—apply to individual information systems in their transition froma baseline to a target architecture.

In renovation, system developers modify and/or enhanceinformation systems. Jesús Bisbal suggests wrapping legacyinformation systems—surrounding an existing system with newinterfaces (Jesús Bisbal and colleagues, “Legacy InformationSystems: Issues and Directions,” IEEE Software, Sept.-Oct.1999, pp. 103-111). This gives the old system new operationsand data structures and/or a new and improved look. Thewrapped system acts as a server to perform functionsrequired by an external client, which does not needto know how the system implements the service.

In migration (Michael L. Brodie and MichaelStonebraker, “DARWIN: On the IncrementalMigration of Legacy Information Systems,” Dis-tributed Object Computing Group TR-0222-10-92-165, GTE Labs, Mar. 1993, http://s2k-ftp.cs.berkeley.edu:8000/postgres/papers/S2K-93-25.pdf),system developers move the information system to anew infrastructure platform. Typically, this move will require achange in hardware and software platforms. Developers canreplace the computer system, the operating system, or both,although they are more likely to retain the hardware platformand replace the operating system.

Replacement usually replaces a system in its entirety—bothhardware and software platforms. System developers must planfor a suitable period of parallel operation, and then a cutoverschedule and process. Developers often employ this approachfor legacy systems that have reached obsolescence from a busi-ness needs and operations perspective.

System Transition Approaches


• managing a global enterprise IT architecture in a rap-idly changing environment,

• predicting technology and business trends to use inbuilding a formal target architecture,

• responding rapidly to new trends, and• developing a management framework for an architec-

ture that lets it remain adaptive.

Bernard Boar describes the difference between a strat-egy of actuality and a strategy of readiness (Bernard H.“Bernie” Boar,“A Blueprint for Solving Problems in YourIT Architecture,” IT Professional, Nov.-Dec. 1999, pp. 23-29).A strategy of actuality is a set of activities that achievea known set of outcomes.A strategy of readiness is a non-specific set of actions that position you to strike. Becauseyou don’t know exactly what you will have to do, orbecause events are in constant flux, such a strategy lets yourespond in any direction with force and quickness, whenneeded. Traditional architectural planning is normally astrategy of actuality, but in today’s business environment,most companies need a strategy of readiness.

Readiness involves three dimensions: technology,organ-ization, and process. First, the technology should be openand scalable. Second, the organization should be able torespond to changing conditions with capabilities such asjust-in-time training, organization-wide mentoring, and atechnology lab to rapidly evaluate new technology.Finally,the development approaches should be adaptive and agile,supporting changing requirements and rework.

System architectures include hardware, software, andtelecommunications components. Most of these architec-tures use the control hierarchies that were in place whena company first implemented these components,which canbe as long as two decades ago. Dynamic changes in thenational and global business environment, including imple-menting e-business systems, increase the need to integrateand redesign the information systems that build upon thesearchitectures.

Most companies will weight architecture transition planstoward technology initiatives.These initiatives do not existin a vacuum, but complement initiatives that reengineerbusiness processes and procedures. For example, the coor-dinated implementation of technologies and tools canrequire a physical-facility redesign;capital investment;newpolicies and procedures, organizational structures, andtraining efforts; and metrics and outcome measures. It caneven dictate new business practices.

So, the transition from the baseline to the target archi-tecture will likely encompass multiple activities and proj-ects. Many of these activities will have interdependencies,so careful transition planning is essential to the targetarchitecture’s successful and timely implementation.

It’s best to perform transition planning, not in a vacuum,but with minimal concern for cost, schedule, and humanresources. The goal is to develop a clear technical picture

of what the organization has to do and an assessment ofits technological feasibility.

When preparing a transition plan, you must rememberthat leadership is crucial. Management needs to invest thetime up front to provide leadership and build appropriatemanagement structures and techniques. You cannot fullydelegate architecture transition planning to a project man-ager or a single systems architect. You can delegate partsof the task,but the transition plan must represent the orga-nization’s view of how to reach the target architecture.

A key use for a transition plan is to ensure that stake-holders are onboard, engaged, and part of a joint, strategicprocess.You must be prepared to share knowledge with allelements of the organization.Defining and sharing enoughof the right information between responsible organizationswill help to ensure appropriate knowledge for action.

Finally, you must remember that transition planning isnot a detailed road map;rather, it defines a set of key objec-tives and a high-level, prioritized approach to reach theseobjectives.The transition plan is a living document and willneed adjusting as the organization implements the archi-tecture.

STEP 5: DEVELOP AN IMPLEMENTATION PLANThe last step in architecture definition and development

is preparing an architecture implementation plan.This planmaps resources—budgets, schedule, people, and prod-ucts—to the choices made earlier in transition planning.But, not all resources are available when needed andschedules don’t always mesh properly. So, you might have

A

Targetshifts

Initialarget

A + X

Targetshifts

A + 2X

Archivetarget

A + 3X

Architectural development path Target architectureTime

Figure 4. Adaptive architecture development path.


to defer some transition choices for one or more iterationsof the architecture development process. Figure 5 depictsthe three steps for developing the architecture implemen-tation plan.

Emerging from the implementation planning process,the architecture implementation plan goes to the individ-ual project teams, which follow the organization’s systemdevelopment life cycle (SDLC) methodology. Detailedplanning of project activities occurs within the SDLCprocesses.

Define/update the program management plan

The program management plan describesthe human and financial resources availablefor information system projects. From anarchitecture viewpoint, the program man-agement plan is notional: It should identifythe type and quantity of resources withoutreference to specific individuals, or to specificsoftware or hardware items.This latter infor-mation comes from the individual projectmanagers, who specify it when their teambegins or continues specific projects in theSDLC methodology.

An obvious exception to the notional con-tent of the program management plan is whereinformation system development projectscross multiple architectural generations. You

should identify specific, earlierdecisions—including project per-sonnel, software and hardwarechoices, and so on—in the pro-gram management plan, asappropriate.

Specify information system development

The actual implementation ofthe architecture is divided into a set of systemdevelopment projects. The project managersshould conduct detailed design and specifica-tion of information systems’ remediation, ren-ovation, or replacement under the auspices ofthe SDLC methodology. However, the archi-tecture implementation plan should describe—for each information system—the majorchanges necessary for remediation, renova-tion,or replacement. If you’ve chosen replace-ment, the description should highlight thereplacement system’s new features and capa-bilities.

In calling for renovation or replacement,always consider the impact of data conver-sion. You need to decide what data to bringforward into the new system and what to

leave behind. If the new system allows for more capaciousdata storage and manipulation than the old, you mustmake a separate decision as to what new data to gatherand input to fully use the new functionality. This activitywill require some data transformations. Early identifica-tion of these conversions occurs when considering indi-vidual systems in the larger architectural context.

The architecture implementation plan should also high-light those information systems to be retired from service,and it should specify the disposition of hardware and soft-


Define/updateprogram

managementplan

To systemdevelopmentlife cycleprocess

Specifyinformation

systemdevelopment

Define/updatearchitecture

implementationplan

Figure 5. Architecture implementation planning phase.

The challenges involved in transitioning and implementing anenterprise-wide architecture involve more than technical or busi-ness problems. Large organizational structures canpresent their own set of difficulties, including

➤ thinking that you can “big bang” the implemen-tation of a large enterprise architecture,

➤ not taking an iterative approach to building anenterprise architecture,

➤ inexperience with large-scale efforts,

➤ stovepiped organizations with no history of work-ing together,

➤ multiple organizations with duplicate functional areas (such aseach business area with its own information technology or mar-keting group),

➤ lack of a common vision or buy-in to success measures and tar-gets,

➤ lack of leadership that can really own and drive the process (forexample, if the chief systems architect is also the project man-ager, he will lack the time to effectively lead transition andimplementation),

➤ passive or outright resistance to enterprise-wide architectureplanning,

➤ organizations with a history of resisting change, and

➤ a lack of agreement on roles and responsibilities.

Common Organizational Problems


ware.Architecture implementation is a good time to deter-mine how the organization’s archival requirements andguidelines for information apply to individual informationsystems.

Define/update the architecture implementa-tion plan

You construct the architecture implementation planfrom the ATP. In this phase, you consider resources forindividual projects, and can defer elements of the ATP forone or more generations because of resource constraints.Once you revise the ATP for these deferments, you applyresources to the ATP’s element to create the architectureimplementation plan.

Rather than creating an entirely new document, the sys-tem architecting team should annotate the ATP withresource allocations to create the architecture implemen-tation plan. These allocations are notional—number ofpeople and their tentative skill levels, funding by fiscal year,locations where the work will be performed, and so on.Detailed resource allocation occurs within individual proj-ects in adherence to the organization’s SDLC methodol-ogy, but uses the annotated ATP as a baseline. Byannotating the ATP, you make it easier to manage futurerevisions to both documents.

Executing the plan: Working with the implementation projects

The final activity in architecture development is to handoff the high-level specifications for the modernization, ren-ovation,or replacement of information systems to the proj-ect managers. By handoff, we mean that the responsibilityfor detailed planning of implementation projects transfersto the implementation teams. However, the system archi-tecting team has an enduring role in tracking the progressof individual implementations. Another role is to resolveconflicts, particularly at the interfaces, as individual imple-mentation teams proceed with their detailed designs andimplementation plans.

Things to watch forKeep the development efforts short—six to 12 months at

most, if possible.Within an effort, iterate to learn and dealwith changing requirements. The enterprise architectsshould be as closely involved in the individual efforts aspossible, to facilitate as tight a feedback loop as possible.Make sure that the overall objectives and efforts definingthe transition are still up to date.

CONTINUING ROLE FOR SYSTEMS ARCHITECTSThe architects still have a role to play. For example, they

must coordinate the remediation, renovation, or replace-ment of those components that have high reusability, thatis, the infrastructure components. These components fallinto three categories:

• foundational components, such as those for communi-cations networks, which IT staffs must implementrobustly for the architecture to succeed;

• common tools, which every project group must use toensure consistency and commonality; and

• scaffolding components, which serve as a bridge fromthe old architecture to the new.

Enterprise transition and implementation planning leadto a more realistic and achievable schedule.The tran-sition and implementation planning processes pro-

duce a more realistic and achievable schedule because theschedule reflects both top-down objectives and bottom-up realism and buy-in.They help senior systems architectsfocus on progress and high-risk issues by providing sub-stantive information to support informed decisions with-out poring through raw data.This two-pronged approachsupports project management accountability and flexibil-ity. Individual project managers do not usually perceivethis approach as threatening, because the implementationplan adds value without micromanaging.Project managersare accountable for meeting their commitments but con-trol the project management processes and tools.

This approach unmasks unrealistic planning assumptionsand gaps early. Clearly defined assumptions, roles, andresponsibilities avoid gaps and misunderstandings.Realizations such as, “I thought your project was doingthat!” can spell disaster if discovered too late to take cor-rective action.

Be aware that resistance to this approach can alienatepeople and disrupt projects.Early team building with proj-ect managers and stakeholders can help prevent disrup-tions and ensure that all stakeholders reach a consensus,especially on intersystem interactions. �

Frank J. Armour is an internationally recognized, inde-pendent IT consultant specializing in system architecting,requirements engineering, and object-oriented systemsanalysis and design. He is also an adjunct professor for theManagement of Global Information Technology programat the Kogol School of Business,American University. Con-tact him at [email protected].

Stephen H. Kaisler is the director of systems architectureat the Office of the Sergeant of Arms and Technology Advi-sor to the Sergeant At Arms,US Senate.He is also an adjunctprofessor of computer science in the School of Engineer-ing and Applied Science at George Washington University.Contact him at [email protected].

Download - Enterprise architecture: agile transition and implementation

Top Related