Technology

The Basics of Design (Part 1)

I’ve been doing design for a large part of my career and I’m not just referring to IT designs as a solutions architect.

I think my earliest memory on design was from my secondary school days. I remember building a model airplane using plastic from a household cleaning product (Vim). I started out that project by making a sketch of what I wanted the plan to look like. I think I had planned for it to have wings similar to an F-14.

In my earlier blog on 3V0-624 Preparation & Exam Experience, I mentioned that one of the things you have to learn for the exam is the basics of design. This involves the conceptual, logical and physical design.

When I first started my career in IT and had the opportunity to design a solution for a customer, I used to make the mistake of only creating a physical design or one design that covers but physical and conceptual. The VCAP design exam handles the design concepts very beautifully and I think I appreciated it more because I had done things the wrong way and this way was so much better allowing me to avoid so many issues.

For starters each aspect of the design should be signed off by the customer before proceeding to the next design. This means the customer must approve that they understand and agree with the design before the architect proceeds to the next phase.

Conceptual Design

This is the first phase and involves representing the ideas behind the solution to the problem at hand. This design comes first and follows a meeting with the customer to gather information of what their perspective is. It is where the architect tries to represent the business drivers (inputs and activities that drive business results) and constraints (decision points that have already been made and cannot be changed or what the design must have/include).

Below is a sample of what a conceptual design may look like. Some architects initially scribble this design on a paper.

Conceptual Design – P2V Conversation & Server Consolidation

The above conceptual design was something I prepared years ago to represent a customer’s requirement to convert their physical server to a virtual one. This was the first phase of their requirement.

Along with this design is categorizing the information the architect must have gathered from the first meeting into requirements, constraints, assumptions, and risks categories.

So, if I were to use the above customer scenario;

Requirements:
Applications running on physical server must be virtualized

Constraints:
The existing physical server must be utilized in the design. Meaning I must install ESXi on it. This is a constraint cos it forces me to use the server even though it may not be compatible

Risks:
There are no IT personnel in the current branch to manage infrastructure once deployed

Assumptions:
All datacenter infrastructure has already been put in place by the organization

One thought on “The Basics of Design (Part 1)

  1. This is enlightening. I was recently given a task to create a conceptual design for cloud migration, and if I came across this article earlier, I’m sure I would have done better. Thanks for this Niyi, well done.

    Like

Leave a Reply to Ayomide Cancel reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s