Sunday, June 22, 2008

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.

4 Comments:

Blogger Fregas said...

I think waterfall had plenty of "high level design" and plenty of architecture. Massive documentation of requirements, complex UML diagrams, flow charts, tests, etc. abounded and still do in waterfall environments. Waterfall was full of architecture.

The problem was timing. They designed too far in advance. They gathered requirements for features that may never need to be implemented. The created documentation for a project that was bound to change. They did lots of testing and lots of bug fixing. They did tons and tons of deployment, although usually all at the end.

I would agree that merely adding "iterations" won't fix everything that was wrong with waterfall. Agile is not simply about taking a waterfall project and breaking it into iterations. But iterations DO have value in that they break the project into smaller chunks, and perform those activities at the right times and get feedback from those activities at the right times.

That "frigidity" (i think you mean rigidness) does cause problems, because requirements, business needs, heck even manager whims are about to change. Why build something thats going to be obsolete 6 months from now? Lets build just what we know we need right now and be willing to change as needed. Those small iterations mean there's less waste.

7/21/2008 08:39:00 PM  
Anonymous Anonymous said...

After a while, I feel “architecture” is not the right wording, it should be “design-logic”. So, it is time vs. logic (“dependency” is also logic). Logic determines time, not time determines logic. Time is poor, logic is rich; time is monotonous, and logic is flexible; time is shallow, logic is deep.


When you lead a team, think about logic, do not think about time. Ya, sometimes you need to think about time – but time is simply a result of the logic. Sometimes, you need to bend the logic in order to fit the time; however, trying to dig into time, you will get nothing!


You are right; you make me to see that the word “architecture” has too much junk from waterfall processes. I will use "logic", "structure", "design", "design logic", "design structure", instead of "architecture".

survic

7/28/2008 04:23:00 PM  
Anonymous Anonymous said...

Iterative approach may be hard to sell because at first look, it looks some wastage of time.

But in reality, it is other way.

http://vikasnetdev.blogspot.com/2008/07/leading-project.html

7/28/2008 07:28:00 PM  
Anonymous Anonymous said...

http://agiletips.blogspot.com/2008/07/agile-bridge-analogy.html

This is good one.

Vikas

7/29/2008 09:29:00 PM  

Post a Comment

Subscribe to Post Comments [Atom]

Links to this post:

Create a Link

<< Home