Job interviews are tough. It’s the equivalent of both parties deciding whether they want to get married during the first date. So, imagine my surprise when Thom Greene asked me to conduct a mock interview with him in preparation for his job hunt. Thom was game enough to even allow me to record it as a vBrownBag session.Read More »
vBrownBag EMEA is in the midst of recording sessions that cover the VCAP6-DCV Deploy (3V0-622) exam. If you are interested in presenting one of the exam objective, see the Call for Presenters post here.
Objective 2.2 – Map Service Dependencies
Skills and Abilities
- Evaluate dependencies for infrastructure and application services that will be included in a vSphere design.
- Create Entity Relationship Diagrams that map service relationships and dependencies.
- Analyze interfaces to be used with new and existing business processes.
- Determine service dependencies for logical components.
- Include service dependencies in a vSphere 6.x Logical Design.
- Analyze services to identify upstream and downstream service dependencies.
- Navigate logical components and their interdependencies and make decisions based upon all service relationships.
- Graham’s blog post on Objective 2.2.
- Don Ward’s post called “VMware Application Dependencies and Entity Relationship Diagrams”
Without further ado, the podcast recording can be found here:
Nutanix does not want to be known for simply hyper-converged infrastructure. That was made very clear during Nutanix’s .NEXT conference in Washington DC two weeks ago. As Trevor Pott said in a recent article from The Register, “if all you’ve got to sell is HCI, then your company is already dead.” Nutanix is choosing to evolve rather than die.Read More »
This year I am honored to be one of the Virtual Design Master (vDM) judges. If you are unfamiliar with vDM, it is a technology driven reality competition that showcases virtualization community member and their talents as architects. Some competitors are seasoned architect while others are just beginning their design journey. To find out more information, please click here. One of the things that I, along with the other judges, noticed is that many of the contestants did not correctly document conceptual, logical, and physical design.
The best non-IT example that I have seen of this concept the following image:
The way I always describe and diagram design methodology is using the following image:
I will continue to refer to both images as we move forward in this post.
During the assess phase, the architect reaches out to the business’ key stakeholders for the project and explore what each need and want to get out of the project. The job is to identify key constraints and the business requirements that should be met for the design, deploy, and validation phases to be successful.
The assessment phase typically coincides with building the conceptual model of a design. Effectively, the conceptual model categorizes the assessment findings into requirements, constraints, assumptions, and risks categories.
- technicloud.com should create art.
- The art should be durable and able to withstand years of appreciation.
- Art should be able to be appreciated by millions around the world.
- Art cannot be a monolithic installation piece taking up an entire floor of the museum.
- Art must not be so bourgeoisie that it cannot be appreciated with an untrained eye.
- Art must not be paint-by-numbers.
- Lead IT architect at technicloud.com has no prior experience creating art.
- Mitigation – will require art classes to be taken at local community college.
- Lead IT architect is left-handed which may lead to smearing of art.
- Mitigation – IT architect will retrain as ambidextrous.
- Art classes at community college make artists.
- Museum will provide security as to ensure art appreciators do not damage artwork.
As you read through the requirements and constraints, the idea of how the design should look should be getting clearer and clearer. More risks and assumptions will be added as design decisions are made and the impact is analyzed. Notice that the conceptual model was made up entirely of words? Emphasis on “concept” in the word “conceptual”!
Once the conceptual model is built out, the architect moves into the logical design phrase (which indicated by the arrows pointing backwards in Figure 2, demonstrating dependence on conceptual). Logical design is where the architect begins making decisions but at a higher level.
Logical art work design decisions –
- Art will be a painting.
- The painting will be of a person.
- The person will be a woman.
For those who are having a hard time following with the art example, a tech example would be:
An example of what a logical diagram may look something like this:
Notice that these are ‘higher’ level decisions and diagrams. We’re not quite to filling in the details yet when working on logical design. However, note that these design decisions should map back to the conceptual model.
Once the logical design has been mapped out, architect moves to physical design where hardware and software vendors are chosen and configuration specifications are made. Simply put, this is the phase where the details are determined.
Physical art work design decisions –
- The painting will be a half-length portrait.
- The medium will be oil on a poplar panel.
- The woman will have brown hair.
Once again, if you hate the Mona Lisa then the IT design decision example would be:
- XYZ vendor and model of storage array will be purchased.
- Storage policy based management will be used to place VMs on the correct storage tier.
- Tier-1 LUNs will be replicated hourly.
These are physical design decisions, which directly correlate and extend the logical design decisions with more information. But, again, at the end of the day, this should all tie back to meeting the business requirements.
An example of a physical design would be something like:
Notice that in this diagram, we’re starting to see more details: vendor, model, how things are connected, etc. Remember that physical should expand on logical design decisions and fill in the blanks. At the end of the day, both logical and physical design decisions should map back to meeting the business requirements set forth in the conceptual model (as evidenced by Figure 2).
Being able to quickly and easily distinguish takes time and practice. I am hoping this clarifies some of the mystery and confusion surrounding this idea. Looking forward to seeing more vDM submissions next week.