Enterprise architecture: agile transition and implementation

Download Enterprise architecture: agile transition and implementation

Post on 13-Mar-2017




2 download

Embed Size (px)


  • 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.


    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 goalin 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 theplans 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 cant just generate aplan and throw it over the wallto system developers. An effectiveprocess is holistic, adaptive, andteam oriented.

    System TransitionApproaches




  • November December 2001 IT Pro 31

    cutover, and system removaldecisionsthat must involve information systemsdevelopers.


    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) onedoesnt meet the organizations 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






    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





    Plan architecturetransition4

    Develop individualsystems







    Plan architectureimplementation5

    Initiate the process

    Scope the project

    Build the team

    Establish a target vision


    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 onwhats 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 architectures next generation, somewill go away, and some will change. Aprimary principle that architects mustapply is Sum costs dont count.That is,legacy systems only have value in termsof their future contributions to the orga-nizations 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



    Transitioning to target