Re-Engineering

At the heart of the Re-Engineering is the continuous process of change. The change or transformation of matter from a given state to a new statea natural fact in the Universeis still poorly understood. And especially poorly managed within the human society, particularly when dealing with the technology (type of) change.

Usually, those responsible for changing a system do not follow any methodology or process. They start the change with ad hoc modifications of the process in attempts to "make it work," and therefore the trouble begins. In the end, the good intent of the process is usually destroyed.

The goal of change includes maximizing the return of all investments in product development, thus the entire product life cycle must be addressed. Changing the "piece-part paradigm" of trying to solve the puzzle by focusing on one or two processes must be the first priority.

Re-Engineering is a process. Architecture is rather a product part of the process.

Implementing change over an entire product life cycle requires a methodology. According to the Webster II New Riverside University Dictionary, a "methodology is a system of principles, procedures, and practices applied to a particular branch of knowledge." For quality products (i.e., it meets the requirements), this becomes a product life cycle methodology.

While Webster identifies the three components that make up a methodology, there are two others that enable it to adapt and function in different product environments. The five components of an Re-Engineering Methodology are:

· Processes

· Principles

· Practices

· Tools

· Culture.

These five pieces are critical to a methodology. Without one, the entire approach has little chance of success. And a methodology should be able to have built-in flexibility that will allow for its repetition and adaptability (generic in nature). To illustrate the relationship of the five components, consider the task of building a good quality house (that, by the way of methodology, it has no value in time if it's not going to be adaptable and repeatable).

First Steps

The most common component of a methodology is a process. A process is a defined set of steps which must be followed to complete a project or task. For a builder, the process can be simplified, from start to finish in two stepsdesign and build.

The process may begin with an architect who designs the house (at general level) around the functionality requested by the home owner. This would include guidance from the builder, who has walked many miles in the product's shoes and due consideration to building codes.

However, what are the odds of building a house without getting some form of (government or any other regulating body) approval? The scope of a house building process is controlled by building codes. These conventions or standards that defines criteria which ensure quality, safety, and consistency are known as principles.

In addition, there are also principles that set standards for drawings and datums and even others that are "unwritten" standards of an industry. Without these latter principles, communication would be difficult, if not impossible, as they provide a common set of terms and measurements.

The Right Path

Practices are used to complete a task in a defined or acceptable manner. They differ from processes as they define how a task or activity within a process will be completed.

In the construction of a house, the builder has the option of nailing the drywall to the wall or using more expensive screws that offer higher quality. Practices are chosen to reflect the philosophy and integrity of the builder in meeting the product specification of the home owner.

In the product life cycle, practices may include a means of defining market needs, engineering calculation requirements, ways to establish the geometry of a product, or how a product is assembled. Establishing a market need, for instance, may require conducting a survey. A survey can use the practices of face-to-face interviews, phone interviews, or direct mailers. Each practice is used to deliver a certain results and influence the process to which it applies.

Implementing Processes

Once principles and practices have been applied, a process is usually fully developed and ready for implementation. A process cannot be implemented unless supported by the next component, tools.

There is a danger in selecting tools too early in the process. Tools are there to support the process, principles, and practices after they have been established.

Another problem within the current tool-oriented systems development approach is that the process, principles, and practices are often forced to fit the tool. In the house building example, if screws holding up the drywall best meet the design specification and the builder only has a hammer available, desired quality may be sacrificed because the wrong tool was only one available.

Tools are often selected first, for the wrong reasons. For instance, CAD (Computer Aided Design) systems were designed for improving the drawing, storage, maintainability, and clarity of engineering drawings. They were never intended to go to the head of the process and become the primary design tool. A very similar analogy can be made for CASE (Computer Aided Systems/Software Engineering): from very beginningand even up to todaythis technology has been seen as a "miracle" tool that someone can throw a set of requirements at the front-end and get back at the other end a fully working, error free, high quality product!... A tool without the knowledge, skills, practices, principles and all infrastructure (surrounding its use) is just going to be just that, a tool. Larry Constantine, one of the most remarkable figures of our time in the computer industry had a great saying along these lines: "A fool with a tool is still a fool."

Right Frame of Mind

The four components already discussed can be effective only when the appropriate culture, the fifth component of a methodology, is used in conjunction with them. What is a culture? Webster defines culture as the training and developing of the mind.

Returning to installing drywalls in the house building example, the right culture will influence the best choice of tools that will successfully fulfill the process as the hammer may be the only tool available because it is the builder's tool of choice. And that's because the builder simply feel more comfortable using the hammer.

However, in the process, the product specification defines quality as more important than finishing the job quickly, so the builder will take time to get a screw driver to complete the task. Culture is the ease by which the builder selects the practice of attaching the drywall with screws instead of nails, because it more appropriately satisfied the product specification.

There is an old rule: Lead, follow, or get of the way.

Within every company culture there is some mix of leaders and followers. Either through the management hierarchy or sheer force of personality, these individuals usually sort out compatible working arrangements by themselves, even when surrounded by madness. The challenge, however, is those that should get out of the way. This is because, depending on the circumstances, they may be a mix of leaders and followers who also may be a peer and superior.

In summary, all of the above, Re-Engineering, Architecture and the 5 Components (or Dimensions) of the Re-Engineering, are the key to the change. And this change is not possible without the build-up of an appropriate Infrastructure, Information Systems (to support it,) extensive (and continuous) Training of the people, a Teamwork approach, (continuously) Improved Communications, and a Concurrent Engineering development effort.

All of the above it may sound like another TQM (Total Quality Management) lesson, that many people (in our culture) do not understand it or do not want to understand it. And it's a matter of how you look at and approach the change. Seeing the processes and the products, people and tools, as well as their inter-relationships. The bottom line is a successfully approach to the change, that as stated in the beginning is just a matter of fact in our known Universe that you can not ignore it. And also, how you manage it, i.e., through a methodological approach, as exposed above.


Regarding the pages posted to this WWW area or for further information about the Software Architecture, contact Cliff Kettemborough