What are factors?

Factors represent an issue, or a requirement that has an impact on the final "cost" of a product. In electronics, a "cost" will either be an increase in monetary value of building an item, or an increase in time to delivery. "Costs" in the software domain might be -

• Cost of hardware or hosting monthly fee(s)
• Increase in time to develop or deploy
• Compensating technology required for security, or risk mitigation

This isn't a complete list, but its a good start. Our ultimate goal is to define a set of "Weighted Factors" that we will use to score a particular design option. But first, lets explore the different types of Design Options, and explore a few examples in the Software engineering domain.

Key Point: Each factor varies in how linearly it will effect the "cost" value. Higher costs are bad, lower costs are good. Costs will be normalized by the weighting scale applied to each factor to ensure one factor doesn't overly control the outcome.

Types of Factors

Binary Decision Factors

Binary factors are those constraints that are an absolute Go or No-Go. Any factor that will clearly eliminate an option should be the first criteria analyzed. If a certain criteria is met (or not met), the highest cost should be assumed - ensuring that this option can never be chosen (not without due negotiation anyway!)

Tipping Point Factors

Some factors have no "cost" impact until they pass a certain threshold. An example might be disk space use. Until your product passes the requirement to need more than 100MB of disk space, there is no cost; After that you pay a premium. These factors need to place the lowest cost on a factor, once the tipping point is reached, the factor must assume the highest cost ensuring this option cannot be chosen, otherwise this factor should be zero and not impact the rest of the decision tree.

Scaled Factors

These are general quantifiable factors. The offer a mechanism to determine (and indicate) how a factor impacts cost. E.g. Adding an extra business service layer will increase the deployment complexity and may need extra servers. We'll discuss how to formulate a scale for these factors in a future article, but in this example you can imagine that adding servers has a cost, and each extra architectural layer increases the cost accordingly.

Determining the Relevant Factors

This is the crux of the story. We need to identify the factors that we will score. There is no master list of factors to draw upon. It is important that each factor fall into a category listed above - Binary, Tipping Point or Scaled.

The basic process is to get all the stakeholders into a room and extract (brainstorm) factors that will in their opinion cause an extra cost. No factor is too small at this stage (we'll filter them later), just keep the crowd focused on identifying issues that can increase/decrease effort, cost, time and risk.

By then end of a session you should have a stack of post-it notes littering a whiteboard. Use post-it notes so that you can join and link duplicate concepts and ideas. If you involve the right people, you should end up with a big list of factors. How many are too many? Impossible to quantify, but once a list of Factors is defined, the weighting process should spotlight those factors that fall below a level that will alter any outcome. These factors can then be dropped.

I've not got a complete list, or even a recommended list at the moment. Hopefully sometime in the future I'll have something more, but for the fact of this article, here are a few I jotted down in three minutes (some overlap, some are duplicate, some can't be measured, and some don't make sense at all - all problems to look at later)-

• Bandwidth utilization
• Disk space required
• Number of Architectural Layers
• Database size
• Number of Database Objects
• Number of different development languages
• Number of different technologies
• Number of integration points
• Number of external partners integration points
• Number of config settings, and ease of changing
• Production event logging, how much, to where, how often?
• Ease of deployment
• Number of Servers
• Number of third party components
• Ease we could host at a co-located facility

In future articles, we'll look at how to take this list and refine it down to a manageable set, and how we would scale and weight each factor.

Troy.