- Quality of Design
- The Intelligent Architectures Archetypes in Detail
- Archetype Attributes
- Combining Archetypes Into Designs
- Structured Design vs. Ad Hoc Design
- Summary
- Acknowledgements
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Structured Design vs. Ad Hoc Design
Structured design refers to identifying and understanding all of the factors that affect a design, as well as all requirements, prior to design.
While ad hoc design is structured, its structure isn't planned in advance. To take an example from outside the IT industry, most cities in the world are the result of ad hoc design. In most cases, cities developed over time without a single plan defining the entire city. It must be stressed that ad hoc design is not chaos and it should not be used as an excuse to "just let things happen." As with the example of the growth of a city, buildings are not built haphazardly, and most, if not all, cities have zoning and building requirements.
It may be obvious that a structured design is a near impossibility in the real world. Rarely are system architects presented with a complete set of detailed system requirements from which to design a system. Especially in the case of a system redesign or remodeling, a system architect is given a rough and incomplete set of requirements and a set of constraints to work within.
As with the experienced system architects approach to combining archetypes and resolving the dual nature of some archetypes, the experienced system architect will employ a dualistic design methodology.
System architect's experience will guide them through concurrently applying both a structured approach and an ad hoc approach. The structured approach will be used in those areas where the requirements or implementation issues are well-defined or well- understood. When confronted with a problem area that is poorly defined or without hard requirements, system architects will switch to an ad hoc approach. This helps enable system architects to "fill in the gaps" in the requirements or problems definition.
As with many things, this ability, or the knowledge required to determine when to apply it's use, comes only from attempting to architect systems and from making mistakes.
The concept of switching between these two design approaches is easily understood. However, knowing when to switch from one process to the other during the design process, as well as knowing what requirements are essential, comes only with practice.
To illustrate this, consider the need to architect a highly available mail and messaging server based on the Solaris™ 8 Operating Environment and iPlanet™ Message Server 5.1 software.
The crucial areas of this problem area require you to consider the following:
What are the availability requirements of this service?
What are the availability expectations of the users of this service? ("Do I need to meet the expectations of my users or do I need to provide 24x7 service?")
What, if any, service or response time guarantees have been made?
What are the users privacy expectations, what privacy guarantees have been made or implied, and how secure must the service and data be?
What, if any, are the backup, data restore, and data retention needs? (This will help determine the backup schedule, restore requirements, and business continuity planning).
On what scale is this to be implemented (hundreds of users, thousands of users, millions?)
The previous questions serve to determine the "hard requirements" that must be met. These hard requirements define the structure which can then be filled in by choosing components from the archetypes.
The hard requirements will help determine if an HA framework, such as Sun Cluster 3.0 software, is necessary to meet the availability requirements. Hard requirements will also help determine the attributes that the archetypes must take, as well as any required inter-relationship between those archetypes. For example, by questioning the number of users and required response time, you can determine the capacity attribute of the Data Store and the Data Manipulation archetypes.
After these design points have been addressed, a more ad hoc approach can be used to fill out the rest of the design. These ad hoc design items include determining the process and documentation attributes, identifying serviceability and recovery attributes (which can also be used to provide a run book for the service), and specifying the criteria for the monitoring and measurement attributes.