|
| |
Back to
e-Newsletter Archives:
 Effective Engineering e-Newsletter – 10/09/2003
This is your bi-weekly e-Newsletter from Effective Engineering Consulting
Services (www.effectiveeng.com).
If you would like to receive Effective Engineering e-newsletters as they
are published, please send an email to e-newsletter@effectiveeng.com,
and we will add you to our distribution list. Comments and suggestions are
welcome and encouraged!
eN-0301009:
Development Methodology: Architecture
By
Tom Dennis – President, Effective Engineering [tdennis@effectiveeng.com]
In the last e-Newsletter (see eN-030925
– Development Methodology: Requirements), I discussed the Requirements
that need to be defined and documented up front in a product development to
define the WHAT of product development (e.g. product definitions, design
specifications, test requirements, etc). The
other aspects of Requirements – the WHO and WHEN – will
be discussed in the next e-Newsletter on development planning (see eN-031023
– Development Methodology: Failing to Plan Means You Are Planning to Fail!).
This e-Newsletter concentrates on the WHY and HOW of
product development – the Architecture choices and the rationale behind
those choices. These architectural
choices make all the difference between a good product design and a bad product
design.
Before I start talking specifically about product architectures, let’s
consider an analogy of planning a trip. Some
people would simply jump in their vehicle and start driving to go from point A
to point B. When they encountered
difficulties, they would try to “fix them” as they went along.
However, some of the problems they may encounter can’t be fixed because
some of the (architectural) choices they made, consciously or unconsciously,
will stop them dead, or seriously slow them down. For example, if they jumped into a low-clearance two-seat
sports car, and later found they had to travel on a particularly rough off-road
trail for a portion of the trip, they’ll find themselves stopped dead.
If they had thought about their (architectural) choices in advance, such
problems could be avoided from the outset.
Such (architectural) choices include defining their (performance) goals
up front. Where do they want to go?
How do they want to get there (Fastest trip? Shortest trip? Most scenic
trip? Off-road trip? etc.)? How
quickly do they want to get there (4 hours? Overnight? In a week? Etc.)?
Is this (performance) goal even achievable (e.g. if you want to get from
Boston to San Diego by car in 6 hours, it’s just not going to happen)?
What kind of vehicle is required (2-seat sports car? 4-door sedan? SUV?
RV? Airplane? Etc.)? What do they
want to accomplish during the trip (Just get there fast? Enjoy the scenery? Meet
and talk with as many people as possible? Try to sell product along the way?
Etc.)? Without understanding what
needs to be accomplished (WHY) and the best way to accomplish it (HOW), you
could make (architectural) choices that will severely limit your chances of
success. Trying to “fix it
later” may not be possible, and you’ll be left with a failed or severely
limited outcome.
In product development, the choice of architecture can make an enormous
difference in a design approach. Too
many engineers decide to just design “something” and “fix-it-later” by
“tuning” the design. Performance
is ignored until there’s a problem. Fixing
a performance problem after the design is complete and the problem becomes
recognized is costly and time consuming, and sometimes just can’t be
“fixed”. Simply using a faster processor/computer, or more or faster
memory, or faster I/O, may be insufficient to overcome underlying architectural
roadblocks. However, fixing a
problem before it becomes a problem, at the architecture decision point, costs
very little and pays off many-fold in both time and money. By thinking through what you need to accomplish up front, the
architecture can be designed to ensure a successful outcome.
You can’t tell if you’ve achieved your design’s performance objectives
unless you specify what those objectives are.
You need to define your performance goals, and they need to be precise,
quantitative, and measurable. A
goal of “as fast as possible” simply isn’t useful.
Some examples of meaningful performance objectives are, “CPU
utilization should be less than 65% for a peak load of 2,000 events per
second”, or, “response time to a database inquiry should be under 100
milliseconds with up to 1,000 users”, or, “the switch-router should process
data at at least 10 Gigabits per second with less than 10 microseconds delay”.
You should also recognize that needs will change over a product’s
lifetime, and such likely changes should be taken into account.
If you’ve already got an existing design, you need to determine where
you are now. Does your current
architecture meet the required performance objectives?
If not, where are the primary problems, and what are the root causes of
these problems? Is it even possible
to achieve the objectives with the current architecture? If so, what needs to be done?
If not, it’s time to take a step back and think about alternatives.
Next you can evaluate alternative architectures to achieve the performance
goals. At the risk of bringing PETA
down on me, “there’s more than one way to skin a cat”.
Tools are available to model different architectural approaches simply
and effectively, to determine how different architectural choices affect
achievement of performance goals. One
of these tools will be discussed in more detail in a later e-Newsletter.
The key is to model the architectural alternatives and determine what the
major bottlenecks are, and then devise architectural approaches to avoid,
reduce, or eliminate them. If you
eliminate one bottleneck, then what will be the most likely next bottleneck?
It’s like peeling back the layers of an onion.
Once you’ve settled on an architectural approach that will achieve your
performance goals, you can then define the requirements and develop a plan to
implement a design based on that architecture.
Part of the requirements and the plan should include verifying that the
precise, quantitative, and measurable performance goals have been achieved. Then follow the rest of the development methodology to
successfully develop the product, as specified, with high quality, on time, and
within budget. The value of a good
architecture will be the foundation of the design, and of a successful product.
Copyright ©
2003
Effective Engineering Consulting Services, All Rights Reserved
Back to
e-Newsletter Archives:
| |
|
