Enterprise architecture: agile transition and implementation

Download Enterprise architecture: agile transition and implementation

Post on 13-Mar-2017

217 views

Category:

Documents

2 download

TRANSCRIPT

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

    CommonOrganizational

    Problems

    Inside

  • November December 2001 IT Pro 31

    cutover, and system removaldecisionsthat 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) 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

    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

    Begi

    n

    mul

    tiple

    loop

    s

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

    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-tions 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, doesnt it? Although the technol-ogy might work today and tomorrow, thekey issue is whether it will continue to workuntil your organization fully implementsthe enterprise architectures 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 systems 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 activitywhich is particularly

    November December 2001 IT Pro 33

    appropriate for e-commerce and dot-com enterprisesisto 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 activitys 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.

  • 34 IT Pro November December 2001

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

Recommended

View more >