How to apply LCLP on Siebel CRM development

How to apply LCLP on Siebel CRM development

It is logic centric; then, what is the logic?

It is the 8 core techniques, of course – as promised :-) it is all just about re-packaging.

A little further now though. Because of LCLP, we can justify that we jump on those 8 core techniques directly.

Because we do it directly, we can immediately split those into a few dozen items.

Also, “techniques” are too “doer-centric”, so, let’s change it into “special design areas”.

So, the result of applying LCLP on Siebel CIM development is that we directly jump to a few dozen “special design areas” – the groupings are still those 8 core techniques, of course.

-----------------examples:

---- LOV, constrained LOV, static and dynamic, how to make greatParent-parent-child LOV.

---- State model

---- ldap/asi adapter: because Siebel does not use a generic database account, so, even we use ldap/asi, we have database accounts. The adapters will help the sync.

---- …………

LCLP and cheese without fat

This is basically a comment I left on:
http://vikasnetdev.blogspot.com/2008/07/leading-project.html

Based on the comments of previous blog, I have to change ALP (architecture-centric Lean Process) to LCLP (Logic-Centric Lean Process, note that I cannot use LLP) .


Comparing with Lean, I feel TDD or agile is not enough, even I am willing to go along with TDD, since it is the closet we have for now in software industry.

I would like to remove all the concepts that lead to waterfall. For example, the so called "requirement gathering". It implies a step in the waterfall. Requirement gathering is simply communication with users. I deny the concept of "requirement gathering", because there is no special ways in "requirement gathering" -- comparing with "design" (or, a better wording, "logic"), it is vague, and the faster you can jump on to design, the better. "Requirement gathering" is simply an inefficient or less-than-optimal design. All this means, let's talk about screens flows, screens layout and data entities and related business rules, security, notifications, logging, installation, source control, etc. directly and as technical and specific as users or audience can understand, and with no certain orders other than the necessity of the logic.Cut to the cheese, lean, it is the cheese without fat.

How do you like that, cheese without fat :-)

--------------------------A notes on July 31
I know I go to extreme sometimes, that is my weakness – but that is also my strength, by doing that, I get to the bottom of things quickly.

I am trying to eradicate all waterfall concepts, even just some traces of it. This exposes the needs for order.

I said that there is “no certain orders other than the necessity of the logic”, the tone is certainly mostly negative. After thinking about it, I know I need to emphasize the positive side of it also.

The key is, after removing the waterfall, we can see the orders introduced by the “necessity of the logic” more clearly, and therefore, can follow those orders, and do things more efficiently and more effectively.

Actually, that is the whole point of removing waterfall. Waterfall ordering eclipses the real orders: it oversimplifies things to one dimension.

This leads to a very counter-intuitive statement: the most harmful situation of waterfall process is actually for large projects, when you cannot simplify things like that, even using many iterations, it simply just does not work.

Typically, in a mid-to-large sized project, there are a few dozen of “dimensions” (you can “group” them into two or three groups, but those groupings are vague). Experienced team leads or good project managers pick up those dimensions quickly, and follow them up through the whole project.

Along each dimension, there are pretty clear patterns, and among those dimensions, there are also some vague but useful patterns. Ya, those dimensions and patterns are “technical”, but good leads or project managers do not only know some “project management” terminologies, they are technical enough to know those dimensions and patterns.