Volume 4, Number 1, March 2001
The Relationship Between IT Strategic Planning and Enterprise Architectural Practice
Abstract
This paper reviews IT strategic planning and enterprise architectural practice, and compares these two approaches to the planning and management of the IT infrastructure within an enterprise. The paper concludes that the intent and scope of both approaches is very similar, although the detail of the processes used and the outputs differ. Both approaches could beneficially be used in a complementary fashion, which could result in a new IT planning and management paradigm.
Introduction
The IT sector is going through a period of rapid change, and the rate of change is expected to at least maintain, if not accelerate. Most commentators regard rate of change as a key issue in the sector. The following areas are subject to rapid change:
- New technologies are emerging and old ones are superceded. Many major technologies can have a life expectancy of less than five years.
- Deregulation of the IT sector (particularly the telecommunications industry) in many nations has meant more competition and, therefore, more possible vendors or service providers to choose from.
- Costs in many areas are changing rapidly (normally in a downwards direction, but not always in a uniform nor predictable manner).
- As a result of the above, business options for the provision of IT services have increased. Leasing, contracting and outsourcing have become viable alternatives.
These pressures have resulted in a drive for new approaches to planning and managing IT services. Within the corporate world and, to a certain extent, government organisations, IT strategic planning became pre-eminent, especially in the early 1990s. In the latter half of the 1990s, the concept of enterprise architectures (EA) became prominent in the US Department of Defense; a trend which has flowed on into the US government sector and the international military community.
Some distinct similarities between the two approaches are apparent. This paper reviews these two approaches to IT planning and management and provides a comparison of them.
It strategic planning
In discussing IT strategic planning, it is important from the outset to distinguish between strategic information systems planning and strategic planning for information systems. The former relates to the selection of systems that will give an enterprise a strategic business advantage over its competitors, such as the US Airlines computer-based Sabre reservation system of the 1960s. The latter relates to the long-range planning of all IT systems and services which the organisation will utilise, both for business and administrative applications. The latter term (strategic planning of an enterprise’s IT infrastructure) is the subject of this paper.
The Central Computer and Telecommunications Agency (CCTA) of the UK Treasury denotes the following concerns of IT strategic planning: []
- understanding the aims and objectives of the business,
- establishing the information requirements of the business,
- outlining the systems to provide the information, and determining the role of technology in supporting the information systems,
- agreeing policies and plans to develop and implement the information systems,
- determining the role and use of resources to achieve the information systems required, and
- managing, reviewing and evolving the strategy.
Fundamental to the strategic planning process are the following:
- An inventory of existing services. These should include all IT services, including computer-based information systems, computer networks and other telecommunications services.
- A detailed cost model of each service and a summary model for IT services as a whole. Costs of existing systems, including capital, operating, personnel and maintenance are captured. Any trends should also be captured and monitored.
These requirements provide a baseline for all planning and decision-making activities, and are inherent in most, if not all, IT strategic planning methodologies.
The two most commonly described approaches to IT strategic planning are: the IBM-developed Business Systems Planning (BSP) and the Critical Success Factors (CSF).
- BSP is described as “a general purpose methodology for information systems planning”. [] It revolves around a translation of a business strategic plan to an information systems strategic plan. Each element of the business strategic plan is “mapped” to a derived element of the IS strategic plan. For example, “diversify into new businesses” could map to “provide information on new business opportunities” which, in turn, could lead to a requirement for a decision support system which assisted with that objective. BSP can more appropriately be termed an approach rather than a methodology. However, its strength is its translation of business goals and objectives to IT goals and objectives. As such, it is regarded as the “pioneer” IT planning methodology.
- CSF was developed by a research team at MIT’s Sloan School of Management, under John Rockart []. CSF is based on a decision analysis process, in which information needs for each level of management are defined from scratch. The method assumes that each business unit has certain criteria by which its performance will be measured, termed critical success factors. The information requirements to maintain each CSF are defined, and the information types grouped together into delivery by generic information systems. The IS requirements defined in that way are then compared with existing IS. An IS strategic plan can then be developed, to redress any omissions or enhancements required. [] CSF’s strength is, as for BSP, its close mapping of business and IT requirements.
Neither BSP nor CSF can readily be described as methodologies that a team could use to carry out a strategic planning exercise for a particular organisation. They would have to be adapted or developed into a methodology. Most consultancy firms have their own proprietary methodologies, which are based on either CSF or BSP. One open source methodology with which the author is familiar (and which has been successfully used for IT strategic planning in the Defence Forces of Australia, UK and NZ) is the CCTA methodology.
The CCTA methodology is described in detail by [1]. The basic mechanism is a sequence of actions, grouped into the common-sense phases of:
- Where are we now?
- Where do we want to be?
- How do we get there?
The steps include a detailed inventory and cost model of existing systems, a study of business goals and objectives, and a scan of the environment in which the business will operate. Senior management define a vision for where they envisage the organisation will be at the end of the time “window” of the study, both from a business and IT perspective. Options for the provision of systems and services are defined, which are evaluated by a high level steering committee, who decide on the (or a small number of) option(s) to be costed and developed in detail into a strategic plan. The options could include outsourcing, or other innovative approaches to service provision.
A key feature of CCTA is the need for frequent reviews of the strategy to ensure it remains current (or, if not, it is adjusted accordingly). Minor reviews should be carried out annually, with major reviews every 3–4 years. Thus, CCTA is a fairly resource-intensive process. A major strategy study can take upwards of six months for a large organisation. Minor reviews can take several weeks and major reviews of the same order of time as the original study, particularly if the environment has changed significantly.
The only concrete deliverables defined by CCTA are: “… a strategy statement and the associated management and technical policies.” [1] There are normally no detailed migration plans produced as part of the strategy—these are produced as “tactical plans”, after the strategy is approved by senior management.
In summary, the purported main strength of CCTA (or a similar strategic planning methodology) is that it gives a methodical, business-driven approach to selecting, funding, operating and managing IT systems. The production of a comprehensive, top-down IT strategic plan represents a low-risk approach to any organisation’s requirement to manage its IT infrastructure. The existence of a comprehensive strategic plan will allow the organisation to make informed “what if” decisions, such as evaluating the benefits of outsourcing all or part of its IT infrastructure.
Enterprise architectural practice
Enterprise Architectural (EA) practice became prominent in the US DoD in the mid-1990s. The key document which describes the DoD EA framework is []. The US Army has developed an extension of the framework, which is an adaptation for Army use, and is described in the US Army Enterprise Architecture Guidance Document (USAEAGD) []. Non-military approaches to EA also exist; for example that developed by Zachman []. In this paper, however, US DoD practice will mainly be considered, as outlined in [5] and [6].
The underlying vision of the EA process is as follows:
“Architectures are developed to portray the evolution of an IT environment over various points in time, beginning with the baseline, or current situation. Projects to acquire … IT-related capabilities normally are comprised of changes or additions to baseline architecture. Based on priorities and anticipated resource constraints, the projects are integrated into logical groups to form time-phased intermediate architectures. … The architecture envisioned to meet all operational and business requirements is the objective architecture. Migration documents show the progression of architectures from baseline to objective …” [6]
An alternative view of the purpose of EA is as follows:
“Enterprise architecture is a far-reaching concept that comprises the vision, principles and standards that govern the acquisition and deployment of technology. As such, it provides the foundation for detailed data, application and network architectures. An enterprise IT architecture is a key component of a mature IS organisation that enables alignment of business goals, consistent processes and best practice in software reuse.” []
According to US DoD practice, the key elements of an EA are: operational, systems and technical architectures. A summary of the main terminology used [6] is as provided in Table 1.
| Architecture | The structure of components, their interrelationships, and the principles and guidelines governing their design and evolution over time. |
|---|---|
| Operational Architecture (OA) | A description (often graphical) of the operational elements, assigned tasks, and information flows required to accomplish or support a warfighting function. It defines the type of information, the frequency of exchange, and what tasks are supported by these information exchanges. |
| Systems Architecture (SA) | A description, including graphics, of systems and interconnections providing for or supporting warfighting functions. It defines the physical connection, location, and identification of key nodes, circuits, networks, and warfighting platforms and specifies system and component performance parameters. It is constructed to satisfy Operational Architecture (OA) requirements per standards defined in the Technical Architecture (TA). It shows how multiple systems within a subject area link and interoperate and may describe the internal construction or operations of particular systems. |
| Technical Architecture (TA) | A minimal set of rules governing the arrangement, interaction, and interdependence of the parts or elements whose purpose is to ensure that a conformant system satisfies a specified set of requirements. It identifies the services, interfaces, standards, and their relationships. It provides the technical guidelines for implementation of systems on which engineering specifications are based, common building blocks are built, and product lines are developed. |
According to [5], the following are mandatory products for any particular EA iteration:
- Overview and Summary Information,
- Integrated Dictionary,
- High-Level Operational Concept Graphic,
- Operational Node Connectivity Description,
- Operational Information Exchange Matrix,
- System Interface Description, and
- Technical Architecture Profile.
There is a list of twelve optional “supporting products”. The USAEAGD [6] specifies fourteen mandatory products.
The US DoD framework describes the process of defining an EA in terms of the deliverables; that is, the steps to be undertaken to produce the various elements of the operational, systems and technical architectures. It does not describe in any detail the underlying rationale, or analysis which should be undertaken to produce the various deliverables:
“The situation is further complicated because the framework does not provide a process for generating the products. Thus, an organization developing an architecture that is compliant with the C4ISR Framework could be faced with an unbounded amount of effort.”
The Systems Architectures Laboratory at George Mason University has developed a C4ISR Architecture Framework Implementation that includes a process for generating the essential and supporting products for the operational and systems architecture views. The process takes a systems engineering point of view and identifies relationships between the products that lead to a six-step process:
- 1. STEP 0: Problem definition and collection of domain information.
- 2. STEP 1: Operational concept and requirements.
- 3. STEP 2: Functions and organizations.
- 4. STEP 3: Activity model, logical data model, need lines, system nodes, system elements and functions, and task allocation.
- 5. STEP 4: Operational information elements and exchanges, system functionality description, physical data model.
- 6. STEP 5: System information elements and exchanges, local networks/wide area networks (LAN/WANs), system interface descriptions, system performance” [].
Cecere takes a more business-oriented approach, and describes the process in terms of four stages, as follows. [8]
Phase 1—Planning. During this phase, the organization develops a business case for the enterprise IT architecture rollout, defines principles of action and technology standards, and plans the timing of transitions. Phase 1 also identifies "quick hit" opportunities—principles and standards that could be implemented rapidly and would result in immediate, visible benefits. The planning phase involves: creation of an IT inventory; development of a business case for the architecture project; development of an implementation plan that comprised deliverables, milestones, resources required, schedules and costs; and formation of an architecture implementation team.
Phase 2—Initial Migration. During Phase 2, the organisation migrates to the "quick hit" standards identified in Phase 1. One of the objectives of Phase 2, is for the enterprise IT architecture implementation team to convince the organization that the business case for the rollout was valid and that funding and participation should be broadened. That is, commitment by all participants and business units is cemented.
Phase 3—Major Application Migration. The focus for this phase is on moving non-standard production systems such as enterprise software packages, DBMSs and systems development tools to standard ones. The costs of this phase are the highest and most situation-specific.
Phase 4—Post Migration. In this phase, costs are primarily labor-oriented, associated with maintaining the architecture when companies purchase consulting and/or advisory help to supplement internal expertise. Typically, with the migration complete, the benefits of Phase 4 dwarf those costs.
However, as with the US DoD C4ISR architecture documentation, there is little description of analytical processes or supporting rationale underpinning these phases, particularly the planning phase.
In relation to US DoD architectural practice, [5] states:
“It is important to note the difference between an architecture description and an architecture implementation … an architecture description is a representation or blueprint of a … configuration of resources, rules and relationship. The [C4ISR Architectural] Framework does not address this blueprint-to-implementation transformation process.” [5]
The USAEAGD states that: “The architecture products may also be used to choose between architecture alternatives, based on cost … Therefore … the data collected while designing the architecture must include fiscal data.” [6]. However, there is no elaboration of this statement into the development of a business case, or fiscally based options, as is integral to CCTA.
This lack of a business focus, or even comprehensive fiscal modeling, during the creation of architectural descriptions leads to potential difficulties, such as:
- As resources are always likely to be constrained, how are the objective systems and technical architectures determined? (It would be unrealistic to decide these without thorough cost/benefit analysis.)
- How can strategic applications of IT (that is those which give a distinct business advantage) be identified and evaluated?
The lack of a business focus somewhat contradicts the opening paragraph of [5], which states that: “The application of the Framework will enable architectures to contribute most effectively to building … cost effective military systems.” [5]
There is also no indication in [5] or [6] of any specific time window on which the objective architecture should be based. With rapid advances in technology, it may not be possible to specify a firm objective architecture more than 3–5 years ahead.
Comparison between it strategic planning and ea practice
Even from a cursory consideration of the above stand-alone descriptions of the two approaches, there are similarities apparent. A more detailed comparison is as follows.
Similarities
- Basic Intent/Vision: Both are high-level approaches, intended to realise a rational, affordable IT infrastructure which is consistent with business strategy and goals.
- Both include a baseline summary of existing IT infrastructure, and an objective architecture (“where do we want to be?”).
- Both establish the information requirements of the business and determine the systems required, to provide and manage the information.
- Both include a fiscal dimension (however, this is much more heavily emphasized in IT strategic planning).
- Both produce plans/architectures that are dynamic, and need to be reviewed regularly.
- Both can be used by, or adapted to, any type or size of organisation that uses IT.
Differences
Table 2 lists the main differences.
Summary
In summary, there are distinct similarities in the objectives and scope of both approaches. The main difference is in the apparent process-orientation of IT strategic planning, compared with the product-orientation of EA practice. Both have been demonstrated in practice to produce valid results, assisting enterprises to optimise their IT infrastructures. The two approaches can be viewed as complementary, rather than mutually exclusive, and there could well be significant benefits in combining elements of both, to produce a new paradigm in IT planning and management.
In particular, the following steps of the CCTA methodology could address the lack of process inherent in EA practice: that is, provide the basis of a business-oriented process to define an objective architecture:
Define a business vision statement.
Define an IT vision statement to support the business vision.
Determine broad options for achievement of the IT vision and prepare cost/benefit models for each.
Seek senior management guidance on the (or a small number of) preferred option(s) for further development and consideration.
After selection of a single option, prepare and present the chosen strategy by means of a report which details the process and rationale for strategy selection in narrative form, and which includes the EA deliverables as attachments.
Conclusions
The high-level intent of the two approaches is virtually identical, and the general scope and factors considered during the respective processes are very similar. However, the major difference is that IT strategic planning tends to be process-oriented, with relatively little specification of the deliverables, whereas EA is rather the opposite. US DoD EA practice, as espoused in the C4ISR Architecture Framework, does not attempt to define any business processes or models which could be used to derive cost effective objective architectures. The use of IT strategic planning methods could remedy this shortfall.
It is therefore concluded that the two approaches could be used in a complementary fashion—that is, adopting the strengths of both, and eliminating potential weaknesses. In particular, IT strategic planning methods could be used to optimise the processes used to define an objective architecture for an enterprise. This could result in a new IT planning and management paradigm.
References
[1] CCTA publication, Guidelines for Directing Information Systems Strategy, HM Treasury, London, 1988.
[2] C. Wiseman, Strategic Information Systems, Irwin, Homewood, Illinois, 1988.
[3] J. Rockart, “Chief Executives Define their own Data Needs”, Harvard Business Review, May-June 1973.
[4] N. Ahituv and S. Neumann, Principles of Information Systems for Management, Wm C. Brown, Dubuque, Iowa, 1990.
[5] US DoD, Command, Control, Communications, Computers, Intelligence, Surveillance and Reconnaissance (C4ISR) Architecture Framework, Version 2, 18 December 1997, available from: URL http://www.c3i.osd.mil/org/ cio/i3/AWG_Digital_Library/index.htm.
[6] US Department of the Army, Army Enterprise Architecture Guidance Document, 23 December 1998, downloaded from URL http://www.army.mil, approx. March 1999.
[7] J. Zachman, “Concepts of the Framework for Enterprise Architecture”, 1997, available from URL http://www. ozemail.com.au/~visible/papers/zachman3.htm.
[8] M. Cecere, “Architecting Architecture”, CIO Magazine, 15 April 1998, available from URL http://www.cio.com.
[9] M. Barbacci and W. Wood, Architecture Tradeoff Analyses of C4ISR Products, Software Engineering Institute, Carnegie Mellon University, CMU/SEI-99-TR-014 ESC-TR-99-014, July 1999, available from URL http://www.sei.cmu.edu /publications/documents/99.reports/99tr014/99tr014chap02.html.