The next set of activities in the engineering design process can be called "transformation." That is, the effort to transform the problem at hand into something solvable, moving from the unfamiliar to the familiar. We're adding progressively more structure as we move through the phases.

In this phase, we may begin to see pressures from the customer to produce. Be sensitive to that, while relating the problems to the long-term strategy or architecture framework under which you work. After the problem analysis, the customer may expect a fully-formed solution to just pop out. Manage those expectations early in the design process.

The guiding question in this phase is, "Have we solved this problem or something similar to this before?"

By answering that question, we decide whether we will be able to leverage prior efforts, avoid prior mistakes, or perhaps do both. Both of these allow us to move the problems toward solutions more quickly and hopefully in a more cost-effective way than blazing a new trail, although that too might be required.

To leverage prior efforts, we have to discern patterns in the problem that fit the work we've done before. Some examples of patterns in the SysAdmin world might be batch-processing, sessions, synchronous versus asynchronous communication, or layered security. These patterns are part of the problem domain that we noted in the analysis phase. The domain will have basic classes of objects and formalizes the heirarchy of those objects. As I noted in the first article in this series, the body of knowledge that might document this domain heirarchy is still not fully mature in much of the IT industry.

This problem seems brand-new, something you've never tackled? Working with the customer, manipulate it a bit:

Can the problem be:

• Redefined - Do you need to design a dedicated widget or service to fit the need? Does the customer know that we already offer a similar service, scaled for X (where X is some number of transactions/time, amount of user traffic, amount of records) and ready today? Examples might be authentication, mail transport, indexing/search functions, or publishing.
• Rearranged - Can we "start small?" Do we commit full resources to the solution if the outcome (traffic estimates, sales, customer uptake, etc) are unknown or sketchy in some way? Can some features go into a "version 2.0?"
• Regrouped - Given the answers to the two questions above, can we consolidate or change the groupings of the sub-problems to fit a known pattern? Is batch-processing sufficient or do we need real-time output?

At the end of this phase, you now have all of the definition and analysis necessary to begin idea development. You have eliminated duplications and are able to leverage prior work and existing systems. With this, you've reduced your problem size and hopefully complexity.

Past articles in this series:

1. Analysis - Breaking It Down
2. What Is It We're Doing Here? - Applying Engineering Principles To System Administration
3. Who Is It? - Defining Who Might Benefit

Technorati Tags: system administration

Tags: on technorati, delicious, netscape, google