jefgray.com

Creation VS. Evolution

If you have ever remodeled a house, you will understand this analogy. Let’s pretend a family of 4 moves into an appropriately sized dwelling and live there for several years. In time, the need for more space grows; more storage, a guest bedroom, a study, a family room. The family finds a bigger home and moves to it, or they renovate the existing house and build on to the structure.

There are reasons people decide one way or the other. Moving gets the entire process over with in one painful step. Renovating is more cost effective and you are able to spread the issues out over a period of time. A course of action is chosen depending on which serves the priorities better.

Imagine a house that has been modified several times to accommodate different needs over time. Rooms are added on to rooms, hallways are extended, attics become rooms, and other equipment is brought in to facilitate the need for air conditioning, heat or hot water. Eventually the original house design is lost and the larger more “evolved” house remains. If the house fits the needs of the day, then it is sure to be changed as needs change. A pattern of addition has been established and will continue until it becomes more expensive to add than to move out.

Your mainframe or network servers will resemble one of these scenarios. You have either decided to cut your losses and migrate to a new platform/vendor or you kept the old system and updated, patched or enhanced its original design.

The decision is not an easy one, and it often has some serious consequences regardless of the choice you make. If you keep the old system you declare obsolescence in 6 months or less, if you buy a new system you are putting everyone through the learning curve, including your customer base. An IT manager or executive must understand the differences in creation (buying a new system to fix everything) vs evolution (modifying a system to repair issues that don’t work or need to be added).

Why creation:

A new system can be more comprehensive and efficient than an older one, and it is more likely to integrate better with emerging technologies. It can also be tested offline while the legacy system continues to operate.

The creationist or new approach gives a lot of freedom to the design. A question that must be asked is, “If we were starting this business today, would we want the computer system to run like it does now?” Usually the answer is no.  Therefore; design your new system to do more than what you had before. Reinventing an old system on a new platform is a paradigm centric fallacy that many follow.

A designer has to ask the right questions. Who approves this or that? Who starts the workflow, where do orders come in and how much empowerment can be attributed to the front line workers? These concerns are true of any system. The deeper questions are harder to define; how much of the process was based on the old program? Do we really need three copies of this form?

If this is new automation, consider the consequences of removing a paper-based function from the daily routine. Look at the entire process from creation to retrieval. Then asked questions to analyze everyone’s involvement in the product.  Who needs to see this information? What key words or numbers will they search on to find it? Who gets the reports? How is the information analyzed or stored?  Based on the answers, begin to build the database and interfaces that would process all of the information and make it readily available.

Creationism is the best solution because it embraces the one constant of all communication systems; change. A created system re-invents the process based on the latest developments in a company. Users will complain that things were easier on the “old” system simply because they knew the old system better. In the long run, we forget the headaches of the past and only dwell on current misery. Design your system so that you can modify it based on input in the early stages of deployment and you will have a greater success among all who use it.

System creation is based on what we are doing; system evolution is based on what we did.

Evolution:

This idea is not new of course, we have been force fed the theory from grade school. All religious implications aside, I still think evolution doesn’t work. It is an outdated model fraught with paradigms that assumes a system could not get any better, even if it is 10 years old. The only things that survive this long are flyswatters and nail clippers. Everything else tends to wear out before then.

The first fact you must face is, if the old system worked, you wouldn’t be considering a revision, modification or upgrade. What brings you to reconsider your system should bring you to the design phase. You need more drive space, faster interaction on the client side, more options or increased search capability.

The evolution approach also requires the clients to live with the modifications while an upgrade is in progress. Frequent server re-boots or system lock out time is common. And one adjustment that solves the problem can create another somewhere else. –Much like the house analogy.

A system change is akin to renovating one room in the house, the other rooms are affected.  Dust and noise creeps throughout the house.  The fumes from new paint require other rooms to be ventilated, even though they are not being painted. Furniture from the old room is placed in hallways or other rooms, crowding their traffic flow.

The final job may be impressive, but now the rest of the house needs attention since this project demanded so much time. Everything gets put on hold during revisions and the backlog created by them is never ending.

In small-punctuated issues, a revision is the perfect solution, but global concerns that span the enterprise should never be regarded with the same type of thinking. Once you set a pattern for revisions, you commit yourself to obsolescence and inflexibility with emerging technology.

Popularity: 14% [?]