MIS2 - Assignment 4 :)

If I were invited by the university president to present my IS (Information System) Plan for the university in which I would really feel flattered for, and to discuss what are the steps to expedite or accelerate the implementation of my said IS (Information System) plan, I would first explain the foundation and grounds of an Information Systems Plan.


Any organization especially the university must be aware of the rationale of an Information System. In almost all the organizations in the world, they spend 5% of their gross income on information systems and their supports. If the corporation has $300-700 million dollar every year, $15,000,000 to $35,000,000 will be spent for the IS support which makes us think how on earth will our university have this lots of money just for an IS support, excluding of course the planning stage but then even planning costs a lot especially in a government organization.


Even though an information system costs from $1,000,000 to $10,000,000, and even through most chief information
officers (CIOs) can specify exactly how much money is being spent for hardware, software, and staff, CIOs cannot however state with any degree of certainty why one system is being done this year versus next, why it is being done ahead of another, or finally, why it is being done at all. I am referring to a million dollar company. But in case of USEP, I still find it hard to propose or much especially to have IS plan because of this one factor, BUDGET. I am sure that the university won’t spend lots and lots of millions just for an innovation. Well, it’s just what I think though.
Too many half-billion dollar organizations have only a vague notion of the names and interactions of the existing and under development information systems. Whenever they need to know, a meeting is held among the critical few, an inventory is taken, interactions confirmed, and accomplishment schedules are updated.


Rather than having centralized, long-range planning and management activities that address these problems, today's business units are using readily available tools to design and build ad hoc stop-gap solutions. These ad hoc systems not only do not interconnect, support common semantics, or provide synchronized views of critical corporate policy, they are soon to form the almost impossible to comprehend confusion of systems and data from which systems order and semantic harmony must spring. Not only has the computing landscape become profoundly different and more difficult to comprehend, the need for just the right--and correct--information at just the right time is escalating. Late or wrong information is worse than no information. Information systems managers need a model of their information systems environment. A model that is malleable. As new requirements are discovered, budgets modified, new hardware/software introduced, this model must be such that it can reconstitute the information systems plan in a timely and efficient manner.


There are five distinct characteristics of a QUALITY ISP (information Systems Plan) as according to Whitemarsh. A quality ISP must exhibit five distinct characteristics before it is useful. These five are presented in the table that follows.

Timely. The ISP must be timely. An ISP that is created long after it is needed is useless. In almost all cases, it makes no sense to take longer to plan work than to perform the work planned.

Useable. The ISP must be useable. It must be so for all the projects as well as for each project. The ISP should exist in sections that once adopted can be parceled out to project managers and immediately started.

Maintainable. The ISP should be maintainable. New business opportunities, new computers, business mergers, etc. all affect the ISP. The ISP must support quick changes to the estimates, technologies employed, and possibly even to the fundamental project sequences. Once these changes are accomplished, the new ISP should be just a few computer program executions away.

Quality. While the ISP must be a quality product, no ISP is ever perfect on the first try. As the ISP is executed, the metrics employed to derive the individual project estimates become refined as a consequence of new hardware technologies, code generators, techniques, or faster working staff. As these changes occur, their effects should be installable into the data that supports ISP computation. In short, the ISP is a living document. It should be updated with every technology event, and certainly no less often than quarterly.

Reproducible. The ISP must be reproducible. That is, when its development activities are performed by any other staff, the ISP produced should essentially be the same. The ISP should not significantly vary by staff assigned.
Whenever a proposal for the development of an ISP (Information systems Plan) is created it must be assessed against these five characteristics. If any fail or not addressed in an optimum way, the entire set of funds for the development of an ISP (Information systems Plan) is risked.


It is very difficult to obtain consensus on a functional decomposition for any one application, much less across all the information systems within the entire corporation. That is because functional analysis requires identification and codification of how activities are performed. In short, the codification of style. This type of analysis leads to conflicts, power struggles, and endless nit-picking. In the end, nobody likes the results. Once, or if ever completed, both IBM and Martin use the resulting ISP as a foundation for identifying information systems. Building the ISP on top of such a foundation of discord cannot possibly result in stable, enduring information systems.


Finklestein's methodology requires the development of a fifth-normal form data model for the entire enterprise. Such an extraordinarily detailed effort certainly embraces three to five thousand entities, all the appropriate attributes, full definitions for entities and attributes, and a full exposition of every relationship among all entities. While development of such a edifice is a valuable final shrine once all the identified information systems have been implemented, it is totally unnecessary for the ISP.


Whitemarsh’s ISP: A Difference in Kind
Whitemarsh’s ISP approach was built directly on the strengths and designed-out the weaknesses of the three traditional approaches. The Whitemarsh approach employs:

! A mission based foundation for the ISP rather than the extremely politically charged function modeling.
! A data driven approach for the formulation of all databases, but only at a high level. That is, database objects.
! The Whitemarsh metabase to store, evolve, report and analyze all collected analysis products.
! Project, deliverable, and metric templates to make project estimation accurate and reproducible.
! Ron Ross’s interrelated resource life-cycles as a lattice upon which all ISP proposed projects are cast.


As a consequence of this difference in kind, the Whitemarsh ISP (Information Systems Plan) exhibits these characteristics:

Timely - Creation of the Whitemarsh ISP is timely because it can be created in less than three staff years. This is an order of magnitude less than IBM’s BSP, Martin’s SDP, or Finkelstein’s SMP. The time is even less if components already exist.

Useable - The Whitemarsh ISP enables its users to make both strategic and tactical decisions regarding business information system and database project sequencing based squarely on business fundamentals.

Maintainable - The Whitemarsh ISP is maintainable because it mainly uses metadata
already essential for enterprise database. Metadata that should be readily
available in the metabase.

High Quality – The Whitemarsh ISP is a quality product because it is accomplished through common-sense-based techniques that have been proven over 20+ years.

Reproducible - The Whitemarsh ISP is reproducible because at each review, the resources can be re-examined, new technology set into place, basic RLC precedence vectors re-cast, and then the whole plan regenerated.


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.

The following steps are involved in ISP development (Whitemarsh):

1.Create the mission model
2.Develop a high-level data model
3.Create the resource life cycles (RLC) and their nodes
4.Allocate precedence vectors among RLC nodes
5.Allocate existing information systems and databases to the RLC nodes
6.Allocate standard work break down structures (WBS) to each RLC node
7.Load resources into each WBS node
8.Schedule the RLC nodes through a project management package.
9.Produce and review of the ISP
10.Execute and adjust the ISP through time.

CREATE MISSION MODEL. Missions and mission descriptions are represented through hierarchically composed text. They are natural and are devoid of the effects from organizational structure stylistic effects. Missions from enterprises from the same “line of business” are very similar. In contrast, their
function models may be quite different because of effects imposed by management styles and
organizational structures. Simply stated, mission descriptions are goal and objective oriented and
are best seen as characterizations of the idealized end-results, without any regard for “who and
how.”

For many organizations, the mission description document often represents the first
overall statement of their raison d’etre. The table that follows contains the overall mission
description of the mythical Systems Engineering Corporation, and then the subordinate mission
description for its human resources mission.

It is important to distinguish between missions and functions. At first, missions and
functions look very much alike. However they are not. The following table illustrates their key
differences.
-----------------------------------------------------------------------------------------------------------------
Missions are descriptions of the characteristics of the end result. Missions are noun-based
sentences
Functions are descriptions of how to accomplish an end result. Functions are verb-based
Sentences
-----------------------------------------------------------------------------------------------------------------
Missions are a-political. They are devoid of “who and how.” There should only be ONE
mission description for a mission.
Function hierarchies are commonly tainted by organizations and styles. There can be any
number of equivalent versions of a given function.
-----------------------------------------------------------------------------------------------------------------
Databases and Business Information Systems are based on missions
“Human” activities and organizations are based on business functions
When you “Business Process Re-engineering (BPR)” functions you still have the same
business.
When you “BPR” missions you have a different business.
-----------------------------------------------------------------------------------------------------------------
Mission descriptions are strategic and long range
Functions are tactical to operational, and medium to short range, and are organizationally
Sensitive
-----------------------------------------------------------------------------------------------------------------


BUILD THE HIGH LEVEL DATA. The high level data model is created in two steps: building database domains, and creating database objects.


It is critical to state that the objective of this step is the high-level data model. The goal is
NOT to create a low level or fully attributed data model. The reasons that only a high-level data
model is needed is straight forward:
- No database projects are being accomplished, hence no detailed data modeling is required
- The goal of the ISP is to identify and resource allocate projects including database
projects and for that goal, entity identification, naming and brief definitions is all that is
required for estimating.

The message is simple: any money or resources expended in developing a detailed data model is
wasted.

CREATE DATABASE DOMAINS. Database domains are created from the “bottom” leaves of the mission description texts. There are two cases to consider. First, if the mission description’s bottom leaves are very detailed, they can be considered as having being transformed into database domains. That is they will consist of lists of nouns within simple sentences. The other case is that the mission descriptions have been defined to only a few levels, and the lists of nouns that would result from the development of
database domains have yet to be uncovered.

Whenever a database domain describes complex sets of data, multiple levels of the database domain description may be required. These subdomains are expressed as additional paragraphs. A review of these paragraphs clearly show that the text is “noun-intensive.” The “who and how” is clearly missing. That is the way it should be. If the “who and how” were contained in the database domains then they would not be independent of either process or organization.

A series of diagraming techniques created especially for data and the relationships among data is called entity-relationship (ER) diagraming. Within one style of this technique, the entities are drawn as rectangles and the relationships are drawn as diamonds. The name of the relationship is inside the diamond. Another style of ER modeling is to just have named lines between the entities. In this methodology, since the domain of the diagram is data, it is called the database domain diagram.

The purpose of the database domain diagram is not to be precise and exacting but to be comprehensive. The goal is to have the reviewer say, “that's just the right kind of data needed to satisfy the required mission description.”

When all the database domain diagrams are created, siblings are combined. Entities that are named the same are not presumed to be the same. Analysis must show that to be true. If not, one or both of the entities must have their name and definition changed. As the sets of sibling diagrams are merged from lower to higher levels, the quantity of commonly named entities on different diagrams diminishes. Diagram merger becomes optional when the use analysis of a common entity is subject to update (add, delete, or modify) in one diagram and is only referenced (read) in another diagram.

CREATE RESOURCES AND THE RESOURCE LIFE CYCLES (RCL). Missions are the idealized characterizations of end results of the visionary state of the operating enterprise. Database objects, founded squarely on missions are the highlevel declarations of the data required to reflect the achievement of the mission’s vision. 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 aspects of the missions. Each life cycle is composed of RLC nodes.

A mission might be human resource management, where in, the best and most cost effective staff is determined, acquired and managed. A database object squarely based on human resources would be employee. Within the database object, employee, are all the data structures, procedures, integrity constraints, table and database object procedures necessary to “move” the employee database object through its many policy-determined states. A resource might also be named employee, and would set out for the employee resource the life cycle stages that reflect the employee resource’s “journey” through the enterprise. While an enterprise may have 50 to 150 database objects, there are seldom more than 20 resources.

Enterprises build databases and business information systems around the achievement of the life cycle states of its resources. Business information systems execute in support of a particular life cycle stage of a resource (e.g., employee promotion). These information systems cause the databases to change value-state of contained database objects to correctly reflect the resource’s changed state. The state of one or more database objects in the database is the proof that the resource’s state has been achieved. Resources become the lattice work against which database and business information systems are allocated.

ALLOCATE INFORMATION SYSTEMS AND DATABASES TO THE RLC NODES. Once the resource life cycle network has been created, it is stored into the metabase. Once there, its lattice can be employed to attach the databases and business information systems. Databases and their business information systems exist within a data architecture framework.

Most resource life cycle nodes contain at least one original data capture database application. The data from these ODC databases should be pushed to their respective TDSA databases. Once there, various subject area databases pull the data to build the longitudinal and broad subject area databases. It is likely that there is one subject area database for one or more resources. Data from the subject area databases, also called operational data stores by Bill Inmon, is again pulled to create one or more data warehouse databases. Most databases employ one or more reference data tables as standard semantics for selection, control-breaks and printing.

ALLOCATE STANDARD WORK BREAK DOWN (WBD) STRUCTURES TO EACH INFORMATION SYSTEMS AND DATABASE PROJECTS. The key reason for having a well engineered check list for identifying the types of work involved in either a database or business information system project is the ability to then used canned work breakdown structures (WBS). When these WBSs are coupled with experience-honed metrics that are embedded in a project management system that “self-learns” from on-going projects,
accurate, reliable and repeatable project plans result.

The figure below presents a very high level view of how project management and the projects associated with RLC nodes are interrelated. In actuality, there are many more tables within the Whitemarsh project management software. But, from this perspective, when the assessment checklist is compiled, the specific WBSs that are applicable are selected from the project template table.
The five distinct classes of projects are:
! Administration and management
! Specification
! Implementation
! Operation and maintenance
! Multiple category

LOAD RESOURCES INTO EACH PROJECT. Once the WBS is selected, the WBS list and associated deliverables and metrics are automatically brought into the project. When the quantities for each deliverable type is computed, then the overall gross hours estimate for the project is created.

The gross hours estimate is then finalized (either upwards or downwards) by the selection of work environment factors (e.g., nobody even knows who the users are (that’s a bad work environment factor)), and also by the specific persons assigned who have varying levels of capabilities in certain experience levels (e.g., someone is assigned to create the data model who doesn’t yet even know the meaning of the term, “ER diagram”). That’s a bad staffing factor.

The value in having highly engineered work environment and staffing experience factors that adjust the gross hours is that project managers can then relay back to management the exact reasons why a project will cost more or less than another project of even the same construct and size.

The resources are then exported to a text file that is able to loaded into a project management system such as Microsoft Project. This is necessary because the purpose of the Whitemarsh project management system is to support the planning of projects on an enterprise wide basis rather than the scheduling of individual projects.

SCHEDULE THROUGH A PROJECT MANAGEMENT PACKAGE. Project management systems like Microsoft Project, Welcom’s Open Plan Professional, or Primavera’s P3e all require PERT (activity network charts) to effectively schedule an entire RLC network of RLC node assigned projects. When WBSs are brought into a project management system, they are treated as selfcontained subprojects within the overall set of RLC node network of projects. The resource life cycles are depicted from their first to last node in a topdown fashion. The precedence vectors are shows from one node of a RLC to another node of a adifferent RLC. Multiple precedence vectors do not exist between resource life cycles.

PRODUCE AND REVIEW THE ISP. When the resource loaded network of projects is scheduled through a project management system, normal results are produced. That is, the enterprise is faced with the requirement for:
! Infinite resources
! Infinite time
! Infinite computer capacity and speed, and
! Zero time allocated by “management” to accomplish all the work.

The ISP produced by this technique is thus no more able to be accomplished on the first pass
than is any other information systems plan. Now, where the Whitemarsh starts to become very
different from other ISPs is that the Whitemarsh ISP is fundamentally data within a database. Because the Whitemarsh ISP is “data,” it can be reported, queried, updated, recalculated, and reprinted any number of times with only reasonable effort.

A second key distinction is that the data that supports the ISP is primarily contributed by and thus supported by management. After all, it is their missions, their database domains, their database objects, their resources, their resource life cycles, and their precedence vectors between the resource life cycles. The only parts that are truly owned by information technology are the proposals for IT projects that transform an “as-is” database or information system to a “to-be” database or information system.


EXECUTE AND ADJUST ISP THROUGH TIME. Enterprises, once they evolve beyond their first round of information systems, find themselves transformed from a project and package mentality to a release mentality. The diagram on the next page illustrates this new continuous flow environment. It is characterized by:
! Multiple, concurrent, but differently scheduled projects against the same subject area
database or warehouse database
! Single-database projects that affect multiple subject area and data warehouse databases
! Projects that develop completely new capabilities, that can assess required changes to
existing capabilities, and that can accommodate a variety of systems generation
alternatives (COTS, package, and custom programming)

The continuous flow environment contains four major sets of activities. The user/client is represented at the top in the small rectangular box. Each of the ellipses represents an activity list to accomplish a specific need. The four basic needs are essentially:
! Need Identification
! Need Assessment
! Design
! Deployment

REFERENCE:
informationsystemsplanning.pdf