“Analysis Paralysis”?
-- There exist so many ways to proceed, how could you get paralyzed?
Francis G. Mossé, Object Discovery Corporation |
 |
COLUMN
PDF Version |
I’ve been in several situations in which students would stop
me in class and ask with stern faces: “How do you avoid analysis
paralysis?” First time I heard that I sincerely replied: “How
do you get to be paralyzed?” Indeed, there are many ways to avoid
analysis paralysis—at least 5. The rest of this article assumes
you’re in the shoes of an analyst, with the mission to model
some new topics that experts are explaining to you.
Perhaps a manually
run business operation is to be automated. The analyst must first understand
what the system has to do (analysis) before deciding
how to automate it (design). Muscular paralysis comes from blocking
the connection between the brain and muscles. Mental paralysis, the
analogy used here, comes from either having no idea what to do or having
too many options to choose. The following advice cures the no-idea
case and gives priorities to help you determine where to start and
how to continue.
Picture the subject matter experts throwing all kinds
of elaborated concepts at you. They’re the experts, yet you may
see them stumble over fundamental definitions, use terms you can’t
relate to, contradict another expert, call-up a colleague to check
on key concepts
and so on. That would slow down and even freeze your analysis process,
wouldn’t it?
- Deal with the best-known topics first
Identify a topic your experts seem to know best and model it right
away. It doesn’t have to be an easy one (half of the time it
won’t be). You know how to model and the experts know the topic.
Here is your opportunity to make quick progress. Once you’re
done, go on with the next best-known topic, and so on.
So, your tactic at that early stage is to channel everyone’s
energy to come to closure quickly on existing knowledge, knowledge
that is readily available. This will bring you two immediate benefits:
a) everyone will feel satisfied with the rapid progress; b) future
discussions won’t be cluttered with these topics.
While dealing with the best-known topics and concepts first, you
might end up building a good chunk of your model. This will definitely
prepare
the ground for further modeling. Later on, additional and more-complex
concepts might easily “plug-in” with the already modeled
ones.
- Locate the most knowledgeable person(s)
We’ve all been there: you work hard with a very well intentioned
fellow trying to understand some deep topic, but somehow the more you
analyze it the less you feel you can grasp it. After some considerable
labor, he or she tells you: “I don’t really know—after
all, I’m not the expert!”
You can avoid this problem by looking for the experts prior to
starting anything. Always ask: “Who’s the top expert in this matter?” Spend
time with the experts first. If they can’t really afford
to spend hours with you, invite them to join some of your short
analysis
sessions.
Involve them by all means.
You’ll find that real subject matter experts will make your
project progress with giant leaps.
- Use the marvels of natural language
The UML may be a great modeling language and you might be a champion
at using it, yet you could experience a very slow start. Have
the expert write one or a few paragraphs on the subject matter. For
example,
Paul
is the man who truly understands retirement plans. It’s a hairy
subject. Don’t start to model it straight from a first
encounter with him.
Have Paul write a few paragraphs ahead of time to summarize all
he knows about retirement plans. Then Paul and you can meet
and model. In so many years of consulting and mentoring in the industry,
I’ve
almost never seen a true expert fail in writing his/her
knowledge in plain English. Natural language has its unquestionable
power.
Ask also that key words used in that text be defined in the glossary—still
in plain English. With these two documents, the expert’s knowledge
will be clarified, you’ll get a powerful start and you’ll
have a reference that you and the expert can use while modeling. I’ve
tried it both ways: with or without a narrative to start with. I feel
that modeling sessions are much faster if you start with a short narrative
(I also call it a “problem statement” or “business
synopsis”).
They will enjoy seeing their terms appear in your UML diagrams
and use case narratives. Remember, with UML you are structuring their
expertise,
not encrypting it.
Some people object that plain English is not that useful and certainly
not as high-tech as the UML. They argue that tools like UML sequence
diagrams could “get you there” much faster. It’s
a myth. Narratives expose the meaning; they build up fundamental understanding
in the analyst’s mind. That’s the best place to start and
it’s quickly obtained.
Note: In a future tech letter I’ll write about object interactions,
activity diagrams and business process modeling. I’ll also
write about the power of relationships as modeled in various
UML diagrams.
- Slice up concepts
Now, assuming you’ve got the right expert(s) to speak with and
a narrative to start with, what’s your next step? That’s
where your analysis activity really begins. Stick to the business
concepts: what they mean, how they differ from each other,
what type they belong
to, what characteristics they exhibit, what they are made
of and so on. Very importantly: how they relate with other concepts.
That part is like “dissection”: slicing up the concepts.
All the above angles, as you know, lead you to using fundamental
UML constructs. Examples are: classes (or objects), attributes,
inheritance, composition, associations and association classes.
In very little time your UML picture is built of various diagrams
and you feel at home. Don’t think you’re done.
You need to present the outcome of your analysis back to the
experts, as advised
in the next paragraph.
- Assemble concepts back together
As you probably remember from our course, a model is only as good
as its effectiveness in reflecting the reality. Experts took the
time to work with you; they hope for more than a cryptic picture
that you
seem to be the only one to appreciate. You need to close the feedback
loop.
Read the whole diagram back to them “in plain English”,
using their business terms. Examples would be: “Purchase orders
refer to goods that are requested by manufacturing departments…” Do
not say things like: “Here is the PO class that is associated
with the Good class, and it’s a 1 to many association…”
Do not use any UML terms while describing your model back to the
domain experts. They need to “hear” your model. Based on that,
they’ll tell you whether your understanding is right. They’ll
help you fix details and refine your model, based on your own reading
of the model. After a few iterations your understanding will be raised
to the expert’s level.
Now, your model is ready. It’s the blueprint for the whole project.
It’s a bridge between the expert’s mind and the
actual system that will be built to automate the business
needs.
Before modeling, we always make sure that enough knowledge about the
subject matter is available. If it’s not, then we go get the
experts. We model what is known. We postpone what’s not known.
We use natural languages to start with and also to conclude. What was
said at the beginning of the analysis period will also be expressed
at the end. In the process the model is built.
It’s a very simple,
systematic strategy based on common sense, based on human understanding.
This very dynamic process moves you towards
the goal. How could you possibly get stuck? There is no excuse for
paralysis while doing analysis; that is nothing more than an old catch
phrase.
About the author
Cite this column as follows: Francis G. Mossé: “Analysis
Paralysis? There exist so many ways to proceed, how could you get paralyzed?”,
in Journal of Object Technology, vol. 2, no. 5, September-October 2003,
pp. 13-16. http://www.jot.fm/issues/issue_2003_09/column2
|
