BIS4430 Web-based Information Systems Management. UNIT 05 Information Systems Strategy Planning [Version 1.0, GA, July 2008]

Transcription

1 BIS4430 Web-based Information Systems Management UNIT 05 Information Systems Strategy Planning [Version 1.0, GA, July 2008] Context In the preceding units, we have introduced the need for the strategic planning of information Systems and the basic planning process. make up a strategic view of IS within the enterprise. There are in fact three major strategies, or components of a strategy, centred on systems, technology, and management. Each one of these components is now examined in more detail, together with the architectures that may be found in each component. Objectives At the end of this unit you will be able to: Describe the three individual components of an enterprise IS strategy. Explain the major constructs found within each strategic component and their role in the IS development cycle. Explain how architectures can be developed using different techniques and apply techniques to develop specific architectural views. Understand the importance of each architectural view in modelling an enterprise s views of Information Systems. Required Study Time 8 hours (excluding tutorial time) Reading material and resources

2 1. Kenneth C Laudon and Jane P Laudon, (2006), 'Management Information Systems, Managing the Digital Firm, 9 th Edition, Pearson Education, ISBN , Chapter 1 and Chapter 3 pages Efraim Turban, Dorothy Leidner, Ephraim McLean, and James Wetherbe, (2006), 'Information Technology for Management, Transforming Organizations in the Digital Economy', 5 th Edition, John Wiley & Sons, ISBN , Chapter 1, page 336. Supplementary texts (available at LSC): 1. Information Systems A Managerial Perspective(3 rd edition), S.Alter, Addison Wesley, 1999(ISBN ) 2. Organisations and the Business Environment, D.J.Cambell, Butterworth- Heinemann, 1997 (ISBN ) Online Resources: While you may find some information about modelling techniques and development methods on the web, the core texts and the learning materials in this unit should be sufficient.

3 TABLE OF CONTENTS Context... 1 Objectives... 1 Required Study Time... 1 Reading material and resources... 1 Supplementary texts (available at LSC):... 2 STRATEGIC LEVELS AND LINKAGES... 4 OVERVIEW OF STRATEGY COMPONENTS... 6 IS STRATEGY... 7 IT STRATEGY IM STRATEGY THE ROLE OF ARCHITECTURES IN THE SYSTEMS DEVELOPMENT LIFE CYCLE DISCUSSION TOPICS REFLECTION ON LEARNING EXPERIENCE END OF UNIT REVIEW... 22

4 STRATEGIC LEVELS AND LINKAGES IT is now a strategic resource. Therefore we need to develop a strategic orientation for our technology and systems. In the past system development projects have been based on an analysis of the present system to determine equipment needs and new projects. No real attempt has been made to focus development towards supporting the goals of the organisation, or providing our IS/IT group with a direct link into corporate planning. When we attempt to exploit Information Technology (IT) for some strategic advantage, we can clearly see the Technology-Strategy connection. IT has to be seen as a strategic resource that must support business strategy. This means that IT has to have a strategic perspective within an organisation. Such strategic perspectives are new to the IT industry. The only way to link the exploitation of IT with the business needs is through linking our business and Information Systems (IS) strategy. BUSINESS STRATEGY INFORMATION TECHNOLOGY INFORMATION STRATEGY Fig. 4 Linking IS and IT strategies with Business Strategy Our architectures then are constructed at a strategic level, and force us to link the formation of business strategy with the strategy for technology and systems. The IT Infrastructure or architecture is our foundation upon which we will build and deliver our IT needs. This infrastructure must be based then on business needs. IT can support business strategy, but it can also create strategic options (Fig. 5). We can safely say then that no business strategy is complete without reference to an IT or

5 IS strategy. IT and IS delivery has to be planned and conceptualised at a strategic level. It is apparent that the information and technology architectures must be of strategic concern. IS SUPPORTED BY CORPORATE STRATEGY IT (HELPS) CREATE Fig. 5 IT/Corporate Strategy Link It seems that IS strategy then is important for many organisations, but is also more complex than it first appears. There are in fact three levels of strategy that we are talking about, not one single strategy. Although we commonly refer to an IS strategy, IS (i.e. the applications we will build) are just part of a much wider strategic view. We often use the acronyms IS and IT as if they are interchangeable, but they are not. They mean different things and cannot be used arbitrarily. We are talking about three distinct themes or levels (Fig. 6): IS are the ends, IT is the means, and IM defines the management aspect. As we learn to separate applications and their delivery so we delineate between what we should do with the technology, which is mainly concerned with aligning IS development with business needs, and how do we do it, which is focussed primarily on IT policies. We have already mentioned in part what we mean by IT strategy and IS strategy. It is also important that our IT resources must be planned, and provided in an orderly and manageable fashion in order to implement the IS strategy. IT needs to be managed, and the IT management style should fit the management style of the organisation. The third part of our strategy involves putting the management into IT. Lucas and Turner contend that the effective control of IT is a pre-requisite to the integration of technology with strategy. IM strategy therefore defines the roles, structures, controls and policies, procedures, of IT activities within an organisation.

6 IS STRATEGY APPLICATIONS WHAT? HOW? IT STRATEGY DELIVERY WHEREFORE? IM STRATEGY MANAGEMENT Fig. 6 The three components of strategy OVERVIEW OF STRATEGY COMPONENTS The confusion exists because so many different parties (organisations, business managers and the technical specialists themselves) use the terminology for their own purposes. Information Systems are the ends and Information Technology is the means. Thinking in terms of applications and delivery can reinforce this difference. The applications we build, and therefore what we want to do with technology, is termed the Information Systems Strategy. This can be contrasted with how we accomplish things (or build our systems) using technology, which is termed the Information Technology Strategy. Although these two levels are not entirely separable, they are distinct and different. Information Systems Strategy is concerned with IS development, whilst IT Strategy with technology policies and standards. The last level, Information Management Strategy is concerned with the effective management control of both IT and IS within an organisation. In Fig 6. above the IS strategy is described as what as in what we are going to build. The IT strategy is how we are going to build or deliver it. Finally the IM strategy is more wherefore, as in who is going to do it, where are they going to do it/be located, which way, etc.

7 Each one of these strategies is considered further in the next unit. IS STRATEGY The IS strategy is our view of the IS or applications we intend to develop. It is used to ensure that these applications are aligned with the needs of the business. It is also important because it gives us a focus on the IS within an enterprise. As has been mentioned earlier, there is a need for this overall or co-ordinating view. From the earlier work in architectures, you know that the view of IS is developed from defining the activities and information needs of an enterprise. It is the clustering or grouping of related content (business activities and information needs) that suggest areas where IS may exist. The IS strategy is a directional plan essentially defining what the organisation intends to do with technology. Fig. 2 below illustrates its main emphasis. It is a business-oriented view focusing on business needs. It is demand led, and concerned with either supporting business strategies or creating new strategic opportunities. The majority of large organisations began to formulate IS strategies in the 1980 s. Although there are several reasons why an organisation should embark on formulating an IS strategy, such as competitive advantage or revamping existing resources, this section focuses more on the alignment of IS/IT investment with the business needs outlined in the business strategy. For many years system development projects have been decided by the IT specialists, without a strategic view, and have failed to deliver the anticipated benefits to the organisations they serve. IS STRATEGY DIVISION / FUNCTION BASED DEMAND ORIENTED BUSINESS FOCUSED Fig.2 Overview of IS strategy

8 The IS strategy focuses effort on aligning IS development with the business needs, and taking strategic control of the systems development process. It must be formulated therefore at the same level as the business strategy. This is referred to as the level of the strategic business unit (SBU). There may be several SBU s in an organisation and therefore several IS strategies representing different unit needs. There may also be a corporate IS strategy focusing on group needs across the enterprise. IS strategies contain several key ingredients. They will initially define the essential and tactical short-term applications, as well as defining applications based around more medium-term business-driven needs, and longer-term visionary investments. Different types of IS will be required by organisations, including mandatory (e.g. legal) requirements, strategic moves (e.g. supporting or creating strategic options), infrastructure investments (e.g. common databases), as well as the expected migration to new technologies, maintenance and enhancements of existing systems. The IS strategy consists of 2 main components: The Information Architecture and the Application Development Portfolio.

9 INFORMATION ARCHITECTURE The Information Architecture is developed to obtain a business view that will drive the identification and development of a set of integrated applications. The Information Architecture then defines both the business activities (or functions) performed by the business, and the information needed by these activities. It also defines the (information) dependencies between these activities, and the involvement or usage of data in activities. These views of what are essentially data and process may well come from the business strategy. If not, models of the business which capture these aspects will have to be formulated as part of the IS strategy building. Data Modelling The modelling of data or information is a well-practised technique, but has traditionally been relegated to analysis and database design. However, we can utilise the same concepts to define a high-level view of business data. This is a view free from technical references such as keys and data types, and ensures a high level framework or architecture that supports the corresponding high level view of business activities. Fig. 3 shows an example of a typical data model.

10 PICKING ORDER PROMOTION MATERIAL SUPPLIER INITIATED BY OFFERS PAID BY CUSTOMER ORDER ORDERS PRODUCT PAYMENT STORED AS EXECUTED BY STOCKED AS CUSTOMER DELIVERY CONSISTS OF PRODUCT STOCK INSERTS SUPPLIER DELIVERY LOCATED AT WAREHOUSE PLACES INTERNAL TRANSPORT Fig. 3. A typical data model Different notations do exist, but the concepts behind the abstraction are essentially the same. Activity Modelling There are several techniques available to define the business activities of an organisation. Business Process Modelling techniques have been used for many years. The sample functional hierarchy, shown in fig. 4 illustrates a set of business activities. As with the data model, we are not interested in a detailed view of the activities, or how they are accomplished. It is a view of what the activities are. Additional complementary techniques can be applied, such as process dependency diagrams, or data flow diagrams (see module BIS4111 for more details on these types of techniques).

11 ROBINSON COMPANY BUSINESS MANAGEMENT PRODUCT MANAGEMENT MARKETING FINANCE INFORMATION MANAGEMENT STRATEGIC PLANNING SUPPLIER MANAGEMENT MARKETING PLANNING FINANCIAL PLANNING INFORMATION FACILITIES PROGRAMME DEVELOPMENT PRODUCT RANGE MANAGEMENT SALES PROMOTION FINANCIAL MANAGEMENT OPERATIONS MGT. BUDGETING PRODUCT DEVELOPMENT SALES PERFORMANCE CASH MANAGEMENT COMMS. MGT. Fig. 4. A sample functional hierarchy Integrating Views As well as models of business activities (process) and information needs (data), we need to develop a view of how these components interact. Fig. 5 below illustrates a simple activity-data matrix. Business 1 * Activities Busines s Data * * Objects * *

12 * * * Fig. 5 Activity - Data matrix By focusing on the involvement of data in activities, we have a good picture of where data will be used. Affinity analysis, as mentioned in the previous unit, groups common elements together. So we attempt to group related activity and data. This results in activities that use the same data being identified. This clustering technique identifies common groups that will eventually be represented by IS. This architecture then is essential in defining the boundaries and content of individual IS, as well as providing a common foundation to aid integration and data sharing. It is the applications identified and defined here that will be further described in the applications development portfolio. THE APPLICATION DEVELOPMENT PORTFOLIO The Application Development Portfolio (ADP) is essentially a wish list of applications development projects. It is a business-related statement of the agreed applications to be developed, and projects to be initiated. It does not focus on the technical detail of sub-systems or interfaces. This level of detail will be held in the IT strategy, covered in the next section. The ADP contains all the IS for potential development. It will contain estimates for resources, timescales and budgets for the individual developments. It also ensures IS

13 development is organised around business priorities only, by concentrating on the priorities of the business strategies supported or created. Each area will contain estimates of spending or resource allocation, and some idea of priorities. Not all areas will have equal priority in timescales or resources. It is essential that it reflects a realistic set of deliverables over time. It is a practical development portfolio, ensuring that only relevant systems are developed, and that resources to projects are efficiently allocated. APPLICATIONS DEVELOPMENT PORTFOLIO EFFECTIVE MGT. AND CONTROL OF SYSTEMS DEVELOPMENT RESOURCES BLUE PRINT FOR DEVELOPMENT OF INTEGRATED SYSTEMS ACROSS ENTERPRISE

14 IT STRATEGY IT strategy is primarily concerned with technology policies and architecture. It focuses on delivery and is the framework within which specialists will build applications and users will use them. Fig. 6. Gives an overview of the main focus. It is a blueprint or schema of the actual building blocks we intend to use to construct and operate our IS. As well as an overall view of technology across the enterprise, it will also contain risk attitudes, technical standards, security levels, etc. Remember that the IT strategy will not only support the business strategy, but may also create strategic options or opportunities. It has thus become a strategic concern, and must be planned accordingly. The actual management of the IT components within an organisation need to be controlled the same as other resources. The view of how we are going to accomplish solutions using technology is contained in this strategy. IT needs to be positioned and managed accordingly. The IT strategy needs to be determined by the specialist IT function and approved by the business / senior management. IT STRATEGY ACTIVITY BASED SUPPLY ORIENTED TECHNOLOGY FOCUSED Fig. 6. Overview of IT strategy The next sections examine the techniques used to help develop an IT strategy, and develop the technical levels of our technology architecture.

15 BUSINESS SYSTEMS ARCHITECTURE The Business Systems Architecture is a framework for the future development of business applications and defines the proposed business systems in terms of functions and the flow of data between them. This architecture is a model of the applications in the enterprise and represents an ideal which could exist at the end of the agreed planning horizon. Inter-dependencies between applications can be shown and it provides a basis for planning future systems development to ensure compatibility between systems and with databases. A sample business systems architecture is shown below (Fig. 7). PRODUCT MANAGEMENT SUPPLIER ORDER PROCESSING OPERATIONS FACILTIES MANAGEMENT CUSTOMER ORDER OPERATIONS GOODS DESPATCH INVENTORY MANAGEMENT Fig. 7. A sample Business Systems Architecture The applications modelled in this architecture will directly correspond with those identified during our interaction modelling in the IS strategy. The applications are the same as those specified in the applications development portfolio.

16 TECHNICAL ARCHITECTURE A technical architecture can then be derived from the business systems architecture. The technical architecture defines the technical facilities for computing, automation and communication. It defines the facilities, and defines the use of facilities by business systems and locations. The IT strategy helps organisations to distinguish between the actual applications and the delivery of these applications. The technical architecture that is developed includes several different technical views. These will include views of computing (hardware and operating system software, preferred machines and vendors, configuration and compatibility), communications (telecommunication networks and links, LAN/WAN, ISDN, OSI, X25), the organisation and control of data assets, and the actual applications themselves (their functions and inter-relationships, interfaces, development methods, etc.). Each one of these elements is important enough to be dealt with separately, but they are all still inter-related. These technical models of an organisation will help to specify and organise the IT infrastructure. Unlike the models produced in IS Strategy, there are no standards for notation or accepted terminology. A sample technical architecture is shown below (Fig. 8.). DBMS ISD - APPLICATIONS CENTRE 3 GEN. LANG. 4 GEN. LANG. GENERAL APPLICATIONS AND DATA REL. DBMS DATA EXTRACT INFORMATION CENTRE DOCUMENT STORAGE AND DISTRIBUTION WORKBENCH ENCYCLOPEDIA WIDE AREA NETWORK LOCAL PROCESSING CENTRES LOCAL APPLICATIONS APPLICATIONS PACKAGES FILE XFER LOCAL AREA NETWORK PROFESSIONAL WORKSTATION OFFICE WORKSTATIONS VDU WORKSTATIONS Fig. 8. A sample technical architecture It does not mention specific products, instead the intention is to define types of technology and how they inter-communicate.

17 IM STRATEGY The IM strategy puts the management into IT. We have already identified that IT is a strategic resource that needs to be managed and controlled just like any other organisational resource. The IM strategy will define the policies and actions (identified from positioning frameworks?). We have stated that effective control of the development process is paramount to integration of technology with the business or corporate strategy. The IM strategy defines the roles and structure of the IS/IT activities within the enterprise. It identifies management controls and responsibilities for IT, together with performance measurements. IM STRATEGY ORGANISATION BASED RELATIONSHIPS ORIENTED MANAGEMENT FOCUSED Fig. 9. Overview of IM strategy Neither the IS or IT strategy7 are sufficient on their own. They need to be managed. This IM strategy is a set of guidelines for managing the IS/IT activities of an organisation. The IM strategy overview is shown in fig. 8. The focus is now on the organisation, structure and management of IS/IT activities. As IT has become a strategic concern, so it needs to be managed as efficiently and effectively as other organisational resources. The power of IT has already been stated in that it can both support and help create strategic options. The IT function, and the associated decision-making, must be brought into the strategic level, away from the specialists. It is so embedded in the modern organisation that a strategic view is essential for management. Issues to be decided include centralisation and de-

18 centralisation of resources and activities, the role and make-up of steering committees to oversee developments, the internal organisation of the IS/IT activities and the position of IS executives in the organisation. IM strategy must also be capable of change. Both business needs (and priorities) and technology will change over time.

19 THE ROLE OF ARCHITECTURES IN THE SYSTEMS DEVELOPMENT LIFE CYCLE The importance of the architectural concepts introduced in the preceding unit is reiterated here, in the light of examining the strategic components. Each architecture has a different view, and each strategy is defined by a number of architectures. These are the blueprints, which define key features relating to the enterprise, the system developments, and the technology. The architectures provide a baseline against which progress can be measured or assessed, illustrate the overall goals and serve as a basis for co-ordination. Each strategy contributes the various architectures that are required for the coordinated development of integrated applications. We can see from fig. 10 that all the architectures contribute in some way to the subsequent system development life cycle, albeit in different phases. Our Information Architecture (data and process views) will be used in the business analysis phase, where the activities and data are defined in much greater detail. This statement of business requirements is sufficiently detailed to allow technical design to proceed. The business systems architecture and the technical architecture provide a major input to the design, build and implementation phases. Being concerned with technical issues, the relate more to the implementation aspect of IT. As would be expected, the IM strategy is relevant to all phases of the systems development life cycle. It provides guidelines for the management of the complete systems development life cycle. INFORMATION STRATEGY PLANNING INFORMATION MANAGEMENT ORGANISATION ORGANISATION DEVELOPMENT INFORMATION ARCHITECTURE BUSINESS SYSTEMS ARCHITECTURE ISP BUSINESS AREA ANALYSIS BUSINESS SYSTEMS DESIGN CONSTRUCTION TECHNICAL ARCHITECTURE INFORMATION TECHNOLOGY DEVELOPMENT Fig. 10 Use of Architectures in the Systems Development Life cycle

20 The concepts of the Zachman framework, explained in the previous unit, are enforced here. We have developed separate architectures for the business process, data and technology. We have also developed essentially the same views (e.g. data) but at differing levels of detail or perspective. Remember the ballpark view serves a very different purpose from the designer s view.

21 Discussion Topics Choose an organisation that you are familiar with. Pick a strategic business unit if your organisation is too large. 1. Develop a simple architectural overview of both business activity and data. 2. Develop a sample IT architecture 3. Construct an organisational chart for the structure of IS/IT activities. Ensure you understand the essential nature of each architectural view. 4. Place the following in a strategic view. Justify your decision. system development methods (e.g. SSADM) IT security practices Business Area Data Model Network protocol standards IS/IT organisational chart Reflection on Learning Experience In your Learning Journal write up your experience of your learning on this unit. Say what you thought was good or bad, what you had difficulty understanding, and how you resolved your problems.

22 On-line End-of-unit Review Questions End of Unit Review Answer the following questions true or false. 1. IT strategy defines the potential applications to be built. False: Applications are held in the IS strategy 2. There are only 2 main views to be covered by a strategy, the IS and IT views. False: there are 3 views. Don t forget the IM (mgt.) 3. The costs and timescale estimates for IS development projects do not need to be considered until detailed systems development takes place. False: cost and time estimates are essential at the strategic level to ensure budgets and timescales are realistic. 4. The IS strategy contains technical details relating to the implementation of IS applications. False: The IS strategy defines the potential applications to built. Technical views are held in the IT strategy. 5. IS have an essential strategic perspective. True: IS/IT can be used to both support and help crea65te strategic options. 6. The IS strategy focuses on the business. True: IS strategy is created at a strategic business unit (SBU) level, and linked with business strategy. 7. The applications development portfolio only contains essential applications. False: The ADP will contain visions and innovations, and defines relevant investment in relevant technology. 8. The architectures developed during strategy formulation contribute directly to the systems development life cycle. True: IS strategy architectures (process and data) contribute mainly to analysis phase. IT strategy (technology) contributes to design and build phases.

23 On-line End-of-unit Review Questions 9. The IM strategy determines the organisational structure and position of IS/IT activities. True: the IM strategy will define the appropriate internal structure and strategy for managing the IS/IT activities of the organisation. 10.Architectures are important to develop a strategic view of IS/IT across an enterprise. True: Architectures are a blueprint for development of integrated systems across the enterprise and allow effective control and management of system development resources.