Entries for 'timbryce'

Every now and then I encounter a programmer who adamantly contends you cannot have an information system without some form of computer support. Actually, we've had such systems well before the advent of the computer.

Managers should do some soul-searching; do they really need that information or are they interfering with the responsibilities of others? My advice to managers is simple: Delegate responsibility, hold people accountable, and get out of their way.

The language of systems is no different; No, it is not C++, Java, COBOL, etc., but rather simple English (or whatever your native language happens to be). In the past I have gone into length about the differences between Systems and Software, the two are simply not synonymous. Whereas systems include business processes implemented by human beings, computers and other office equipment, software is simply instructions for the computer to follow. Systems are for people who must also take an active role in its execution. In fact, systems will fail more for the lack of people procedures than they will for well-written computer software.

In a nutshell, a methodology represents a series of steps in a project specifying Who is to perform What, When, Where, Why, and How (aka, "5W+H"), from start to finish. Perhaps the best way to think of a methodology is as a roadmap or an assembly line where a product is developed over a series of work stations.

It seems every now and then someone comes along with a new spin on how to estimate a project, either in its entirety or a portion of it. I have heard a lot of theories over the years, particularly in the Information Technology (I.T.) field where there is a tendency to pull numbers out of a hat, but I've long given up looking for panaceas.

Over the years I have noticed that we, as Americans, seem to possess a knack for attacking the wrong problems which I refer to as the “Rearranging the deck chairs on the Titanic” phenomenon. I see this not only in the corporate world, but in our private lives as well. Instead of addressing the correct problems, we tend to attack symptoms.

Recently, I was watching an episode of "60 Minutes" which discussed the prosecution of a whistle blower at the NSA regarding the development of a major system to be used in the War on Terror, code named "Trailblazer." Although the intentions of the developers may have been good, the project started to spiral out of control almost from the beginning.

"Enterprise Engineering" is a term coined in to reflect the third and final part of the concept of Information Resource Management (IRM) representing a triad of methodologies to design, develop, and control all of the resources needed to support the information requirements of an enterprise, be it a commercial or nonprofit endeavor.

In I.T., are we really spending too much time on "maintenance"?  Within any systems development organization, there are but three types of work effort: new systems development, maintenance, and modification/improvements. A mature development organization will spend approximately 5% of its time on new development, 10% on maintenance, and 85% of its time on modification/improvements.

Regretably, many of today's Systems Analysts are still glorified programmers in sheep's clothing.  I recently came across some job postings under the title, "Systems Analyst," and it occurred to me people still do not know what it means. In the postings I saw things like "seeking a Systems Analyst with 4 - 6 years experience... Candidate must have experience with JAVA and the ATG application framework."

I've never been comfortable with the concept of "Man Hours," not that it's a gender issue, but rather it implies ignorance of how time is used in the work place and fumbles away some simple management concepts needed to run any business, namely accountability and commitment. Actually, I thought the "Man Hour" concept disappeared with the passing of the 20th century, but it appears to be making a comeback.

Systems work is not as hard as you might think. However, we have a tendency in this business to complicate things by changing the vocabulary of systems work and introducing convoluted concepts and techniques, all of which makes it difficult to produce systems in a consistent manner. Consequently, there is a tendency to reinvent the wheel with each systems development project. I believe I owe it to my predecessors and the industry overall to describe basic systems theory, so that people can find the common ground needed to communicate and work. Fortunately, there are only four easy, yet important, concepts to grasp which I will try to define as succinctly as possible.

In the past I have discussed the need to manage data (and all information resources) as a valuable resource; something to be shared and reused in order to eliminate redundancy and promote system integration.  Now, our attention turns to how data should be defined.  Well defined data elements are needed in order to properly design the logical data base as well as developing a suitable physical implementation.

The subject of current systems analysis is usually greeted with dismay or disdain by systems departments. There are many reasons for this. In many installations, the support of current systems takes more than 85% of the systems department's time, and the departments are more than ready to get on with new systems development and bury the old, non-working systems as quickly as possible. In cases where systems do not require a lot of maintenance, the systems department may find that the current systems are not giving management the kind of information it needs for effective decision making; these current systems become likely candidates for replacement.

However, there are some very legitimate reasons for documenting existing systems...

One of the biggest challenges in any system design effort is to produce a viable system design that is well thought-out with all of the pieces and parts working harmoniously together. If something is forgotten, regardless of its seeming insignificance, it will undoubtedly cause costly problems later on. The task, therefore, is to produce a design that is demonstratively correct.