Conceptual Designs

When designing an IT solution for your business, an early major step is the creation of the Conceptual Design.  This design typically includes tables of requirements, constraints, assumptions, and risks.  It contains one or more block level diagrams that illustrates the key functions, personas, management operations, data entities, infrastructure, etc of the conceived solution. It should map each requirement to components in the diagram that addresses the requirement.

A good Requirements table contains an ID and a description of the requirement.  Each requirement is an item that the solution must meet. Some requirements are functional, which describe something the solution must do. Others are technical and address one of the factors of any good system design, such as manageability, security, usability, or availability. Here are some example requirements that may be included in a Disaster Recovery (DR) Solution Conceptual Design.

Likewise, a Constraints table contains similar columns.  Each constraint is something that limits potential design choices.  It is something that must be “designed around”.  For example, a potential constraint in a DR solution could be that no additional storage may be procured for the solution.

A solid Risks table provides an ID, Description, and Mitigation Plan for each identified risk.  A risk could describe something that could go wrong with the final solution, like the failure of a specific component.  In this case the mitigation may involve automatic failover to a redundant component.  Typically, risks like these are actually covered in the Requirements table of the Conceptual Design, while the Risks table covers those that impact the quality or success of the design. For example, consider a scenario  in a DR Design where a requirement is to protect up to 100 virtual machines. You have a risk that any projections for the total size of the virtual disks and the daily data change rate  may be significantly lower than what is actually realized.  If the numbers used to size the DR solution are wrong, the risk is that the DR solution cannot meet the specified RPO / RTO.  A Mitigation Plan could be to trigger alerts proactively indicating that projections are soon to be exceeded.  In the design’s operating procedure, you could include steps for addressing such alerts, such as adding more replication nodes.

The Conceptual Design should contain a table describing key personas and their roles.  For example, the Persona Table for a DR solution may describe DR Administrators, Virtual Machine Administrators, Application Owners, Storage Administrators, Managers, and others.  The Conceptual Design may include an operations table that maps specific tasks to specific personas.  For example, a business’ Vice President persona may be responsible for declaring a disaster and launching the execution of a recovery plan. An application owner may be responsible for executing a DR test.

Click here for more details and help with building DR Conceptual Designs.