Conceptual, RCARs and AMPRS … What?

Today I gave a very quick crash course on the conceptual design portion of a VMware design, RCARs and AMPRs to a couple of co-workers at ITQ who are taking a VCAP exam on VMware EMPOWER next week.I decided to do a blogpost on this topic. So if you are taking any of the VCAP-Design exams or if you are aiming to become a VCDX, you will need to learn to live an breathe these concepts. Hopefully this blogpost explains these often hard to grasp fuzzy elements of a VMware design. But, before diving into the conceptual design itself, let’s take a step back and look at the hierarchical relationship between the conceptual, logical and physical designs.

Conceptual, Logical and Physical designs

To best explain the purpose of these three layers, I always like to introduce viewpoints or different perspectives. Let’s start with the physical design, because thats most natural to most of us techies:

Physical design

This is the portion of the design that appeals most to technical engineers. It is the “builders/engineers perspective”. It includes detailed schematics and configuration details of HOW a system needs to be built. It includes many details that are often completely irrelevant to the owner of the system.

Conceptual design

The conceptual design is completely opposite of the physical design. Technical engineers often struggle to understand this level of abstraction. Where the physical design includes detailed configuration settings, the conceptual design is all about WHY a customer is creating a new system. The conceptual design is the “owners perspective”. It includes business drivers, requirements, constraints and so on. The owner basically just wants to know what business value he or she is getting out of the project and doesn’t care about all the underlying complex calculations and schematics.

Logical design

The logical design is the magic glue between the conceptual design (WHY) and the physical design (HOW). It’s goal is to translate all the conceptual fuzziness into a fitting architectural blueprint. This is the “architects perspective”. The logical design includes weighing of pro’s (benefits) and con’s (risks) of design decisions. With just a conceptual design, several technical end solutions would be possible. With just a physical design, no justification for decisions is available and there is no traceability to business value. So, the logical design is arguably the most important portion of any design. It appeals to both the owner and the engineer/builder because both parties can understand and relate to whats being explained in the logical design.

Conceptual Design

This blogpost is about breaking down the different elements of the conceptual design, so let’s get to it:

Following the VMware design methodology, a conceptual design typically includes business drivers and RCARs (explained later):

Business drivers

An IT project should never be started without solid business justification. IT should always strive to add value to the business. It is therefore imperative to identify and clearly stipulate the business drivers that justify a project. These are most often a handful of statements that describe the desired outcome of the project in a language the business can relate to. It should explain what value is being delivered by the project (improved time to market, optimized operational expenditure and so on).

Requirements

Requirements can be divided in two main categories:

1. Functional requirements
2. Non-functional requirments

Functional requirements (FRs) describe WHAT functionality a system should deliver. Non-functional requirements (NFRs) describe HOW a system should behave. If you want to go all-out on requirements mapping, you can divide requirements using the MoSCoW methodology: Must-haves, Should-haves, Could-haves and Won’t-haves. In most of my projects, I’m not adding this additional layer of complexity in all honesty. In large-scale projects it does help you prioritize your requirements though.

A non-functional requirement often already includes part of a solution and can result in being a constraint (more on constraints later on). Within the VMware design methodology NFRs are mapped on the AMPRS framework or Design Qualities as they are also referred to.

Availability

This includes everything related to making sure the system is up and running and doesn’t fail. For example: preventing SPOFs. Availability NFRs also typically include the number of nines availability.

Manageability

All requirements that are related to HOW a system must be managed. For example: providing a single pane of glass management.

Performance

Performance NFRs relate to how well a system should respond. This can include specific IOPS requirements, response times for end users and so on.

Recoverability

Whenever a system or component fails and causes an outage, recoverability requirements dictate how and in which manner a system should recover. RPO and RTO requirements are typical recoverability NFRs.

Security

Everything related to how a system is protected and secured is mapped on the security design quality. Single-sign on and RBAC are common examples of security NFRs. These describe HOW a user should logon to the system and how they can use it).

Constraints

Constraints are what I like to call non-negotiable non-functional requirements. Bold statement: every constraint is a non-functional requirement (but not all non-functional requirements are constraints). When running requirements workshops, as an architect you are often negotiating about the requirements (functional and non-functional) that the customer is shouting out. You are always giving pushback, discussing, reasoning, finding justification and so on. Constraints are a given. You can negotiate as much as you want, they are not going away. You can – figuratively speaking – throw all the money and resources at it, the constraint is there to stay. Of course in real life, most things can be negotiated away when you trow enough money at it. So, when a requirement is non-negotiable (within reason), you are dealing with a constraint.

One other way to look at constraints is that they limit you as an architect in your design possibilities and design freedom. Even when a different solution has a better fit, but you are forced to use a less attractive option, you are dealing with a constraint. The re-use of existing hardware or use of hardware from a specific vendor due to running contracts, or limited space in the data center are frequent examples of constraints. So, in short: constraints are non-negotiable and they limit you as an architect. If a constraint introduces a risk, you should always include it as a risk in your design!

Assumptions

Assumptions are misused a lot in my opinion. On the surface it kind of looks like a very appealing escape for every tough architectural challenge. Just assume the problem isn’t there and off you go. I’ve seen designs, for example where it is absolutely clear that there is a major cooling/power shortage in the data center that is going to prevent the customer for reaching their growth target and, the simple assumption was made that there is enough room in the data center to support the estimated growth. That’s just wrong. You KNOW the problem and risk is there. It doesn’t magically disappear because you have assumed the problem doesn’t exist.

Assumptions are also misused to place certain elements of the design out of scope. This is also heavily used in the VMware Solution Enablement Toolkits design templates: proper DNS/NTP/AD services are provided by the customer. In my opinion, that’s wrong. You are able to validate the proper working of these external services so there is no need to assume they are working. They are beyond your span of control, but up to a certain point you can validate of they are working correctly or not.

Assumptions include everything necessary for your design (and the solution) that you have not yet been able to validate. Assumptions should be continuously validated throughout the project. Your goal is to have zero assumptions by the end of your design cycle. If that’s not possible, there is still a portion of uncertainty in your design so … you’ve guessed it … there must be an accompanying risk explaining what will go wrong if your assumption turns out to be wrong, and how you have mitigated against that scenario.

Note: also read my earlier blogpost on assumptions and how they can be actually very useful in real-life projects

Risks

Risks in a design primarily originate from constraints and assumptions but can also be introduced by external factors. I always like to classify a risk by scoring it against probability vs impact. Of course, all the risks that are highly probable and have a high impact should get the bulk of your attention. A risk should always explain what will go wrong, what you have done to prevent it from happening and how you are containing the fallout in case it does happen.

Summary

So in short: a conceptual design describes the owner’s view and WHY the system is being built in the first place. It focuses on the outcome and envisioned added value of the project. The logical design describes the architects view and ensures alignment between the conceptual design and the physical design. It describes WHAT is being built. Finally, the physical design describes the engineers view and HOW (according to which schematics and specifications) a system is built.

A conceptual design describes the Business drivers, Requirements (Functional – “what” and Non-functional “how”), Constraints (limitations and non-negotiable reqs), Assumptions (uncertainties) and Risks (what can go wrong). Any design should aim to deliver/fulfil on the business drivers, meet requirement, adhere to constraints, validate assumptions and minimize risks.

Non-functional requirements map to the design qualities Availability, Manageability, Performance, Recoverability and Security.

If you have any questions about this blogpost, or if you disagree with some of my viewpoints, feel free to reach out on Twitter our use the comment section below! Thanks for reading…