Visualizing the Conceptual Model for IT Architecture

I have previously written about putting together the conceptual model with logical and physical design; however, I want to dig a little deeper into the conceptual model. The conceptual model categorizes the assessment findings into requirements, constraints, assumptions, and risks:

  • Business requirements are provided by key stakeholders and the goal of every solution is to achieve each of these requirements.
  • Constraints are conditions that provide boundaries to the design.
    • These often get confused with requirements, but remember that a requirement should allow the architect to evaluate multiple options and make a design decision whereas a constraint dictates the answers and removes the ability for the architect to decide.
  • Assumptions list the conditions that are believed to be true, but are not confirmed:
    • By the time of deployment, all assumptions should be validated.
  • Risks are factors that might have a negatively affect the design.
    • All risks should be mitigated, if possible.

giphy-2.gif

Requirements

Describes what should be achieved in the project; describes what the solution will look like.

  • Example: The organization should comply with Sarbanes-Oxley regulations.
  • Example: The underlying infrastructure for any service defined as strategic should support a minimum of four 9s of uptime (99.99%).

The part that tends to trip people up is functional versus non-functional requirements.

Functional Requirements

A requirement specifies a function that a system or component should perform. These may include:

  • Business Rules
  • Authentication
  • Audit Tracking
  • Certification Requirements
  • Reporting Requirements
  • Historical Data
  • Legal or Regulatory Requirements

Non-Functional Requirements

A non-functional requirement is a statement of how a system should behave. These may include:

  • Performance – Response Time, Throughput, Utilization, Static Volumetric
  • Scalability
  • Capacity
  • Availability
  • Recoverability
  • Security
  • Manageability
  • Interoperability

Often times, non-functional requirements will be laid out as constraints — the part makes this concept murkier. In the context of a VCDX design, these should typically be defined as a constraint, whereas requirements are more typically functional requirements. Be careful how you word a non-functional requirement: if it’s stated as a must and there is no room for the architect to make a decision, then it’s a constraint. But if it is a should statement is gives more than one choice for a design decision then leave it as a requirement.

Constraints

Anything that limits the design choice made by the architect. If multiple options are not available to make a design decision, then it’s a constraint.

  • Example: Due to a pre-existing vendor relationship, host hardware has already been selected.

If this is a bit difficult to grasp, don’t worry, you are in good company. This is a question that appears often.

Untitled.png

In this example, because the business dictates that HP ProLiant blade servers must be used, then it is a constraint. This leaves no room for me, as the architect, to make a design decision — it has been already made for me.

Assumptions

Assumptions are design components that are assumed to be valid without proof. Documented assumptions should be validated during the design process. This means by the time the design is implemented, there should be no assumptions.

  • Example: The datacenter uses shared (core) networking hardware across production and nonproduction infrastructures.
  • Example: The organization has sufficient network bandwidth between sites to facilitate replication.
  • Example: Security policies dictate server hardware separation between DMZ servers and internal servers.

These examples are a bit of low-hanging fruit. Don’t be afraid to dig a little bit deeper. If there’s anything documented or stated without empirical proof, then it is an assumption and needs to be validated.

Risks

A risk is anything that may prevent achieving the project goals. All risks should be mitigated with clear SOPs.

  • Example: The organization’s main datacenter contains only a single core router, which is a single point of failure.
  • Example: The proposed infrastructure leverages NFS storage, with which the storage administrators have no experience.

No design is perfect and it is important to document as many risks as you can identify. This will give you the opportunity to be prepared and craft mitigation plans. Not paying close attention here may leave the design in a vulnerable state.

Additional Examples

Can you specify which conceptual model category is correct for each example?

Category

Description

Requirement The design should provide a centralized management console to manage both data centers.
Assumption The customer provides sufficient storage capacity for building the environment.
Constraint The storage infrastructure must use existing EMC storage arrays for this project.
Requirement The platform should be able to function with project growth of 20% per year.
Assumption Active Directory is available in both sites.
Requirement Solution should leverage and integrate with existing directory services.
Risk Both server racks are subject to the same environmental hazards.
Assumption BC/DR plans will be updated to include new hardware and workloads.
Requirement The SLA is 99% uptime.
Constraint External access must be through the standard corporate VPN client.
Risk Having vMotion traffic and VM data traffic on the same physical network can lead to security vulnerability because vMotion is clear text by default.

Resources

To learn more about the enterprise architecture or the VCDX program, please join me, Brett Guarino, Paul McSharry, and Chris McCain at VMworld on Wednesday, 29 August 2018 from 11:00-11:45 to discuss “Preparing for Your VCDX Defense”.

Continued Enhancements in vSphere 6.7

vSphere 6.7 is finally upon us. It should not be a surprise that vSphere is focused on more efficient manageability, especially at scale, and increased security. These design qualities have become paramount as VMware continues to partner with public cloud vendors (AWS, Microsoft Azure) to deliver “hybrid” offerings and as more edge sites are added into the data center’s purview.

Nearly everything in the vSphere suite has gotten a minor facelift for this new release. The one upgrade consideration that caught my eye:

It is not supported to upgrade from vSphere 5.5 to vSphere 6.7. This introduces a multi-step upgrade path.

Additionally, upgrading from 6.5u2 is not currently support but will be added in future releases of 6.7.x so watch for that if it affects you. Refer to my previous blog post about architecting upgrades.

vCenter Server Appliance (vCSA)

I have long been a fan of the vCSA since its initial announcement in 5.0. I thought that combining the app and OS, putting it in VMware’s control could increase security and lead to quicker updates and innovations. Unfortunately, while consulting I found that many customers misunderstood the architecture introduced in 6.x (PSC and vCSA), which led to more confusion than upgrades.

Therefore, the road led has led to 6.7 where VMware has simplified the vCenter Server topology by now supporting vCenter Server with an embedded platform services controller running in enhanced linked mode (ELM). ELM allows customers to link multiple vCenter Servers together for increased visibility aka ‘single pane of glass’ (drink!). This change allows this architectural design decision without the complexity of external PSCs or load balancers.

vCSA

For the rest of the vCenter goodness, check out Emad Younis’ post about the rest of the vCSA enhancements.

Increased Security

In a world where cybersecurity is allocated billions of dollars of the Federal budget and ransomware attacks are commonplace, it only makes sense for companies like VMware to invest in increasing security capabilities. The heart of the vSphere platform is ESXi, therefore it makes sense to start there.

Support for Trusted Platform Module (TPM) 2.0 and the introduction of Virtual TPM 2.0 has been added with vSphere 6.7. If you are unfamiliar with TPM, it enables ESXi to verify drivers/boot components, effectively validating its image during the boot process. It measures the VMkernel with its Platform Configuration Modules to make sure the image is still authentic and hasn’t been changed.

Additionally, VM Encryption has been enhanced to make assignment of this policy a simple right-click. Moreover, encrypted vMotion for cross-vCenter migrations (including versions) addresses the age old security concern about data being migrated in clear-text.

Lastly, VMware has announced support for the entire Microsoft Virtualization Based Security portfolio. I am very interested to see how this plays out, especially as it pertains to NSX.

vSAN 6.7

It is no secret that I find storage enhancement announcements to be jejune. However, I concede that it is important to consistently improve performance, consistency, and usability.

These days, I am more interested in using APIs to interact with software. But I do believe that a simple and performant user interface is necessary in 2018. I am happy to see that vSAN has a new HTML5 UI built on the same “Clarity” framework used by other VMware products.

When vSAN iSCSI services were previously announced, I wondered when Windows Server Failover Clusters (WSFC) would be supported. That day is today. This adds to the already existing support for SQL AAG, Exchange DAG, and Oracle RAC. For organizations with WSFC servers in a physical or virtual configuration, vSAN 6.7 supports shared target storage locations when storage targets are exposed using the vSAN iSCSI service.

You can find more information about vSAN 6.7 by checking out Anthony Spiteri’s blog post.

Architecting a vSphere Upgrade

At the time of writing, there are 197 days left before vSphere 5.5 is end of life and no longer supported. I am currently in the middle of an architecture project at work and was reminded of the importance of upgrading — not just for the coolest new features, but for the business value in doing so.

giphy

Last year at VMworld, I had the pleasure of presenting a session with the indomitable Melissa Palmer entitled “Upgrading to vSphere 6.5 – the VCDX Way.” We approached the question of upgrading by using architectural principles rather than clicking ‘next’ all willy-nilly.

Planning Your Upgrade

When it comes to business justification, simply saying “it’s awesome” or “latest and greatest” simply does not cut it.

Better justification is:

  • Extended lifecycle
  • Compatibility (must upgrade to ESXi 6.5 for VSAN 6.5+)
  • vCenter Server HA to ensure RTO is met for all infrastructure components
  • VM encryption to meet XYZ compliance

It is important to approach the challenge of a large-scale upgrade using a distinct methodology. Every architect has their own take on methodology, it is unique and personal to the individual but it should be repeatable. I recommend planning the upgrade project end-to-end before beginning the implementation. That includes an initial assessment (to determine new business requirements and compliance to existing requirements) as well as a post-upgrade validation (to ensure functionality and that all requirements are being met).

There are many ways to achieve a current state analysis, such as using vRealize Operations Manager, the vSphere Optimization Assessment, VMware {code} vCheck for vSphere, etc.

I tend to work through any design by walking through the conceptual model, logical design, and then physical. If you are unfamiliar with these concepts, please take a look at this post.

An example to demonstrate:

  • Conceptual –
    • Requirement: All virtual infrastructure components should be highly available.
  • Logical –
    • Design Decision: Management should be separate from production workloads.
  • Physical –
    • Design Decision: vCenter Server HA will be used and exist within the Management cluster.

However, keep in mind that this is not a journey that you may embark on solo. It is important to include members of various teams, such as networking, storage, security, etc.

Future State Design

It is important to use the current state analysis to identify the flaws in the current design or improvements that may be made. How can upgrading allow you to solve these problems? Consider the design and use of new features or products. Not every single new feature will be applicable to your current infrastructure. Keep in mind that everything is a trade off – improving security may lead to a decrease in availability or manageability.

When is it time to re-architect the infrastructure versus re-hosting?

  • Re-host – to move from one infrastructure platform to another
  • Re-architect – to redesign, make fundamental design changes

Re-hosting is effectively “lifting-and-shifting” your VMs to a newer vSphere version. I tend to lean toward re-architecting as I view upgrades as an opportunity to revisit the architecture and make improvements. I have often found myself working in a data center and wondering “why the hell did someone design and implement storage/networking/etc. that way?” Upgrades can be the time to fix it. This option may prove to be more expensive, but, it can also be the most beneficial. Now is a good time to examine the operational cost of continuing with old architectures.

Ensure to determine key success criteria before beginning the upgrade process. Doing a proof of concept for new features may prove business value. For example, if you have a test or dev cluster, perhaps upgrade it to the newest version and demo using whatever new feature to determine relevance and functionality.

Example Upgrade Plans

Rather than rehashing examples of upgrading, embedded is a copy of our slides from VMworld which contain two examples of upgrading:

  • Upgrading from vSphere 5.5 to vSphere 6.5 with NSX, vRA, and vROPs
  • Upgrading from vSphere 6.0 to vSphere 6.5 with VSAN and Horizon

These are intended to be examples to guide you through a methodology rather than something that should be copied exactly.

Happy upgrading!

VMware Community #vAllStars

On this Thanksgiving Eve in the US, it is easy to recount the things for which I am grateful: my family, my friends, my health, etc. Monday will be 6 years since I exited from my service in the Marine Corps. At that time I was not sure I would even stay in tech as a career (law school still seems like a good backup plan). I am incredibly grateful and humbled by my career and the trajectory it has taken in recent years. A substantial part of this has been involvement in the tech community, especially the VMware community. I’m far from the only person that has built a career on the back of the VMware community. I am thankful for the guidance and inspiration I have received over the past six years.

Read More »

Catch Me at VMworld US 2017!

It’s that time of summer — VMworld US is only a few days away! Yet again I am making the trek to Las Vegas for the festivities. I wanted to highlight the sessions where I will be presenting so that you have the opportunity to either schedule and come heckle or remind yourself to watch later. I will be hanging around the vBrownBag area of VMvillage or the Rubrik booth when not presenting; come say hello!

giphy
jk, I am too pale to be outside in Las Vegas

Read More »

vBrownBag – VCAP6-DCV Design Objective 2.2

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.

Additional Resources

  • 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:

Read More »

Virtual Design Master: Conceptual, Logical, Physical

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:

C-3NztMXYAIRbF9.jpg-large
(Figure 1) Disclaimer: I’m not cool enough to have thought of this. I think all credit goes to @StevePantol.

The way I always describe and diagram design methodology is using the following image:

Screen Shot 2017-07-06 at 9.50.05 PM
(Figure 2) Mapping it all together

I will continue to refer to both images as we move forward in this post.

Conceptual

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.

For example:

 Requirements –

  1. technicloud.com should create art.
  2. The art should be durable and able to withstand years of appreciation.
  3. Art should be able to be appreciated by millions around the world.

Constraints –

  1. Art cannot be a monolithic installation piece taking up an entire floor of the museum.
  2. Art must not be so bourgeoisie that it cannot be appreciated with an untrained eye.
  3. Art must not be paint-by-numbers.

Risks –

  1. Lead IT architect at technicloud.com has no prior experience creating art.
    • Mitigation – will require art classes to be taken at local community college.
  2. Lead IT architect is left-handed which may lead to smearing of art.
    • Mitigation – IT architect will retrain as ambidextrous.

Assumptions –

  1. Art classes at community college make artists.
  2. 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”!

Logical

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 –

  1. Art will be a painting.
  2. The painting will be of a person.
  3. The person will be a woman.

For those who are having a hard time following with the art example, a tech example would be:

Screen Shot 2017-07-06 at 10.27.57 PM
(Table 1) Logical design decision example

An example of what a logical diagram may look something like this:

Picture1
(Figure 3) Logical storage diagram example

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.

Physical

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 –

  1. The painting will be a half-length portrait.
  2. The medium will be oil on a poplar panel.
  3. The woman will have brown hair.

Once again, if you hate the Mona Lisa then the IT design decision example would be:

  1. XYZ vendor and model of storage array will be purchased.
  2. Storage policy based management will be used to place VMs on the correct storage tier.
  3. 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.

Screen Shot 2017-07-06 at 10.32.54 PM
(Table 2) Physical design decision example

An example of a physical design would be something like:

phys
(Figure 4) Physical storage diagram example

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).

Final Thoughts

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.

vBrownBag – VCAP6-DCV Design Objective 2.3

vBrownBag EMEA is in the midst of recording sessions that cover the VCAP6-DCV Design (3V0-622) exam. If you are interested in presenting one of the exam objective, see the Call for Presenters post here.

Objective 1.3 –Build Availability Requirements into a vSphere 6.x Logical Design

Skills and Abilities

  • Evaluate which logical availability services can be used with a given vSphere solution.
  • Differentiate infrastructure qualities related to availability.
  • Describe the concept of redundancy and the risks associated with single points of failure
  • Explain class of nines methodology
  • Determine availability component of service level agreements (SLAs) and service level management processes
  • Determine potential availability solutions for a logical design based on customer requirements.
  • Create an availability plan, including maintenance processes.
  • Balance availability requirements with other infrastructure qualities.
  • Analyze a vSphere design and determine possible single points of failure.

Additional Resources

  • René van den Bedem’s post on “VCDX – Recoverability impacting Availability Explained”

Without further ado, the podcast recording can be found here:

macOS VCSA Installer “ovftool” Error

I recently ran into an issue with the vCenter Server Appliance (VCSA) 6.5 installer. When I proceeded to Step 5, “Set up appliance VM” I received the error:

“A problem occurred while reading the OVF file…Error: ovftool is not available.”

Screen Shot 2016-12-19 at 5.00.22 PM.png

After some research, it turns out that macOS Sierra (10.12.x) is not supported and, of course, that is the operating system of my laptop. I found a blog post from Emad Younis that outlines two possible options for working around this error.

I tried both options. Option 1 did not work for me, but Option 2 did. I’d like to take a minute and demonstrate step-by-step what I did to proceed with the VCSA deployment.

On the deployment wizard error, I selected Installer log.

Screen Shot 2016-12-19 at 5.00.22 PM copy.png

Quickly read through the log and find the error regarding the ovftoolCmd, it will state the directory that the installer is searching for the tool set. Copy that directory, sans /vcsa/ovftool/mac/ovftool.

Screen Shot 2016-12-19 at 5.01.03 PM.png

Launch the Terminal utility and type the open command for Finder to open that directory.

asdfasdf.png

For example:

open /private/var/folders/j8/ttwss5yx6cqf0flb5lrj_hww0000gn/T/AppTranslocation/

As mentioned before, leave off everything from /vcsa/ and on.

When that directory opens in Finder, you’ll notice that is it empty…therein lies the problem!

empty.png

Copy the vcsa folder into this directory.

vcsa.png

Once the vcsa folder has successfully copied, you should be able to go back to the macOS installer, press Back, and then hit Next to go back to Step 5.

Screen Shot 2016-12-19 at 5.04.47 PM.png

You should now be able to select the deployment size options and successfully proceed with the VCSA deployment.

App Volumes 2.12 – Provisioning Machine Must be Domain Joined?

App Volumes uses a provisioning machine to capture applications in order to create AppStacks. According to the App Volumes User Guide, “the provisioning of AppStacks must be performed on a clean base image…”

Screen Shot 2016-12-20 at 7.02.00 PM.png

In my opinion, a “clean base image” implies that this machine is not domain joined and therefore not inheriting any group policies.

In earlier versions of App Volumes, there was an option when initially configuring or later reconfiguring App Volumes’ Active Directory integration to “Allow non-domain entities.” This is an option that I always selected in order to have a non-domain joined provisioning machine.

Screen Shot 2016-12-20 at 4.20.18 PM.png

However, now in App Volumes 2.12, that option is no longer available.

Screen Shot 2016-12-20 at 3.09.57 PM.png

I’ve yet to figure out an option to bypass having the provisioning machine on the domain. And there’s no mention of this in the release notes.

😦