I like children. If they're properly cooked.

Fields, W.C.  1880 - 1946 U.S. Actor.

When designing a new Information System, it can often seem like putting together a puzzle that you have never seen before. Worse yet, you may not have a picture from the outside of the box to help guide you (My dog ate my box?). From observing various family members, it's clear each approaches the problem with a slightly different strategy. My particular strategy is to first build the outside of the puzzle. First, all the border pieces are easier to identify; they all have at least one straight edge. Second, I then have a well-defined boundary around the puzzle to help me determine how the remaining pieces fit, often working toward the center from the outside. Opportunistically, as one finds pieces that "clump" together, a team of family members can put the puzzle together in fairly short order, even if it is large.

Strangely enough, that's a good strategy for designing and building Information Systems (or really any kind of processing system). In older, "structured" methodologies, one first began by defining the boundaries of the system and developing a "context" diagram. Newer methodologies do something similar. However, what must precede this boundary definition, is a "picture" of what the system must do. The single most important piece of information necesary to develop this picture is: a clear and accurate definition of the problem that must be solved. In my vast experience, NOT having this definition, or having the WRONG definition, is a definite assurance of failure. The liklihood of your customer(s) liking a system that does not address their real problem is very low.

Note, however, that I did not include "complete" in the above definition. First of all, it will never be complete. Second, user requirements are CONSTANTLY changing; particularly in today's business climate. The amount of time required to gather all the information is so long, that some of the old information is certain to be invalid today. What is one to do?

One starts with incomplete information. Having a certain amount of domain expertise is extremely valuable here. Toyota was able to shorten the amount of time to take a new car design from design to construction by taking advantage of this type of information. For instance, they know that car doors are almost always under a certain size. So they can begin the ordering process, refining it as the design progresses, knowing that the doors will be less than "X" by "Y". Doors need to have handles and locks, and interior side beams. All of these are pieces of information they have from "being in the domain", and recognizing the important requirements independent of the actual "shape" of the door.

I, and often my customers, have a certain domain knowledge about Information Processing: data must be validated; tables need to be normalized; entities must be properly identified and described, etc. But more importantly, we must be able to recognize whether the customer has actually described the problem to be solved. We have done a lot of work with business operations people. These are often very smart people, but they rarely have the time or inclination to analyze beyond the problem staring them in the face RIGHT NOW. So most often, I am presented with a SOLUTION to implement, before anyone has verified:

• it solves the real problem, and
• the solution won't create even worse problems

Our goal is to help my customers craft a REAL solution, based on visualizing the problem from a higher level.