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.

In electronics design, many elements can directly impact the cost of manufacturing a product. DfM aimed to move the tradeoff analysis for decisions affecting manufacturing as early as possible in a design phase. I'll attempt to move this into the software architecture realm in a future article, but for now I want to explain how this worked in Electronic Product design.

What design decision matter in Electronics?

In electronic product design, here are a few to start your thought process -

Component Selection - Choosing components from an approved supplier and components that meet requirements but don't exceed specification (giving latitude to safety margins) directly impact cost of an item. Assisting engineers choose preferred part, parts already purchased and in inventory, and offering alternatives can really decrease costs and improve turnaround time.

Printed Circuit Board Size and Shape - Small PCB's aren't made one at a time. They are panelized onto larger sheets, fabricated and even assembled (components positioned and soldered into place) in that form before being broken apart and put into their cases. The more individual boards you can fit to a panel, the less waste and fewer panels need to be moved through auto-assembly equipment.

Printed Circuit Board Technology - If you make the board smaller to fit a certain device, you often need to add 'layers' for interconnecting components. This adds cost; If you make individual features smaller to fit more interconnects onto fewer layers, the manufacturing yield decreases due to mis-registrations. Its a real trade-off and highly dependent on your partners capabilities.

Printed Circuit Board Hole Count and Sizes - For some PCB technologies, drilling holes can be time consuming. Smaller holes needs to be positioned more accurately and these drill bits break more often. Normally, fewer holes of larger sizes is the cheapest way to go; However, some PCB technologies don't incur a cost per hole - which one will you specify?

Component Placement - Where is it safe to put large components? Where will the battery connect? Where are the pushbuttons? All of these decisions need to be considered when the PCB is being designed - BUT they seriously impact the final case design. How can the electronics designers and the mechanical (and brand) designers collaborate to agree on an acceptable design? For extremely high volume designs, placing similar components in the same orientation can reduce the number of machine rotations and component reel changes which reduces the total time of assembly. Saving 1 minute for 1 million pieces is substantial!

Early Focus and Scoring Matrix Definition

Design for Manufacture initiatives aimed to bring focus on the types of decisions made above and allow engineers and designers to perform trade-off analysis as early as possible in the process. The product might have to be smaller than a competitors and that forces a smaller PCB size and shape, which then causes a specific choice of technology - However, the key aim was to understand that early and make informed choices about which remaining options fulfill the global good.

To build a Report Card or Scoring Matrix, the basic process is -

1. Get together with all of your partners, suppliers, fabricators and designers and brainstorm a set of issues that impact cost. Similar to the list provided above, the idea is to get the 'issues list' on the table.
2. Group these issues into a sub-set that can actually be measured and scored. E.g. "Number of boards per panel", "Number of holes smaller than 0.5mm", "Number of different components types", etc.
3. Determine relative weighting for each measurement. Some requirements cannot be broken, other just incur a cost. I'll propose a process for determining this weighting in a future article; for now, just understand they won't all have the same weighting factor.
4. Build the scoring scale for each factor. This step tries to normalize the different scales of measurements into a smaller linear set (i.e. 1 to 5, rather than 1 to 1 million for one factor, and 1 to 10 for another)
5. Calibrate the scorecard by testing on existing systems. Agree and alter the specific factor "Weightings" until you gain confidence in the scorecard
6. Use the scorecard on future design discussions.

Summary

Is it just as simple as substituting "IT Operations" for "Fabricators"; "Usability/Interactive Designers" for "Packaging Designers"; "External Hosting Partners" for "Suppliers"? 

In future articles i'll look deeper into -

• How to build a weighted score card based on issues relevant to software
• Propose some software specific issues and attempt to weight those appropriately
• Test our new scorecard and determine if it is achieving the goal we intended.

Be interested in comments as to whether other people agree there might by parity between DfM in Electronics to DfM in Software.

Troy.

I started out in the electronics engineering field, and moved into the software side of electronics design automation business shortly after that. Back in the early 1990's a lot of effort was being put into Design for Manufacturing. This was in the recognition that very small decisions made early by an isolated engineer, could have massive consequences down the road impacting costs. There were a few leaders and advocates in the field, mainly from HP and IBM at the time.

One incident recalled by Happy Holder, a HP engineer at that time was the reduction in cost of the HP Laserjet III printers. By altering the size of the main printed circuit board size by a few inches one way, they were able to double the production yield of that assembly, halving the raw material cost of the PCB. Happy Holden and IBM's Tucker Garrison at the time came up with a few simple methods for evaluating designs and allocating a report card. The most complex part of the process was getting the right people in the room to agree on the right criteria to measure, and to weight those measurements in the right way.

Manufacturing optimization comes down to improving production yield (reducing waste) and speeding up the process (reducing touch time); These principles are well known to all those proponents of Lean Manufacturing and Theory of Constraints. This book is a good start - Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results (The Coad Series).

Is software yield (throughput) equivalent to DFM for Electronics "Speeding up the process"? The aforementioned books clearly describes the process of improving throughput by reducing the waste and understanding the current blocking issues. But I cannot find a process that brings focus of the cost of decisions back to the earliest possible decision point, when it is relatively simple to move many directions.

It seems obvious there is room for innovation here. Provide a framework (what DFM calls report cards) that developers and architects can use to assess possible solutions and designs for a requirement. I plan over the next few weeks to explain how the Electronics DFM process worked, and suggest a few techniques that might improve our up-front decision making process.

Troy.

How much up-front design or architecture to do in an agile project is always a contentious issue. Having the job title with "Architect" in it makes me personally biased; Having a background as a developer and product manager in successful agile XP gives me a huge respect for agile development practices and somewhat balances my development approach. This posting tries to define my current view on how to balance good up-front architectural planning (minimal, but where it counts) and how to assess whether more or less architectural oversight needs to be applied during a project through intervention.

Many agile scenarios promote that a project be split in a set of features; These features prioritized into milestones by the "Customer" and then these features be worked in in almost a serialized fashion. The focus is on completing the current feature, whilst promoting that refactoring be the tool of choice when a later feature adds or alters a previously signed-off complete and closed item.

I can see some issues with this when followed blindly. My definition of "Refactoring" centers on improving currently functional code with lessons that emerge throughout a project. What I see in many projects is that "Refactoring" is the title given to an almost rewriting of a previously closed feature because the number and scope of changes to keep it operating in the face of the new feature. This is bad, and it is seriously affecting development velocity.

Here is my proposed compromise, that allows features to be built in (semi)-ignorance of future features, whilst still allowing for intervention if a pattern of serious re-writing (or refactoring if you want to water the terminology  down) begins to affect velocity -

• Up-front architecture that should always be carried out as iteration 0 of any project includes anything that WILL BE NEEDED for EVERY feature (or requirements that will cause a registration of almost every feature that has already been completed). This includes technology choices, communication and integration patterns, operational requirements like logging, deployment strategy and localization requirements can be used as a starting list.
• At regular intervals (e.g. 1/4, 1/3, 1/2, 2/3, 3/4) of the way through features in a project analyze the task breakdowns of the latter features to determine if there is a class of task that might be eliminated by an architectural building block or by more holistic design/planning

It is the second bullet point I want to discuss further in this posting.

My boss David Anderson run a pretty tight Lean Software software development department. A lot of the lean principles are facilitated by using a Kanban tracking system (and its electronic counterpart being the data captured in Microsoft TFS). The data captured is very thorough and used as a management tool in determining progress, bottlenecks and general project health. My goal is to use the feature and tasks completed so far to assist in determining where architectural intervention or more up-front planning could avoid that class of task being necessary in future work.

Lets look at an example - In a current project that is very integration heavy with a large ERP/CRM system, that our lack of solid planning for the interface specifications (which weren't ready when we started, but are available now) is cause way too much rework as we move through the features in a linear fashion. It way pay dividends in team velocity to introduce a feature right now that looks at the spectrum of interface specifications we now have and strawman the entire message / web service interfaces. If this reduces the number of tasks in future feature that would have revisited completed interfaces and added that extra field, or changed that database schema - improved velocity is inevitable.

But there is a balance - striving for perfection in this planning intervention would also be catastrophic to feature completion velocity. Going overboard with architecture is just as evil as sticking ones head in the sand and simply working longer hours or hiring more developers to close the backlog gap.

Be interested if other teams have analyzed task types to look for patterns or work that might be eliminated by a targeted architectural focus.

Troy.

How can we put a price on or demonstrate one system architecture against a proposed (or actual) new system architecture? For instance, how can we predict in advance if a major project is going to require a reduction of increase of staff to maintain? Or is it more important that a proposed architecture position a company in a position where it can respond to market pressures with more agility?

I'm currently trying to generate such number to assist our management team with real factual data to support decisions. My problem is - I can't find a lot of material on this subject via Google! So I'm throwing it out there to you guys to give me some ideas.

Here is my basic approach -

1) Find facts we can measure about the hardware environment pre and post project

2) Find facts we can measure about the software architecture pre and post project

3) Segment the companies over 120 software assets into major groupings of 5 areas (trying to analyze 120 product is too fine grained to be of interest).

4) Put all this data into excel, and do a weighted scale matrix for each measure. Total, Graph and Summarize...

I think it will turn out to be easy to demonstrate a "Better" or "Worse" indicator; But I want more - I want an actual score indicator that we can use to determine cost of ownership over time. I want to demonstrate a payback on investment in software architecture that may not be demonstrable through a sexy new website feature.

For the moment - I'm still looking at what variables we can measure (Steps 1 and 2 above). System measurement is basic enough - number of servers, number of upgrades per year, number of helpdesk calls. However software architecture become a little more interesting. Recently I did a quick option analysis and came up with three easier metrics to compare three architectural solutions.

What other metrics have people considered or used in the past when scoring software architecture?

Troy.