Sunday, November 21, 2004

Systems Approach

Since I have been apart of technology for the last 22 years and have a great deal of experience in its use, deployment and I work the front lines of business technology daily. I am somewhat constructively critical.

Defining the Systems Approach

The systems approach is a collection of components that work together in order to share information. It is an abstract concept that is defining the way information is shared, stored and processed. It uses for basic functions, input, process, storage and output. These concepts do not correlate with the actual way an information system works. They are simple concepts being conveyed. These are the text book ways.

There are 5 major components of an information system. The provided reading material states that there are 5 major components (hardware, software, stored data, personnel and procedures).

A component is a part of a system that is needed in order for that system to work. The
hardware element is all of things referred to in the text that are used to process, store and transmitted data via some type of medium either wired or wireless.

The software layer is the non tangible logical abstract. It is a series of bits arranged in a manner that information can be manipulated and stored. It is stored in a machine readable format and displayed in a human readable format. This logical layer uses the hardware layer to transmit and receive data.

The reason I do not consider stored data as part of the overall, because it is a hardware device that provides yet one function. It is part of the hardware layer.

The reason I do not consider people as part of the equation is an information system does run without people. People are the users of the system are not a direct component of the system. In order to qualify as a component I used this process; if the component is removed will the system stop? If a person dies the system will still continue to function. People are used to build and maintain the system and users use the system, but the system does not require a human in order to perform its tasks.

I do not consider procedures as a part of the component as that is an element of software. The text has you to believe that it is part of explaining how to use the information system. If that were true then we would spend our entire life understanding how the information system works. A person does not need to know how a watch works in order to tell time. Nor does a person need to understand how an internal combustion engine works in order to drive a car. A person is a user of the watch, not a component of the watch that makes it work. The human procedure component as the text states is a very tiny part that does not hold enough weight to be a component of a system.


Explaining the Different Roles in Systems Development

Having been a systems analyst, a telecommunications analyst and now a certified systems engineer, I can clearly stated that the role called “systems analyst” is an old term used in large companies as a pay grade reference.

It no longer defines or is used as it is stated in the text. For a large company the roles for systems development are broken down in to categories not defined in the text. For big iron mainframe the groups are commonly called datacenter analyst, for server systems they are called systems engineers, for local area networks they are called network engineers, for connectivity they are called telecommunications engineers, for tech support they are called tech support specialist.

The names may vary from company to company, but the roles and areas are much the same and require a small army to support 1,000’s of people. For smaller company they typically depend on outside support and are called system engineers. That is what they do engineer, design, build and maintain information systems.

The text calls the roles just systems analysts, project teams, users and programmers. There is a ton of roles missing from the text. As a result I find it to be misleading for the new person learning about the roles for the first time.


Explaining and Defining Systems Development Life Cycle

The text explains that the system development life cycle (SDLC), yet another executive buzz word, is divided in five main phases.
  • System Planning
  • System Analysis
  • System Design
  • System Implementation
  • System Maintenance

Since there is no certifying agency that controls this definition from company to company the structure of the SDLC may vary greatly. I agree with the author that these are the main items. However the phases of a project most of the time do not correspond to the phases listed in the text. In a perfect world that would be nice. Due to geographical makeup, the organizational makeup, the financial makeup, the leadership skills of the project teams, the impact goals of the company, the presidential directives largely dictate how the phases of a project may break out. So of the items listed above may be in the same phase or span several phases.


Defining and Explaining What Comprises a Feasibility Study

A feasibility analysis is an excellent tool to determine the technical, operational, and economical feasibly of a new system. This is a step/phase that is often not done or not done properly in large companies. If this step was done more, large companies would save a lot more money. There are two scales to a feasibility analyses not mentioned in the text, and that is large scale and small scale. The end result of a feasibility study is to cost justify the project (a.k.a. from the text “cost/benefit analysis”)

On a large scale the analysis is long and can be drawn out. It is sometimes given to a person that does not have the knowledge in other areas of the information systems. They in turn spend a great deal of time collecting information about other systems.

On a small scale a systems engineer can evaluate a project based upon his past experiences and draw conclusions quickly without the formal process as described in the text.


No comments: