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.

The differences between ALP and TDD

The differences between ALP and TDD

ALP is architecture-centric. It requires finish architecture design in the first a few days (for most projects), or, a few weeks (for really large projects).

ALP treats “stories” or “use cases” as vague materials. It directly focuses on three things: (a) the OR mapping -- key concepts (glossary) and (logical) database tables-columns, and (b) the OU mapping (or binding) -- key concepts (glossary) and screens and buttons, and (c) rules – key concepts, screens-buttons, database tables-columns, and business logic, in the contexts of typical scenarios.


You may say that TDD can do those things also, or, further, good TDDs do those things also. That is true. The same can be said to RUP. That is why it took me so long to make this explicit. However, I feel it is important to make it explicit, all good processes are alike; however, there are too many bad TDDs and bad RUPs.

Architecture-centric Lean Process, ALP

The name “Team Capability Model” is not well-known, so, it seems that we have to keep using the word “process” – so, here is a new name for it: Architecture-centric Lean Process, ALP.

In addition to the content of the concept, I like the name also. It has some tensions built-in (“Lean” usually means less “architecture”), and, it sounds official and formal.

An Architecture-Driven Team Capability Model

After a few years in written form in my notes and in the blog, I believe the “8 core computing techniques” is mature enough to have a more official or formal name, so that it can be used in any documents in the “corporate culture”.

I put some thought on it; the best way for it to "break in" the corporate culture is to use it as a "capacity model" (note that it is not just a “process” -- it has much more content). Because it is all about architecture, so, it is an architecture-driven capacity model.


1. A person’s or a team’s CAPABILITY is determined by its ARCHITECTURE CAPABILITY.
---- I know, this is a peculiar usage of the word “architecture”. Please see below.

2. A person’s or a team’s ARCHITECTURE CAPABILITY equals:

“Business knowledge”
+ “Technologies”
+“Processes”

All of those are elements of architecture:

(a) “Business Knowledge” simply means (i) OR mapping, (ii) OU mapping, and Rules.

(b) “Technologies” simply means (i) Transactions (note: capable of unit-testing at this level is like logging, is part of the architecture, it is NOT just a feature of a “process”), (ii) Networks, (iii) Logging, and (iv) Security.

(c) “Processes” simply means the “order of doing things”, based on the DEPENDENCIES in the architecture.