|
ANALYSIS
PARALYSIS JUST MAY SAVE YOUR LIFE
By
Ronald G. Ross, September
1999
Many
predators hunt based on movement. In fact, even with their keen eyesight, they
cannot really "see" unless the prey itself moves. Consequently, many
hunted animals are programmed literally to "freeze with fear." Not a
bad move if it tends to save your life.
Recently,
I had the chance to review a major-league mess at a large organization that
didn't "freeze with fear." I won't go into all the details, but
let's just say they got on with the coding phase of a large project way too
early. The wounds are deep, and one way or another, the company will ooze red
ink, its very lifeblood. Where did it go wrong? The usual no architecture, no
business rules, no top-down business model.
On
the software side, the company was sold a bill of goods. It was promised that
a breakthrough software product could replace their legacy systems in four
months. (Yes, they should have known better.) To go with that was a spiral
"methodology" based on the mantra, "analyze a little, design a
little, code a little, test a little." The company learned the hard way
what that actually means in practice-rewrite a lot, for a very long time.
Projects
out of control, and belief in the fairy godmother-these are nothing new. I
know this has been said many times, but let me say it yet again. There are
simply no silver bullets. You need to do a business model before you do your
system design, and you need to do your system design before you start your
coding. That is, unless you can afford to spend the rest of your life in
rewrites and "maintenance."
So,
what does "analysis paralysis" really indicate? Maybe that...
-
The
business problem itself is hard. Do you believe that thinking about it in
a coding language (or in IT system models) will make it easier?
-
You
don't really know what the business problem is. In that case, the cure may
prove a lot worse than the disease.
-
You
can't get the right answers from the right people. Then what exactly are
your chances of success?
-
You
have significant differences of opinion about the business itself. Do you
think programmers will make better choices?
-
The
future is hard to predict. Do designers and programmers have better
crystal balls?
-
You
don't really know what is needed. So rolling the dice is the right answer?
-
There's
actually no answer to the business problem as posed. Better rethink the
business problem up front!
-
You're
simply not smart enough to solve it. I doubt that, not if you get the
right people together.
-
You
don't have the right approach. That's the most likely one. Think
architecture, business rules, and a top-down business model, and you'll be
O.K.
So
the next time you hear anyone say watch out for "analysis
paralysis," I hope you will take pause. Just freeze-it may save your
life. Somewhere close by there's probably a programmer poised to pounce on a
keyboard.
©
1999, Ronald G. Ross.
|
|
November/December 1999
The Fin de Siegle Legacy Mindset
By Ronald G. Ross
September/October 1999
Analysis Paralysis Just May Save Your Life
By Ronald G. Ross
July/August 1999
If We Had Started Coding Already...
By Ronald G. Ross
May/June 1999
Your Core Business Processes Need a Rule Engine
By Ronald G. Ross
January/February 1999
Four Things Wrong with the Way We Develop Information Systems
By Ronald G. Ross
November/December 1998
Push-Type Data Hub vs. Pull-Type Data Warehouse
By Ronald G. Ross
September/October 1998
What Knowledge Management is About (And What it Has To Do With Business Rules)
By Ronald G. Ross
May/June 1998
The Next Great Leap Forward ~ About the Changes You See
By Ronald G. Ross
March/April 1998
Business Rules as Customer Interface
By Ronald G. Ross
January/February 1998
Components and Business Rules: Do They Connect?
By Ronald G. Ross
November/December 1997
The Policy Charter: A Small-Sized Picture of the Big Picture
By Ronald G. Ross
September/October 1997
Implementing
Application Packages: Is There A Better Way?
By
Ronald G. Ross
July/August 1997
'Why'
is Why Business Rule Methodology is Different
By
Ronald G. Ross
May/June 1997
Never-ending
On-the-Job Training
By
Ronald G. Ross
September/October 1996
Re-Usability
in the Business Rule Approach
By
Ronald G. Ross
March/April 1996
The
Newest Idea In Business Rules: Rules Normalize!
By
Ronald G. Ross
January/February 1996
An
Open Letter to DBMS Vendors: We Need Active Database Systems
By
Ronald G. Ross
May/June 1995
The
Greatest Irony Of The Information Age: Business Rules
By
Ronald G. Ross
November/December 1995
Business
Rules:
Knowledge For Knowledge Workers
By
Ronald G. Ross
March/April 1994
"Play
Ball!"
By
Ronald G. Ross
November/December 1999 & January/February 2000
Enterprise
Architecture: Issues, Ingibitors, and Incentives
By
John A. Zachman
July/August & September/October 1999
Packages
Don't Let You Off The Hook
By
John A. Zachman
November/December 1988
The
History Of Steam-Powered Ships
By
Ronald G. Ross
January/February & March/April 1999
Life
Is a Series of Trade-Offs and Change Is Accelerating!
By
John A. Zachman
January/February 1994
"Business
Rules, At What Cost?"
By
Ronald G. Ross
November/December 1998
"Yes
Virginia, There IS an Enterprise
Architecture"
By
John A Zachman
May/June 1994
Business
Rules: Birth of a Movement
By
Ronald G. Ross
January/February 2000
Business
Systems And Information Support Systems
By
John Hall
July/August 1998
Enterprise
Architecture: Looking Back and
Looking Ahead
By
John A. Zachman
July/August 1991
Why
I Like the Zachman Framework Architecture"
By
Ronald G. Ross
January/February 1998
The
Framework for Enterprise Architecture (The 'Zachman Framework') and the Search
for the Owner's View of Business Rules
By
John
A. Zachman
March/April 1997
Business
Process Re-Engineering
By
Ronald G. Ross
|