One of the things that helps reenforce new concepts, like the ones I’m teaching, are simple tools that guide you along the way. Like a carpenter’s square, hand plane or ruler, simple tools can be very effective in the hands of a trained engineer. To help further the agile engineering discipline, I’ve created a Tools section of the site and published the first one, an Impact Estimation table designed for Architects and Requirements Analysts.Impact Estimation is a way to assess a design’s impact on a set of desirable qualities. This can be for one quality, such as Response Time or Transactions per Second, or for a collection of key qualities, such as System Performance.
As useful as Impact Estimation is, what is perhaps even more important is the exercise of filling it out. In order to do so, you basically have to do two things:
Quantify the key Qualities
Estimate a Design’s impact against these if implemented
First, to quantify the key qualities, for each one you capture:
- Name
- Unit of measurement (Scale)
- Method to measurement (Meter)
- Target level
- Fail level
WIth this information for key qualities such as Response Time, Transactions per Second, Scalability, Availability and others you can specify critical information very succinctly. This information is used by the architect and development team who must engineer the system to meet the target levels and avoid the failure levels.
So how does the architect know which design (aka strategy) to pursue that best balances performance and costs? Enter impact estimation. Once you enter the Name, Scale, Target and Fail levels for each quality, you estimate the impact of that design and enter it into the worksheet. This helps you answer questions such as:
If this design were implemented, how much closer to our target level would our system be? What % gain or reduction would we see?
How much do we think it will cost to implement the design? What’s the benefit-to-cost ratio (called performance-to-cost in impact estimation)?
How much certainty (or uncertainty) are we factoring into our estimates?
Do we have credible sources for all our input data or is it based on speculation? Have we done this before on this project or in this organization?
If we can’t reach our target level of performance with just one design, what are our next best options? How many different designs will it take to reach our target level of performance (and how much do they all cost)?
What order should we implement our designs that delivers value quickly and iteratively (in days and weeks)?
Are we factoring any risk into our designs? Are we designing just to spec or beyond spec?
These are some of the big decisions architects must face in systems engineering and represent to management with confidence. In situations with hundreds-of-thousands or millions of dollars on the line, wrong decisions can waste money and evaporate time to market. But if done right, organizations can gain quick competitive advantages by focusing their resources on designs that deliver value quickly and iteratively in an agile fashion.
Hopefully this is just the start of more handy tools to come. Let me know what you think and if you find them valuable.
