There have been a number of articles of late on systems architecture all with the tag VCDX. While I appreciate using that tag on my posts gets me 40% more hits it would like to focus on the larger concepts of systems architecture. I am a VCDX certified person but really all that does is validate my ability to design systems architecture. I have also have the pleasure of mentoring other VCDX candidates. This has allowed me to meet some very talented people and learn from them as much as they may learn from me. One common challenge faced by almost all systems engineers switching to architecture is the concept of conceptual, logical and physical diagrams and design. I also struggled with these concepts. Every systems engineer lives in the physical world. It’s 100% details in order to get the work complete. Product names, commands and hardware configuration are the realm of most systems engineers.
What is the definition of each?
The best definition of each layer is the article by Zachman here. This is referenced in every Datacenter design test by VMware and is by far the best description. I personally like one line answers so let me give you mine:
- Conceptual – Explanation of what the solution should do in terms that your non-technical significant other can understand – In my case my wife had to understand what the solution should do by this design
- Logical – Should interconnect between elements without specific products – defines how they should do it – if you have product names on the logical design you might not be doing it correctly
- Physical – Detailed description of solution with products and interactions
Why do I need conceptual?
Conceptual takes business requirements and translates them into something consumable by the business and technical folks. They should show what the solution should do. No products or technical details just business. This would seem like a waste of time for technical folks who say I know what it does… This is a failure to understand that the conceptual design is your get out of jail free card. When combined with requirements and constraints the conceptual design allows you to design as you please with the blessing of the business unit. It should show all their requirements and get their sign off before you pass to logical.
Why do I need logical?
Logical is created the start to show interactions between components. It is critical because it get’s you thinking about everything required to complete the solution. Do I need a database? Do I need redundancy? How do I create redundancy? etc… Get the logical on paper and it will get you thinking about the things you missed. Why does the logical not have product names? Because you should not choose products until you get to physical design. You should design to meet the customers requirements not the products limitations. It is possible that you do have product limits due to constraints but they should not limit the logical design too much. Logical is about connections, communication and figuring out the scope of the problem while providing the how does the solution work.
Why do I need Physical?
Because without physical it will not work. Why can’t I turn the physical over to the implementers? … You can but they may not benefit from the exercise you did going through conceptual and logical.
An Example to learn this process
Last weekend I attended a school event with my daughter. They have a new stem program that teaches critical thinking. Once of the showcase activities was a design challenge. It was interesting to see how my daughters (8 and 5) approached design. The design challenge was as follows:
Using the following ingredients create a vehicle that can move by the power of air:
- 4 Life savers
- 2 Staws
- Paper
- 2 Paper Clips
- Scotch Tape
So from a design perspective we have the following:
Requirements
- Must be a vehicle
- Move by the power of air
Constraints
- We have limited ingredients
Assumptions
- The power of air means your breath
- There is no need to carry any load on this vehicle
Approach on design
I was determined to not get involved in guiding. I wanted to watch them learn from the experience so no parent interaction.
Five year old – Her approach was simple grab straws and start cutting the first side of her car, she taped a lot and stuck thing together. She went straight to physical design with the raw materials
Eight year old – Her approach was a little more thoughtful. She gathered her ingredients and looked at them. She held the straws in different positions and sketched them out on the paper. She created a logical design. Showing how she planned on getting the sail into the design.
Five year old – She completed the car portion very quickly and was impressed with her rolling car… but had missed the requirement to have it move by air… her attempts to blow on her car proved that it would not move. She was able to push the car and was pleased by it. I reminded her that a requirement was it move by air. She had cut most of her straws and now had a true design challenge.
Eight year old – Completed her build including a sail and tested it to prove it was working
Five year old – cut an odd sail out of paper and taped it on the boat to find it would not move it forward very well.
This little exercise proved something to me I have seen many times in my career. Systems architecture should be about 90% planning and 10% execution or you spend at least double the amount of time trying to execute and re-engineer. I know planning and documenting is boring work but it does cut down on frustration and improve the overall product. It will remove the simple mistakes. I highly suggest you try a conceptual, logical physical design model for your next project.
Thanks for so easy explanation!!! I loved the sample, really loved!