Effective Engineering 
                Consulting Services
   
                                           "Helping Engineering Excel!"

Home
Our Premise
The Problem
Our Promise
Our Approach
Our Deliverables
Case Study
Our Results
e-Newsletters
Our People
Contact Us
Photos

 

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:

   

Society of Professional Consultants

  

Copyright © 2002-2013 Effective Engineering Consulting Services, All Rights Reserved