Two Types of Design Iterations

In the continuing dialogue of the Design Iteration process shows that a limited amount of research has been performed here. Professor Smith of MIT nails it with his definition of the types. He talks at length about hardware issues and at a cusory level of the software design iteration process. The process is essentially the same. The problems especially so. What are the types he talks about.

1. Expected Iteration: Or the time it takes the team to create the first pass - a nomimal design. That time which it takes the team to perform the first pass and anticipatated time of the internal design process of each sub-team. Or those iterations which are expected and planned for.

For instance, a business analyst can anticipate some of the steps that may be occuring in a process at high level and present to the business owner a "archtectural" draft or blueprint of the selected process. So some of the design can be attempted even though sufficient information to complete them is not known. So as the input information becomes known and documented the design capture process is repeated until the process information draft is improved.

Many business analysts can relate that this is a difficult task which requires effort to negotiate information from the business client and then renegotiate with IT the documentation of the requirements. There has to be an easier way!

2. Unexpected Iteration. Here again Smith nails it. "The unanticipated iteration in the internal design including re-work due to interanl errors, errors by other groups (read IT, or other business clients who think they know) and changes in product (business) strategy." So the original design unexpectedly fails. When has that ever happened?

This failure occurs most likely, during the execution testing phase. What if we could test sooner and more often maybe we would succeed more quickly? Thomas Edison said, "Results? Why, man, I've gotten lots of results! If I find 10,000 ways something won't work, I haven't failed. I am not discouraged, because every wrong attempt discarded is often a step forward...." .

Our point is that historically we have disassociated the design phase from the execution phase. This is crazy because the one effects the other. Engineers have agreed to be monitored from a testing perspective, because they take macho pride in one uping one another on software development efficiency, and it is measurable by time. But all of us know that efficiency is not quality. Let's begin the dialogue again, anew!

So what Zynium is saying that all of the eoteric features that have been developed in the IT solutions (BPM, SOA) and that may be done, really doesn't mean anything, unless you can prove that you understand the basic steps of the process, first.