Planning for information systems, as for any other system, begins with the identification of needs. In order to be effective, development of any type of computer-based system should be a response to need--whether at the transaction processing level or at the more complex information and support systems levels. Such planning for information systems is much like strategic planning in management. Objectives, priorities, and authorization for information systems projects need to be formalized. The systems development plan should identify specific projects slated for the future, priorities for each project and for resources, general procedures, and constraints for each application area. The plan must be specific enough to enable understanding of each application and to know where it stands in the order of development. Also the plan should be flexible so that priorities can be adjusted if necessary. King (King, 1995) in his recent article has argued that a strategic capability architecture - a flexible and continuously improving infrastructure of organizational capabilities – is the primary basis for a company's sustainable competitive advantage. He has emphasized the need for continuously updating and improving the strategic capabilities architecture.
SISP is the analysis of a corporation’s information and processes using business information models together with the evaluation of risk, current needs and requirements. The result is an action plan showing the desired course of events necessary to align information use and needs with the strategic direction of the company (Battaglia, 1991). The same article emphasizes the need to notethat SISP is a management function and not a technical one. This is consistent with the earlier distinction between the older data processing views and the modern strategic importance view of Information Systems. SISP thus is used to identify the best targets for purchasing and installing new management information systems and help an organization maximize the return on its information technology investment. A portfolio of computer-based applications is identified that will assist an organization in executing its business plans and realize its business goals. There is a growing realization that the application of information technology (IT) to a firm’s strategic activities has been one of the most common and effective ways to improve business performance.
Review of information systems planning models
Existing planning models can be broadly classified into impact and alignment models (Vitale et al., 1986). Impact models focus on the potential impact of information technology on organizational tasks and processes and use this as the basis to identify opportunities for deploying information systems. Alignment models, on the other hand, focus on aligning the information system’s plans and priorities with organizational strategy and business goals.
Michael Porter’s value chain analysis is by far the most widely used impact model.
According to Porter, ‘‘every firm is a collection of activities that are performed to design, produce, market, deliver, and support its product’’. These activities can be represented using a value chain. Value chain analysis helps in identifying key value-adding processes that could be made more effective using information technology. As a planning methodology, value chain analysis is too abstract as it does not provide specific guidelines for designing an information architecture, nor does it provide guidelines for systems development and implementation (Porter and Millar, 1985).Moreover, over the past year, there has been a strategic shift from thinking about value chains to value hubs where the ‘‘linear’’ value chain perspective has evolved to a ‘‘hub-centric’’ model, i.e. emarketplaces. This shift in thinking has been largely driven by two factors: the competitive pressures to respond to a direct selling strategy initiated by companies like Dell, and the maturation of the Internet and related technologies. These changes limit the applicability of the original value chain model for information systems planning for e-business.
Popular alignment methodologies include critical success factors, business systems planning (BSP) from IBM, strategic systems planning, information engineering (Martin, 1989) and method/1. Critical success factors (Rockart, 1979) methodology focuses on identifying key information needs of senior executives and building information systems around those key needs. The emphasis on senior management’s information requirements is based on an organizational control model of critical decisions being made by informed executives. However, the control in e-business is more diffused, autonomous and often occurs outside the organization. This reduces the usefulness of this methodology for EBIS architecture planning.
BSP combines top-down planning with bottom-up implementation and focuses on a firm’s business processes to derive data needs and classes. Similarly, strategic systems planning methodology stresses functional area analysis to identify the data architecture, which is then used to design information systems. Information engineering provides techniques for building enterprise, data, and process models. These models are combined to form a comprehensive knowledge base that is used to create and maintain information systems.
Experience of organizations suggests that these methodologies tend to be too detailed, time-consuming, and expensive. The roots of these methodologies can be traced to systems development practices of the 1980s. Since then new paradigms such as component based development have come into use. These paradigms place less emphasis on building applications from scratch and stress a factory approach of assembling pre-packaged components to create application systems. Hence, organizations often find methodologies such as BSP too rigid and unsuitable for the highly compressed development cycle times that prevail in e-business applications development. Moreover, EBIS planning requires addressing how diverse systems and platforms will be integrated to meet organizational requirements. The alignment methodologies fail to explicitly address such integration issues because they are from an era when organizations created their own information systems and cross-platform integration was not a primary need.
The ISP Steps
The information systems plan project determines the sequence for implementing specific information systems. The goal of the strategy is to deliver the most valuable business information at the earliest time possible in the most cost-effective manner.
The end product of the information systems project is an information systems plan (ISP).
Once deployed, the information systems department can implement the plan with confidence that they are doing the correct information systems project at the right time and in the right sequence. The focus of the ISP is not one information system but the entire suite of information systems for the enterprise. Once developed, each identified information system is seen in context with all other information systems within the enterprise.
Information Systems Plan Development Steps
1.) Create the mission model
2.) Develop a high-level data model- The high-level data model is an Entity Relationship diagram created to meet the data needs of the mission descriptions.
3.) Create the resource life cycles (RLC) and their nodes- Resources are drawn from both the mission descriptions and the high level data model. Resources and their life cycles are the names, descriptions and life cycles of the critical assets of the enterprise, which, when exercised achieve one or more aspect of the missions.
4.) Allocate precedence vectors among RLC nodes- Tied together into a enablement network, the resulting resource life cycle network forms a framework of enterprises assets that represent an order and set of inter-resource relationships.
5.) Allocate existing information systems and databases to the RLC nodes.
6.) Allocate standard work break down structures (WBS) to each RLC node- Employing WBS and metrics from a comprehensive methodology supports project management standardization, repeatability, and self-learning.
7.) Load resources into each WBS node- Once the resources are determined, these are loaded into the project management meta entities of the meta data repository, that is, metrics, project, work plan and deliverables.
8.) Schedule the RLC nodes through a project management- The entire suite of projects is then scheduled on an enterprise-wide basis.
9.) Produce and review of the ISP- The scheduled result is predicable: Too long, too costly, and too ambitious. At that point, the real work starts: paring down the suite of projects to a realistic set within time and budget.
10.) Execute and adjust the ISP through time- As the ISP is set into execution, technology changes occur that affect resource loadings. In this case, only steps 6-9 need to be repeated.
FOUR STEPS TO IMPLEMENTATION
The adoption and implementation of the proposed approach to complying with regulation requirements consists of four steps. Activities in these four steps can be easily incorporated into the Software Development Life Cycle (SDLC) currently in use by the organization. “Information System Life Cycle Phases” is a model that demonstrates integrating regulation requirements into a popular SDLC.
1. Discovery and Identification Specific regulation requirements relevant to information systems should be documented. A current risk survey report may be used if available.
Identification and classification of binding enterprise regulations, standards, and frameworks should be included in a dictionary of terms and definitions. This dictionary should be the basis for a common language among all the organizational units in the enterprise that are involved in implementing and sustaining regulatory compliance measures. Existing and planned information systems and the identification of gaps between regulation requirements and their implementation should also be surveyed.
It is possible to have regulation requirements from multiple regulatory agents. Conversely, IT controls that were developed in response to a particular regulation requirement may be applicable to several information systems. One byproduct of this exercise is the identification of duplicate controls that were implemented to remedy regulatory requirements. A list of information systems, their risk classification, and associated controls presents an excellent opportunity to streamline and consolidate the number of IT controls in the organization.
Once IT controls are documented, a logical next step would be to expand the knowledge base by linking relevant policies, procedures, work instructions, forms, process owner information, and system managers. A repository of such information could help reduce the burden and high demand on IT professionals and make the audit process more efficient.
2. Classification Information systems should be classified to facilitate prioritization according to criteria such as:
• The importance of a system to a business process. An existing risk survey report can be used as a source for information system classification and serve as a starting point. Control self-assessment is a popular tool that can be used for establishing information systems classification.
• The impact of the information system on one or more business processes and the risk factors associated with information systems.
• The interdependency with other internal and external information systems.
Once prioritized, a viable work plan for implementing regulation requirements can be developed for the information systems managed by the IT department.
3. Mapping To establish ownership and direct responsibility for each information system in the organization, it is necessary to map information systems. Mapping should identify the following relationships:
• Information system to business process.
• Regulation requirements to organizational unit(s).
• Information system ownership.
• Identification or discovery of “orphan” information systems.
• Identification of multi-owner information systems.
Any identified gaps must be investigated and resolved. Additionally, the mapping information collected in this effort should be well-documented and maintained as an ongoing regulation compliance activity.
4. Development, Testing, Implementation, and Maintenance The development, testing, implementation, and maintenance of regulation requirements include:
• Development of code necessary to satisfy regulation requirements.
• Testing and validation of regulation compliance of information systems developed in-house.
• Validation that all vendor-supplied information systems comply with regulation requirements.
• Testing, validation, and approval of external information systems services compliance with regulation requirements (including software as a service-based (SaaS) systems).
Certification demonstrating regulatory compliance of information systems by all stakeholders is required to authorize systems for production use. During tough economic times and budget cuts, improving business processes is a good way to prepare for the up-turn cycle and for the inevitable wave of new regulations that are sure to hit our shores.
The prevailing best practice of doing more with less applies to internal and IT auditors just as it does to other stakeholders in business enterprises. Internal and IT auditors can add value to their audited parties, in particular, and to business organizations in general, by playing the role of trusted advisor. The primary role of an auditor is to verify compliance; identify risks, control deficiencies, and the effectiveness of existing controls; and produce an audit report for management.
Executive and Adjusting the ISP Through Time
IT projects are accomplished within distinct development environments. The two most common are: discrete project and release. The discrete project environment is typified by completely encapsulated projects accomplished through a water-fall methodology.
In release environments, there are a number of different projects underway by different organizations and staff of varying skill levels. Once a large number of projects are underway, the ability of the enterprise to know about and manage all the different projects degrades rapidly. That is because the project management environment has been transformed from discrete encapsulated projects into a continuous flow process of product or functionality improvements that are released on a set time schedule. The continuous flow process environment is characterized by:
• Multiple, concurrent, but differently scheduled projects against the same enterprise resource
• Single projects that affect multiple enterprise resources
• Projects that develop completely new capabilities, or changes to existing capabilities within enterprise resources
It is precisely because enterprises have transformed themselves from a project to a release environment that information systems plans that can be created, evolved, and maintained on an enterprise-wide basis are essential.
There are four major sets of activities within the continuous flow process environment. The user/client is represented at the top in the small rectangular box. Each of the ellipses represents an activity targeted to a specific need. The four basic needs are:
• Need Identification
• Need Assessment- is a process for determining and addressing needs, or "gaps" between current conditions and desired conditions, often used for improvement projects in education/training, organizations, or communities. In the context of community improvement, it is known as community needs analysis. It involves identifying material problems/deficits/weaknesses and advantages/opportunities/strengths, and evaluating possible solutions that take those qualities into consideration
• Design- is the planning that lays the basis for the making of every object or system. It is also the process or art of defining the architecture, components, modules, interfaces, and data for a system to satisfy specified requirements. One could see it as the application of systems theory to product development. There is some overlap with the disciplines of systems analysis, systems architecture and systems engineering.
• Deployment- The general deployment process consists of several interrelated activities with possible transitions between them. These activities can occur at the producer site or at the consumer site or both. Because every software system is unique, the precise processes or procedures within each activity can hardly be defined. Therefore, "deployment" should be interpreted as a general process that has to be customized according to specific requirements or characteristics.
The box in the center is the meta data repository. Specification and impact analysis is represented through the left two processes. Implementation design and accomplishment is represented by the right two processes. Two key characteristics should be immediately apparent. First, unlike the water-fall approach, the activities do not flow one to the other. They are disjoint. In fact, they may be done by different teams, on different time schedules, and involve different quantities of products under management. In short, these four activities are independent one from the other. Their only interdependence is through the meta data repository.
The second characteristic flows from the first. Because these four activities are independent one from the other, the enterprise evolves by means of releases rather than through whole systems. If it evolved through whole systems, then the four activities would be connected either in a waterfall or a spiral approach, and the enterprise would be evolving through major upgrades to encapsulated functionality within specific business resources. In contrast, the release approach causes coordinated sets of changes to multiple business resources to be placed into production. This causes simultaneous, enterprise-wide capability upgrades across multiple business resources.
Through this continuous-flow process, several unique features are present:
• All four processes are concurrently executing.
• Changes to enterprise resources occur in unison, periodically, and in a very controlled manner.
• The meta data repository is always contains all the enterprise resource specifications: current or planned. Simply put, if an enterprise resource semantic is not within the meta data repository, it is not enterprise policy.
• All changes are planned, scheduled, measured, and subject to auditing, accounting, and traceability.
• All documentation of all types is generated from the meta data repository.
ISP Summary
In summary, any technique employed to achieve an ISP must be accomplishable with less than 3% of the IT budget. Additionally, it must be timely, useable, maintainable, able to be iterated into a quality product, and reproducible. IT organizations, once they have completed their initial set of databases and business information systems will find themselves transformed from a project to a release environment.
The continuous flow environment then becomes the only viable alternative for moving the enterprise forward. It is precisely because of the release environment that enterprise-wide information systems plans that can be created, evolved, and maintained are essential.
References:
http://www.wiscorp.com/ISP_the_bet_your_business_project.pdf
http://web.njit.edu/~jerry/MIS-625/Articles/Pant-Ravichandran-2001.pdf
http://viu.eng.rpi.edu/publications/strpaper.pdf
http://www.theiia.org/intAuditor/itaudit/2009-articles/the-impact-of-regulation-on-information-system-planning/
SISP is the analysis of a corporation’s information and processes using business information models together with the evaluation of risk, current needs and requirements. The result is an action plan showing the desired course of events necessary to align information use and needs with the strategic direction of the company (Battaglia, 1991). The same article emphasizes the need to notethat SISP is a management function and not a technical one. This is consistent with the earlier distinction between the older data processing views and the modern strategic importance view of Information Systems. SISP thus is used to identify the best targets for purchasing and installing new management information systems and help an organization maximize the return on its information technology investment. A portfolio of computer-based applications is identified that will assist an organization in executing its business plans and realize its business goals. There is a growing realization that the application of information technology (IT) to a firm’s strategic activities has been one of the most common and effective ways to improve business performance.
Review of information systems planning models
Existing planning models can be broadly classified into impact and alignment models (Vitale et al., 1986). Impact models focus on the potential impact of information technology on organizational tasks and processes and use this as the basis to identify opportunities for deploying information systems. Alignment models, on the other hand, focus on aligning the information system’s plans and priorities with organizational strategy and business goals.
Michael Porter’s value chain analysis is by far the most widely used impact model.
According to Porter, ‘‘every firm is a collection of activities that are performed to design, produce, market, deliver, and support its product’’. These activities can be represented using a value chain. Value chain analysis helps in identifying key value-adding processes that could be made more effective using information technology. As a planning methodology, value chain analysis is too abstract as it does not provide specific guidelines for designing an information architecture, nor does it provide guidelines for systems development and implementation (Porter and Millar, 1985).Moreover, over the past year, there has been a strategic shift from thinking about value chains to value hubs where the ‘‘linear’’ value chain perspective has evolved to a ‘‘hub-centric’’ model, i.e. emarketplaces. This shift in thinking has been largely driven by two factors: the competitive pressures to respond to a direct selling strategy initiated by companies like Dell, and the maturation of the Internet and related technologies. These changes limit the applicability of the original value chain model for information systems planning for e-business.
Popular alignment methodologies include critical success factors, business systems planning (BSP) from IBM, strategic systems planning, information engineering (Martin, 1989) and method/1. Critical success factors (Rockart, 1979) methodology focuses on identifying key information needs of senior executives and building information systems around those key needs. The emphasis on senior management’s information requirements is based on an organizational control model of critical decisions being made by informed executives. However, the control in e-business is more diffused, autonomous and often occurs outside the organization. This reduces the usefulness of this methodology for EBIS architecture planning.
BSP combines top-down planning with bottom-up implementation and focuses on a firm’s business processes to derive data needs and classes. Similarly, strategic systems planning methodology stresses functional area analysis to identify the data architecture, which is then used to design information systems. Information engineering provides techniques for building enterprise, data, and process models. These models are combined to form a comprehensive knowledge base that is used to create and maintain information systems.
Experience of organizations suggests that these methodologies tend to be too detailed, time-consuming, and expensive. The roots of these methodologies can be traced to systems development practices of the 1980s. Since then new paradigms such as component based development have come into use. These paradigms place less emphasis on building applications from scratch and stress a factory approach of assembling pre-packaged components to create application systems. Hence, organizations often find methodologies such as BSP too rigid and unsuitable for the highly compressed development cycle times that prevail in e-business applications development. Moreover, EBIS planning requires addressing how diverse systems and platforms will be integrated to meet organizational requirements. The alignment methodologies fail to explicitly address such integration issues because they are from an era when organizations created their own information systems and cross-platform integration was not a primary need.
The ISP Steps
The information systems plan project determines the sequence for implementing specific information systems. The goal of the strategy is to deliver the most valuable business information at the earliest time possible in the most cost-effective manner.
The end product of the information systems project is an information systems plan (ISP).
Once deployed, the information systems department can implement the plan with confidence that they are doing the correct information systems project at the right time and in the right sequence. The focus of the ISP is not one information system but the entire suite of information systems for the enterprise. Once developed, each identified information system is seen in context with all other information systems within the enterprise.
Information Systems Plan Development Steps
1.) Create the mission model
2.) Develop a high-level data model- The high-level data model is an Entity Relationship diagram created to meet the data needs of the mission descriptions.
3.) Create the resource life cycles (RLC) and their nodes- Resources are drawn from both the mission descriptions and the high level data model. Resources and their life cycles are the names, descriptions and life cycles of the critical assets of the enterprise, which, when exercised achieve one or more aspect of the missions.
4.) Allocate precedence vectors among RLC nodes- Tied together into a enablement network, the resulting resource life cycle network forms a framework of enterprises assets that represent an order and set of inter-resource relationships.
5.) Allocate existing information systems and databases to the RLC nodes.
6.) Allocate standard work break down structures (WBS) to each RLC node- Employing WBS and metrics from a comprehensive methodology supports project management standardization, repeatability, and self-learning.
7.) Load resources into each WBS node- Once the resources are determined, these are loaded into the project management meta entities of the meta data repository, that is, metrics, project, work plan and deliverables.
8.) Schedule the RLC nodes through a project management- The entire suite of projects is then scheduled on an enterprise-wide basis.
9.) Produce and review of the ISP- The scheduled result is predicable: Too long, too costly, and too ambitious. At that point, the real work starts: paring down the suite of projects to a realistic set within time and budget.
10.) Execute and adjust the ISP through time- As the ISP is set into execution, technology changes occur that affect resource loadings. In this case, only steps 6-9 need to be repeated.
FOUR STEPS TO IMPLEMENTATION
The adoption and implementation of the proposed approach to complying with regulation requirements consists of four steps. Activities in these four steps can be easily incorporated into the Software Development Life Cycle (SDLC) currently in use by the organization. “Information System Life Cycle Phases” is a model that demonstrates integrating regulation requirements into a popular SDLC.
1. Discovery and Identification Specific regulation requirements relevant to information systems should be documented. A current risk survey report may be used if available.
Identification and classification of binding enterprise regulations, standards, and frameworks should be included in a dictionary of terms and definitions. This dictionary should be the basis for a common language among all the organizational units in the enterprise that are involved in implementing and sustaining regulatory compliance measures. Existing and planned information systems and the identification of gaps between regulation requirements and their implementation should also be surveyed.
It is possible to have regulation requirements from multiple regulatory agents. Conversely, IT controls that were developed in response to a particular regulation requirement may be applicable to several information systems. One byproduct of this exercise is the identification of duplicate controls that were implemented to remedy regulatory requirements. A list of information systems, their risk classification, and associated controls presents an excellent opportunity to streamline and consolidate the number of IT controls in the organization.
Once IT controls are documented, a logical next step would be to expand the knowledge base by linking relevant policies, procedures, work instructions, forms, process owner information, and system managers. A repository of such information could help reduce the burden and high demand on IT professionals and make the audit process more efficient.
2. Classification Information systems should be classified to facilitate prioritization according to criteria such as:
• The importance of a system to a business process. An existing risk survey report can be used as a source for information system classification and serve as a starting point. Control self-assessment is a popular tool that can be used for establishing information systems classification.
• The impact of the information system on one or more business processes and the risk factors associated with information systems.
• The interdependency with other internal and external information systems.
Once prioritized, a viable work plan for implementing regulation requirements can be developed for the information systems managed by the IT department.
3. Mapping To establish ownership and direct responsibility for each information system in the organization, it is necessary to map information systems. Mapping should identify the following relationships:
• Information system to business process.
• Regulation requirements to organizational unit(s).
• Information system ownership.
• Identification or discovery of “orphan” information systems.
• Identification of multi-owner information systems.
Any identified gaps must be investigated and resolved. Additionally, the mapping information collected in this effort should be well-documented and maintained as an ongoing regulation compliance activity.
4. Development, Testing, Implementation, and Maintenance The development, testing, implementation, and maintenance of regulation requirements include:
• Development of code necessary to satisfy regulation requirements.
• Testing and validation of regulation compliance of information systems developed in-house.
• Validation that all vendor-supplied information systems comply with regulation requirements.
• Testing, validation, and approval of external information systems services compliance with regulation requirements (including software as a service-based (SaaS) systems).
Certification demonstrating regulatory compliance of information systems by all stakeholders is required to authorize systems for production use. During tough economic times and budget cuts, improving business processes is a good way to prepare for the up-turn cycle and for the inevitable wave of new regulations that are sure to hit our shores.
The prevailing best practice of doing more with less applies to internal and IT auditors just as it does to other stakeholders in business enterprises. Internal and IT auditors can add value to their audited parties, in particular, and to business organizations in general, by playing the role of trusted advisor. The primary role of an auditor is to verify compliance; identify risks, control deficiencies, and the effectiveness of existing controls; and produce an audit report for management.
Executive and Adjusting the ISP Through Time
IT projects are accomplished within distinct development environments. The two most common are: discrete project and release. The discrete project environment is typified by completely encapsulated projects accomplished through a water-fall methodology.
In release environments, there are a number of different projects underway by different organizations and staff of varying skill levels. Once a large number of projects are underway, the ability of the enterprise to know about and manage all the different projects degrades rapidly. That is because the project management environment has been transformed from discrete encapsulated projects into a continuous flow process of product or functionality improvements that are released on a set time schedule. The continuous flow process environment is characterized by:
• Multiple, concurrent, but differently scheduled projects against the same enterprise resource
• Single projects that affect multiple enterprise resources
• Projects that develop completely new capabilities, or changes to existing capabilities within enterprise resources
It is precisely because enterprises have transformed themselves from a project to a release environment that information systems plans that can be created, evolved, and maintained on an enterprise-wide basis are essential.
There are four major sets of activities within the continuous flow process environment. The user/client is represented at the top in the small rectangular box. Each of the ellipses represents an activity targeted to a specific need. The four basic needs are:
• Need Identification
• Need Assessment- is a process for determining and addressing needs, or "gaps" between current conditions and desired conditions, often used for improvement projects in education/training, organizations, or communities. In the context of community improvement, it is known as community needs analysis. It involves identifying material problems/deficits/weaknesses and advantages/opportunities/strengths, and evaluating possible solutions that take those qualities into consideration
• Design- is the planning that lays the basis for the making of every object or system. It is also the process or art of defining the architecture, components, modules, interfaces, and data for a system to satisfy specified requirements. One could see it as the application of systems theory to product development. There is some overlap with the disciplines of systems analysis, systems architecture and systems engineering.
• Deployment- The general deployment process consists of several interrelated activities with possible transitions between them. These activities can occur at the producer site or at the consumer site or both. Because every software system is unique, the precise processes or procedures within each activity can hardly be defined. Therefore, "deployment" should be interpreted as a general process that has to be customized according to specific requirements or characteristics.
The box in the center is the meta data repository. Specification and impact analysis is represented through the left two processes. Implementation design and accomplishment is represented by the right two processes. Two key characteristics should be immediately apparent. First, unlike the water-fall approach, the activities do not flow one to the other. They are disjoint. In fact, they may be done by different teams, on different time schedules, and involve different quantities of products under management. In short, these four activities are independent one from the other. Their only interdependence is through the meta data repository.
The second characteristic flows from the first. Because these four activities are independent one from the other, the enterprise evolves by means of releases rather than through whole systems. If it evolved through whole systems, then the four activities would be connected either in a waterfall or a spiral approach, and the enterprise would be evolving through major upgrades to encapsulated functionality within specific business resources. In contrast, the release approach causes coordinated sets of changes to multiple business resources to be placed into production. This causes simultaneous, enterprise-wide capability upgrades across multiple business resources.
Through this continuous-flow process, several unique features are present:
• All four processes are concurrently executing.
• Changes to enterprise resources occur in unison, periodically, and in a very controlled manner.
• The meta data repository is always contains all the enterprise resource specifications: current or planned. Simply put, if an enterprise resource semantic is not within the meta data repository, it is not enterprise policy.
• All changes are planned, scheduled, measured, and subject to auditing, accounting, and traceability.
• All documentation of all types is generated from the meta data repository.
ISP Summary
In summary, any technique employed to achieve an ISP must be accomplishable with less than 3% of the IT budget. Additionally, it must be timely, useable, maintainable, able to be iterated into a quality product, and reproducible. IT organizations, once they have completed their initial set of databases and business information systems will find themselves transformed from a project to a release environment.
The continuous flow environment then becomes the only viable alternative for moving the enterprise forward. It is precisely because of the release environment that enterprise-wide information systems plans that can be created, evolved, and maintained are essential.
References:
http://www.wiscorp.com/ISP_the_bet_your_business_project.pdf
http://web.njit.edu/~jerry/MIS-625/Articles/Pant-Ravichandran-2001.pdf
http://viu.eng.rpi.edu/publications/strpaper.pdf
http://www.theiia.org/intAuditor/itaudit/2009-articles/the-impact-of-regulation-on-information-system-planning/
0 comments:
Post a Comment