How to lead a project: the opposite of “waterfall” is “architecture-centric”, not “iterations”

How to lead a project

We must lead a project around the concept of “architecture”: “architecture design”, “high level design”, or “design”. However, note that because “architecture” has too much overloaded meaning, I use the wording “high level design” whenever I can.

The waterfall concept, that we do software in the order of requirement gathering, analysis, design, coding, testing, deployment, support, is simply wrong. However, the opposite of “waterfall” is “architecture-centric”, not “iterations”. "Iterations" are simply small waterfalls. Many small wrongs do not correct one big wrong. Further, the wrongness about the waterfall concept is not its frigidness; it is its emptiness and pretentiousness – it is its tendency to encourage people to think non-senses – things that cannot add values to the project (its frigidness is actually fine if you can deal with its emptiness and pretentiousness). We need to replace the “waterfall” concept with the concept of the “architecture” and the “dependencies” in the architecture. Note that “architecture” and “dependencies” are very rich concepts.

1. The project is within a bigger architecture.
2. The project itself has its own internal architecture, or, high level design.


3. The high level design of the project has the following parts:

a. “Functional” (in Siebel, we call it “configuration”). It includes OR mapping and OU mapping (i.e. ORU mapping) and rules. Here we have two important notes:

(i) functional is part of the architecture. Some people may say that the “functional part” is not part of an architecture design (i.e. high level design). That is not true. OR mapping, OU mapping/binding, and rule engine are certainly parts of an architecture design (high level design); the usage patterns of ORU mapping and rule engine are also part of an architecture design (high level design). It is actually very easy to see -- once we stop seeing things through waterfall glasses, and begin to see things through “architecture-centric” point of view: there is no “requirement gathering” or “analysis”, there are just vague designs, and designs are simply vague or unfinished systems.

(ii) UI must be easy for automated testing. Some people may say that testing is not part of a high level design. Wrong! Testing is part of the architecture, just as logging is part of the architecture. To ensure that, automated UI testing must be part of the early development.

b. “Architectural” (in Siebel, we call it “Integration and conversion”). It includes “transaction” (in Siebel, it is BS and WF), “networking (in Siebel, it includes EAI/web service, EIM, offline client, reporting server), logging, and security. Again, an important note here is that automated unit testing is part of a high level design. Here, automated unit testing is included in the concept of “transaction” -- a good high level design should always make it automated unit testable at transaction level.

c. “Admin”: this can be treated as an extension of b.

(i) Source control is an extension of automated unit testing; this is because it is through automated unit testing that source control is “attached” to the architecture and therefore must be treated as part of an architecture. Using source control is part of a high level design.

(ii) In Siebel, when we set up development environment; we need to go through hoops in setting up “offline client”.

So, here “admin” includes “deployment admin” and “system admin”. Note that by getting into "system admin", I begin to accomplish my new year resolution that I will consolidate my knowledge into a complete vertical stack, bottom up, from hardware, OS, to browser scripting.