Enterprise architecture - IEEE Xplore

3 downloads 0 Views 354KB Size Report
In our previous articles, we made the case for having an enterprise architecture (Frank J. Armour, Stephen H. Kaisler, and Simon Y. Liu, “A Big Picture Look at ...
Architects can’t just generate a plan and throw it over the wall to system developers. An effective process is holistic, adaptive, and team oriented. Frank J. Armour and Stephen H. Kaisler

Enterprise Architecture: Agile Transition and Implementation

I

n our previous articles, we made the case for having 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 an architecture development process (“Building an Enterprise Architecture Step-by-Step,” IT Professional, May-June 1999, pp. 49-57).The second article concentrated on describing the baseline architecture and defining the target architecture. In this third article, we complete our discussion of the methodology by focusing on transition and implementation planning.

WHAT ARE TRANSITION AND IMPLEMENTATION PLANNING? Once you define a target architecture, the primary question that many executives ask is, how much will it cost? The second question is, how do we get there from here? Many executives thus confuse the order of these two questions, attempting to address cost issues before understanding the path. You cannot reliably estimate resource usage (people, funding, schedule, tools, and deployment locations) until you know what actions to take in moving from the baseline to the target archiSystem Transition tecture. Planning is further comApproaches plicated by long time frames, Common volatile business conditions, and Organizational changing technology. Problems Transition planning focuses on deriving a time-phased set of

Inside

30

IT Pro November ❘ December 2001

actions to achieve a given goal—in this case, implementation of the target architecture. Large organizations will remediate, renovate, or replace many systems concurrently. In doing so, they must recognize interdependencies among systems and accommodate them in activity scheduling. Implementation planning has a different time frame and a different audience. It maps resources (people, places, things, and funding) to transition planning activities.The transition plan provides a high level blueprint of the activities needed to achieve a goal; the implementation plan provides a more detailed and short-term allocation of resources to start and complete individual activities. Several factors can force transition replanning, including feedback from the individual activities, insufficient resources, as well as changes in the business and technology. For this reason, our methodology separates the process of enterprise architecture transition planning from that of implementation planning.Although we suggest that initially, these processes occur sequentially, companies are likely to perform transition planning and implementation planning iteratively.An iterative approach lets the actual implementation planning occur in small increments, assessing the plan’s impact on activity scheduling and factoring in perceived changes in business conditions and technology. We have emphasized coordination with all elements of the organization throughout the architecture development process. For example, it is essential to involve information systems developers during transition and implementation planning.These plans address operation, maintenance, 1520-9202/01/$10.00 © 2001 IEEE

cutover, and system removal—decisions that must involve information systems developers.

THE IMPORTANCE OF TRANSITION AND IMPLEMENTATION

Figure 1. Steps in enterprise architecture development.

1

2

Initiate the process

Characterize the baseline architecture

m

ul Be tip g le in lo op s

Should a systems architect really care Infrastructure Function about transition and implementation? • Scope the project view view Many authors would argue that architect• Build the team ing is just planning; you can always write • Establish a target vision Information Work another plan if the first (or previous) one view view doesn’t meet the organization’s needs. Of course, we emphatically disagree with such Validate views with user survey a notion.An organization can only tolerate so many failures before it returns to ad hoc methods of designing, developing, and delivering information systems. If you view architecting as separate from the process of designing, developing, and delivering information systems, then you Plan architecture Develop (update) greatly increase the chances of failure. implementation target architecture In contrast, we see architecting as a holistic process and a team-oriented activity. Define target business view Architects cannot just generate a plan and throw it over the wall to system developers: They must maintain ownership of the plan Define target architecture view and a commitment to solving problems as they arise during development. Architects Infrastructure Function view view must work as part of an integrated team with developers, and this team must react Information Work quickly. As the team designs, develops, and view view Develop individual deploys individual information systems, systems architects must become mentors and midwives for their architecture: not to carry out most of the work, but to make it easier for those who actually renovate, remediate, Development process replace, or create information systems.The planning and administration architecture is often an inadequate guide to (review boards, conflict Plan architecture developers as they make critical decisions; resolution, training, transition and so on) because they focus on individual projects, they might not foresee how their decisions could affect other projects.. System architects serve as mediators and decision makers across mulIn transition planning, architects focus on risk mitigatiple projects, but are particularly important at the tion from the perspectives of technology availability and interfaces. component interdependency. This step addresses the folAt the end of our last article, we discussed how to define lowing questions: a target architecture using the methodology shown in Figure 1. We pick up our discussion in step 4. • What technology does the organization require to implement the functions and databases described in the functional and information views? STEP 4: PLAN THE TRANSITION • Does the available technology have the right set of feaTransition planning prioritizes a set of development tures to meet the prescribed nonbehavioral requireefforts. In this phased and incremental set of efforts, sevments, such as performance, security, and capacity? eral architectural management processes guide and sup• What interactions among components impose interdeport the transition (and implementation), as Figure 2 pendencies on design, development, and deployment? shows.

5

3

4

November ❘ December 2001 IT Pro

31

ARCHITECTURE

Figure 2. Framework for supporting the transition and implementation to the target architecture. Baseline architecture

Target architecture Transitioning to target architecture

IS development effort 1 IS development effort 2

Enterprise architecture definition: • Work • Functional • Information • Infrastructure • Dimensions

IS development effort 3 IS development effort n

Architectural principles and standards A foundation of architectural management processes guide and support IS development efforts.

Reference model of Internet services Chief architect and working group collaboration Architectural processes and development guidelines Research and development center Knowledge management Just-in-time training and mentoring

Figure 3. Architecture transition planning phase. Analyze architectural differences Identify design constraints

Select transition opportunities

Define architecture transition plan

Assess technology maturity

To architecture implementation planning

and databases does the target architecture add? Which does it remove? Although developers often focus on what’s new, they often fail to focus on what is no longer operationally useful. Failing to plan for the retirement of information systems can lead to surprising consequences. We use gap analysis to identify the differences in the baseline and target architectures from the five architectural views: business, work, information, functional, and infrastructure. Because an architect does not design a target architecture in isolation, the organization has probably already analyzed and identified many of the differences during the target definition process. Gap analysis enumerates the components that an organization needs to change to help resolve each difference. Gap analysis must pay particular attention to legacy systems. Some of these will survive into the enterprise system architecture’s next generation, some will go away, and some will change. A primary principle that architects must apply is “Sum costs don’t count.”That is, legacy systems only have value in terms of their future contributions to the organization’s mission versus future costs, not the sum of all costs, past and future. Under this doctrine, the organization must often determine when the future costs of maintaining a legacy system outweigh the costs of replacing it. The Year 2000 problem forced this issue for many organizations. In many cases, it would have been harder to make legacy code Y2K compliant than to just replace the system outright. And, many organizations took exactly this course in making their information systems Y2Kcompliant.

Assess technology maturity

Figure 3 depicts the five activities that should occur in transition planning.

Analyzing architectural differences The first activity determines the differences between the baseline and target architectures. Differences occur in two ways:What new work units, information systems, locations, 32

IT Pro November ❘ December 2001

Concurrent with gap analysis, you must assess the maturity of the technology available to implement a target architecture.The target architecture prescribes a set of desired capabilities along with their characteristics, but the technology to implement these systems must be available. The US Department of Energy (Information Architecture: Volume III, Guidance, US Dept. of Energy, Washington, D.C., 1996) has defined five levels of techno-

logical maturity.These levels, which Table 1 summarizes, are useful in assessing the Table 1. US Department of Energy information resources described for an levels of technological maturity. enterprise information system architecture. The architect must assess the organizaLevel Description tion’s existing technology as well as new Experimental Initial technology examinations, proof-of-principle technology to determine whether the new pilot projects, and exploration of business benefits technology can support the required capafor a possible future architectural capability. bilities. For example, it is highly unlikely that an organization would use experiAdoption and Deliberate, planned architecture project implemenmental technology for mission-critical busiexpansion tations, developments, or deployments that add ness information systems. On the other to or even completely replace existing baseline hand, although an organization could use capabilities. obsolete technology to support missionFormalization Deliberate, planned architecture projects that critical systems, identifying this technology continue to add or replace existing baseline as obsolete produces a strong impetus to capabilities. replace it as soon as possible. Assessing the maturity of existing techMature Deliberate, planned architecture projects and other nology can be an eye-opener for execuinitiatives that continue to provide established and tives. An oft-heard query is, “But, it still proven baseline capabilities. works, doesn’t it?” Although the technolObsolete Technologies and capabilities within the baseline ogy might work today and tomorrow, the that the organization is or should be considering key issue is whether it will continue to work for elimination or replacement. until your organization fully implements the enterprise architecture’s next generation. Intergenerational failures of missioncritical technology that require an emergency response appropriate for e-commerce and dot-com enterprises—is can destroy the careful planning for transition from one to project characteristics of the future user population and generation to another. the growth of service usage. These factors affect robustness, reliability, scalability, and performance across an architecture. Identify design constraints Because they are not the stakeholders for the services Although a technology for implementing a new inforprovided by systems, many system developers focus on mation system can be feasible, it might not be available or individual systems but fail to account for intersystem comrobust enough in time to work for a particular informamunication. Eberhardt Rechtin notes that the greatest tion system. This is where constraints come in. risks to system stability are at the interfaces (The Art of Constraints are factors that remain unaffected by archiSystem Architecting, CRC Press, Boca Raton, Fla., 1991). tectural changes. Constraints differ from requirements and System developers tend not to consider the return on goals in that they can involve factors from the world outinvestment on either a system or architectural basis side the organization as well as in-house resource and because they are neither the service providers nor the technology limitations. Use the following questions to ferservice users. However, most systems today are heavily ret out particular types of constraints: dependent on intersystem communications, such as Wenabled e-commerce systems that depend on different • Functional/behavioral. How often and/or how fast does commercial-off-the-shelf software packages for implethe system need to run? How accurate must it be? How mentation and deployment. is the system’s technology delivered? • Physical. What does it take to physically implement the system? How big is it? Selecting realistic transition opportunities • User interface. How does the system need to look? In developing the target architecture, a company often • Operational. Under what conditions does the system grasps at more than it can implement given the available need to work? resources. As the architecture team reviews the gaps between the baseline and target architectures, and conThese constraints do not consider cost, schedule, or other siders the dependencies and design constraints, it usually resources. The implementation planning phase considers sees the need to defer some projects. This activity’s goal these types of constraints. is a conscious decision about what projects can proceed A critical aspect of this activity—which is particularly versus those to defer until the next iteration. The team November ❘ December 2001 IT Pro

33

ARCHITECTURE

System Transition Approaches Three approaches—renovation, migration, or replacement— apply to individual information systems in their transition from a baseline to a target architecture. In renovation, system developers modify and/or enhance information systems. Jesús Bisbal suggests wrapping legacy information systems—surrounding an existing system with new interfaces (Jesús Bisbal and colleagues, “Legacy Information Systems: Issues and Directions,” IEEE Software, Sept.-Oct. 1999, pp. 103-111). This gives the old system new operations and data structures and/or a new and improved look. The wrapped system acts as a server to perform functions required by an external client, which does not need to know how the system implements the service. In migration (Michael L. Brodie and Michael Stonebraker, “DARWIN: On the Incremental Migration of Legacy Information Systems,” Distributed Object Computing Group TR-0222-10-92165, GTE Labs, Mar. 1993, http://s2k-ftp.cs. berkeley.edu:8000/postgres/papers/S2K-93-25.pdf), system developers move the information system to a new infrastructure platform. Typically, this move will require a change in hardware and software platforms. Developers can replace the computer system, the operating system, or both, although they are more likely to retain the hardware platform and replace the operating system. Replacement usually replaces a system in its entirety—both hardware and software platforms. System developers must plan for a suitable period of parallel operation, and then a cutover schedule and process. Developers often employ this approach for legacy systems that have reached obsolescence from a business needs and operations perspective.

should take an agile approach in which it determines priorities and addresses the highest priority functionality rapidly. It can then use feedback from these efforts to refine the transition plan on an ongoing basis. Critical projects include stay-in-business transitions for information systems that run legacy applications (Bing Wu and colleagues,“Legacy System Migration:A Legacy Data Migration Data Engine,” presented at the 17th Int’l Database Conf., 1997, http://home.kst.dit.ie/~bwu/ datasem97.pdf). The team must understand the perspectives and needs of stakeholders—including suppliers—to effectively drive priorities and transition planning goals. In selecting transition opportunities, the architecture team must also review design constraints across all projects. Because a design constraint can apply to multiple projects, implementing a single solution—rather than multiple solutions—could solve a problem common to several projects. 34

IT Pro November ❘ December 2001

Finally, don’t pass up the opportunity for a few quick hits—projects that take minimal effort and few resources, but make an immediate impact on business operations. When the transition time between the baseline and target is long, quick hits demonstrate progress and can help to alleviate problems while you develop long-term solutions.They can also help maintain stakeholder commitment to the transition planning’s long-term goals as well as provide customer feedback to future projects. In selecting quick-hit opportunities, don’t be afraid to throw the work’s result away once you complete the full transition. Quick-hit opportunities might involve the implementation of a basic enterprise Web portal, upgrade of user desktop platforms, or deployment of a Web-enabled resource request form for all users.

Define the architecture transition plan An architecture transition plan (ATP) describes the changes that each system must undergo to move from the current architecture to the target architecture. In regard to individual systems, architects have three basic choices, which the “System Transition Approaches” sidebar explains. An ATP also provides a tentative schedule for modifications to the baseline architecture based on changes to individual information systems. This schedule accounts for the interdependencies among individual systems.The ATP must explicitly identify quick hits, especially those that are only temporary improvements.

Things to watch for Although traditional architecture frameworks for enterprise IT address the pressures of global and enterprisewide scopes, key challenges arise when dealing with the other two pressures: business and technology changes. First, the idea of predicting “to be” or “target” enterprisewide architectures becomes problematic given changing business and technology drivers. A target architecture faces consistent pressures both from the top—as business changes force the need for new systems—as well as from the bottom, when the underlying technology shifts. Therefore, although it is possible to plan target architecture objectives in the short term, longer-term (multiyear) targets are increasingly difficult to formulate. As Figure 4 shows, the path to a long-term target vision can change as the target shifts. Organizations must be flexible and able to adjust to these changes. Challenges include

• managing a global enterprise IT architecture in a rapidly changing environment, • predicting technology and business trends to use in building a formal target architecture, • responding rapidly to new trends, and • developing a management framework for an architecture that lets it remain adaptive. Bernard Boar describes the difference between a strategy of actuality and a strategy of readiness (Bernard H. “Bernie” Boar,“A Blueprint for Solving Problems in Your IT Architecture,” IT Professional, Nov.-Dec. 1999, pp. 2329).A strategy of actuality is a set of activities that achieve a known set of outcomes. A strategy of readiness is a nonspecific set of actions that position you to strike. Because you don’t know exactly what you will have to do, or because events are in constant flux, such a strategy lets you respond in any direction with force and quickness, when needed. Traditional architectural planning is normally a strategy of actuality, but in today’s business environment, most companies need a strategy of readiness. Readiness involves three dimensions: technology, organization, and process. First, the technology should be open and scalable. Second, the organization should be able to respond to changing conditions with capabilities such as just-in-time training, organization-wide mentoring, and a technology 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, and telecommunications components. Most of these architectures use the control hierarchies that were in place when a company first implemented these components, which can be as long as two decades ago. Dynamic changes in the national and global business environment, including implementing e-business systems, increase the need to integrate and redesign the information systems that build upon these architectures. Most companies will weight architecture transition plans toward technology initiatives.These initiatives do not exist in a vacuum, but complement initiatives that reengineer business processes and procedures. For example, the coordinated implementation of technologies and tools can require a physical-facility redesign; capital investment; new policies and procedures, organizational structures, and training efforts; and metrics and outcome measures. It can even dictate new business practices. So, the transition from the baseline to the target architecture will likely encompass multiple activities and projects. Many of these activities will have interdependencies, so careful transition planning is essential to the target architecture’s successful and timely implementation. It’s best to perform transition planning, not in a vacuum, but with minimal concern for cost, schedule, and human resources. The goal is to develop a clear technical picture

Figure 4. Adaptive architecture development path. Time

Architectural development path Target architecture

A

Initial arget

A+X

Target shifts

A + 2X

Target shifts

A + 3X

Archive target

of what the organization has to do and an assessment of its technological feasibility. When preparing a transition plan, you must remember that leadership is crucial. Management needs to invest the time up front to provide leadership and build appropriate management structures and techniques. You cannot fully delegate architecture transition planning to a project manager or a single systems architect. You can delegate parts of the task, but the transition plan must represent the organization’s view of how to reach the target architecture. A key use for a transition plan is to ensure that stakeholders are onboard, engaged, and part of a joint, strategic process.You must be prepared to share knowledge with all elements of the organization. Defining and sharing enough of the right information between responsible organizations will help to ensure appropriate knowledge for action. Finally, you must remember that transition planning is not a detailed road map; rather, it defines a set of key objectives and a high-level, prioritized approach to reach these objectives.The transition plan is a living document and will need adjusting as the organization implements the architecture.

STEP 5: DEVELOP AN IMPLEMENTATION PLAN The last step in architecture definition and development is preparing an architecture implementation plan.This plan maps resources—budgets, schedule, people, and products—to the choices made earlier in transition planning. But, not all resources are available when needed and schedules don’t always mesh properly. So, you might have November ❘ December 2001 IT Pro

35

ARCHITECTURE

Figure 5. Architecture implementation planning phase. Define/update program management plan

Specify information system development

Define/update architecture implementation plan

To system development life cycle process

Common Organizational Problems The challenges involved in transitioning and implementing an enterprise-wide architecture involve more than technical or business problems. Large organizational structures can present their own set of difficulties, including ➤ thinking that you can “big bang” the implementation of a large enterprise architecture, ➤ not taking an iterative approach to building an enterprise architecture, ➤ inexperience with large-scale efforts, ➤ stovepiped organizations with no history of working together,

Define/update the program management plan The program management plan describes the human and financial resources available for information system projects. From an architecture viewpoint, the program management plan is notional: It should identify the type and quantity of resources without reference to specific individuals, or to specific software or hardware items.This latter information comes from the individual project managers, who specify it when their team begins or continues specific projects in the SDLC methodology. An obvious exception to the notional content of the program management plan is where information system development projects cross multiple architectural generations. You should identify specific, earlier decisions—including project personnel, software and hardware choices, and so on—in the program management plan, as appropriate.

Specify information system development

The actual implementation of the architecture is divided into a set of system ➤ multiple organizations with duplicate functional areas (such as development projects. The project managers each business area with its own information technology or marshould conduct detailed design and specificaketing group), tion of information systems’ remediation, ren➤ lack of a common vision or buy-in to success measures and tarovation, or replacement under the auspices of gets, the SDLC methodology. However, the architecture implementation plan should describe ➤ lack of leadership that can really own and drive the process (for —for each information system—the major example, if the chief systems architect is also the project manchanges necessary for remediation, renovaager, he will lack the time to effectively lead transition and tion, or replacement. If you’ve chosen replaceimplementation), ment, the description should highlight the ➤ passive or outright resistance to enterprise-wide architecture replacement system’s new features and capaplanning, bilities. ➤ organizations with a history of resisting change, and In calling for renovation or replacement, ➤ a lack of agreement on roles and responsibilities. always consider the impact of data conversion. You need to decide what data to bring forward into the new system and what to to defer some transition choices for one or more iterations leave behind. If the new system allows for more capacious of the architecture development process. Figure 5 depicts data storage and manipulation than the old, you must the three steps for developing the architecture implemen- make a separate decision as to what new data to gather and input to fully use the new functionality. This activity tation plan. Emerging from the implementation planning process, will require some data transformations. Early identificathe architecture implementation plan goes to the individ- tion of these conversions occurs when considering indiual project teams, which follow the organization’s system vidual systems in the larger architectural context. The architecture implementation plan should also highdevelopment life cycle (SDLC) methodology. Detailed planning of project activities occurs within the SDLC light those information systems to be retired from service, and it should specify the disposition of hardware and softprocesses. 36

IT Pro November ❘ December 2001

ware.Architecture implementation is a good time to determine how the organization’s archival requirements and guidelines for information apply to individual information systems.

Define/update the architecture implementation plan You construct the architecture implementation plan from the ATP. In this phase, you consider resources for individual projects, and can defer elements of the ATP for one or more generations because of resource constraints. Once you revise the ATP for these deferments, you apply resources to the ATP’s element to create the architecture implementation plan. Rather than creating an entirely new document, the system architecting team should annotate the ATP with resource allocations to create the architecture implementation plan. These allocations are notional—number of people 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 projects in adherence to the organization’s SDLC methodology, but uses the annotated ATP as a baseline. By annotating the ATP, you make it easier to manage future revisions to both documents.

Executing the plan: Working with the implementation projects The final activity in architecture development is to hand off the high-level specifications for the modernization, renovation, or replacement of information systems to the project managers. By handoff, we mean that the responsibility for detailed planning of implementation projects transfers to the implementation teams. However, the system architecting team has an enduring role in tracking the progress of individual implementations. Another role is to resolve conflicts, particularly at the interfaces, as individual implementation teams proceed with their detailed designs and implementation plans.

Things to watch for Keep the development efforts short—six to 12 months at most, if possible.Within an effort, iterate to learn and deal with changing requirements. The enterprise architects should be as closely involved in the individual efforts as possible, to facilitate as tight a feedback loop as possible. Make sure that the overall objectives and efforts defining the transition are still up to date.

CONTINUING ROLE FOR SYSTEMS ARCHITECTS The architects still have a role to play. For example, they must coordinate the remediation, renovation, or replacement of those components that have high reusability, that is, the infrastructure components. These components fall into three categories:

• foundational components, such as those for communications networks, which IT staffs must implement robustly for the architecture to succeed; • common tools, which every project group must use to ensure consistency and commonality; and • scaffolding components, which serve as a bridge from the old architecture to the new.

E

nterprise transition and implementation planning lead to a more realistic and achievable schedule.The transition and implementation planning processes produce a more realistic and achievable schedule because the schedule reflects both top-down objectives and bottomup realism and buy-in.They help senior systems architects focus on progress and high-risk issues by providing substantive information to support informed decisions without poring through raw data. This two-pronged approach supports project management accountability and flexibility. Individual project managers do not usually perceive this approach as threatening, because the implementation plan adds value without micromanaging. Project managers are accountable for meeting their commitments but control the project management processes and tools. This approach unmasks unrealistic planning assumptions and gaps early. Clearly defined assumptions, roles, and responsibilities avoid gaps and misunderstandings. Realizations such as, “I thought your project was doing that!” can spell disaster if discovered too late to take corrective action. Be aware that resistance to this approach can alienate people and disrupt projects. Early team building with project managers and stakeholders can help prevent disruptions and ensure that all stakeholders reach a consensus, especially on intersystem interactions. ■

Frank J. Armour is an internationally recognized, independent IT consultant specializing in system architecting, requirements engineering, and object-oriented systems analysis and design. He is also an adjunct professor for the Management of Global Information Technology program at the Kogol School of Business,American University. Contact him at [email protected].

Stephen H. Kaisler is the director of systems architecture at the Office of the Sergeant of Arms and Technology Advisor to the Sergeant At Arms, US Senate. He is also an adjunct professor of computer science in the School of Engineering and Applied Science at George Washington University. Contact him at [email protected]. November ❘ December 2001 IT Pro

37