Identify discovery questions for a conceptual design (number of users, number of VMs, capacity, etc.)
- These questions are ones you are going to ask during the design workshop for the design/project. For the workshop you need to make sure you have the applicable project participants/stakeholders who can join the workshops (depends if you want one big one where people come and go at certain points or multiple ones where you speak to each business unit/ team). For the stakeholder meetings/design workshops I personally like to try bring in the following people, this does vary depending on the project and what has been chosen but 9/10 times these are the people you want to speak to:
- Virtualisation administrators (if applicable. If not already present then future administrators of the solution)
- Server Hardware Administrators
- Backup Administrators
- Storage Administrators
- Desktop/OS Administrators
- Network Administrators
- Application Administrators (these are very important as their applications may have very specific requirements)
- Security Officer
- Project Sponsors
- End users/ Help desk personnel (this I find is helpful to find out what are the current support desk tickets/problems the company are facing and if these will impact the project in any way. Also these discussions are easy to have in the hallway/over a coffee but have alerted me to unknown risks that would have severely impacted the design and delivery)
- The US vBrownbag for the VCAP5-DCD objective 1 had a great first slide on VMware’s 5 Step Design Process:
Identify the effect of product architecture, capabilities, and constraints on a conceptual design.
- I may be looking at this the wrong way but I think this is actually around how specific products architecture, capabilities and constraints isn’t applicable in a conceptual design as for a conceptual design you are only creating a “napkin” design diagram of how the whole environment is going to be delivered.
Skills and Abilities
Relate business and technical requirements to a conceptual design.
- From one of the VMware service delivery kits available to VMware partners they give a great breakdown of what requirements are and what business and technical requirements are:
- Requirement – Documented statement that depicts the requisite attributes, characteristics, or qualities of the system
- Business requirements – Describes what must be achieved for the system to provide value
- System must provide self-service capability
- System must provide x% availability
- System must provide optimal scalability and elasticity
- Technical requirements – Describes the properties of a system which allow it to fulfill the business requirements
- System requires a Web portal where users can log in securely and deploy virtual machines based on defined policies
- System must have fully redundant components throughout entire stack (host, network, storage)
- System leverages virtualization technology and associated features
- As mentioned these requirements will be gleamed from the Design Workshops/Stakeholder meetings and then put into the conceptual design. This is where you would work out if the customer requires a private, hybrid, public or even community cloud deployment. For example if the customer requires certain data to remain in a country for regulatory reasons then in the conceptual design you know compute resources, networking and connectivity between that country and the primary site need to be available. The speeds, number of hosts, make of hosts and amount of memory and vCPU are not in the conceptual design as this is the “napkin” design just covering the concept of how it will all work out and may actually change once you get to the logical and physical designs.
- Some example business requirements a customer may have which are ones I did for my VCAP5-DCD Design Practice are :
|R001||Virtualise the existing 6000 UK servers as virtual machines, with no degradation in performance when compared to current physical workloads|
|R002||To provide an infrastructure that can provide 99.7% availability or better|
|R003||The overall anticipated cost of ownership should be reduced after deployment|
|R004||Users to experience as close to zero performance impact when migrating from the physical infrastructure to the virtual infrastructure|
|R005||Design must maintain simplicity where possible to allow existing operations teams to manage the new environments|
|R006||Granular access control rights must be implemented throughout the infrastructure to ensure the highest levels of security|
|R007||Design should be resilient and provide the highest levels of availability where possible whilst keeping costs to a minimum|
|R008||The design must incorporate DR and BC practices to ensure no loss of data is achieved|
|R009||Management components must secured with the highest level of security|
|R010||Design must take into account VMware best practices for all components in the design as well as vendor best practices where applicable|
- For Technical Requirements a great way of doing it is to break them down into sections like:
- Virtual Datacentre Requirements – eg: Allocation model Virtual Datacenters reserves 75% of CPU and memory
- Availability Requirements – eg: VMware vCloud Director (clustering, load balancing)
- Network Requirements – eg: Organizations have the ability to provision vApp networks
- Storage Requirements – eg: Different tiers of storage resources must be available to the customer (Tier 1 = Gold, Tier 2 = Silver, Tier 3 = Bronze)
- Catalogue Requirements – eg: Catalog items are stored on a dedicated virtual datacenter and dedicated storage
- SLA Requirements – eg: SLA Requirement #1 – Networking 100%
- Security Requirements – eg: Organizations are isolated from each other
- Management Requirements – eg: Only technical staff uses remote console access
- Metering Requirements – eg: Metering solution must monitor vApp power states for PAYG
- Compliance Requirements– eg: Solution must comply with PCI standards
- Tenant Requirements – eg: Customer requires the ability to fence off vApp deployments
- To make sure you are doing the design in a VCDX-like manner which should push you to do it at a very high level, don’t forget to refine the customer-specific technical requirements and validate that they are specific, measurable, accurate, realistic, and testable (SMART).
Gather customer inventory data.
- This is what is going to be on the new vCloud system whether it is existing workloads or new workloads. A good way of getting this if the customer allows it is to run a VMware Capacity Planner collection on the existing workloads that are going to be migrated in so you know sizes, I/O and current state analysis values. The Capacity Planner can only be run by VMware partners so if this isn’t possible for you then manual collection and recording is going to be required. Another method is via the VMware vCloud Planner which is another tool only available to VMware Partners so maybe getting a VMware partner in to do this for you prior to the project running would be a good idea
- Also knowing what the customer already has can help you understand possible future constraints for example that all their current servers are IBM and so this is likely to be the server platform for this design.
- There may also be a requirement to use existing legacy physical kit already present in the datacentre which needs to be recorded and fully understood so that the risks and constraints of using this infrastructure are fully understood. For example if you are using legacy network switches which can’t do stretched VLANs this will impact your design substantially if you have two sites and a requirement for the Management cluster to be failed over/migrated in the event of a disaster.
Determine customer business goals.
- This is plainly what is the customer looking to gain from the deployment of this solution? At the end of the project what do they hope to achieve? These are sometimes not as clear as you may hope as people have different ideas of what they want the solution to achieve so as the architect you will need to take all these business requirements, set expectations if they are unrealistic due to varying reasons like cost or pre-selected hardware and then define them and get sign off from the customer that they agree to these before any additional work is done. This is very important as if these aren’t defined and agreed to by the customer then scope creep can happen which could cause the project to fail.
Identify requirements, constraints, risks, and assumptions.
- I’m not going to go into great depth here as I think the definitions of each will give you a good idea of what each is. During the design workshops/stakeholder meetings these are worked out, recorded and agreed to by the customer. Always remember that for any design you need to collect all of these and then look at it in a holistic manner and understand the impacts of each decision.
- Requirements – Documented statement that depicts the requisite attributes, characteristics, or qualities of the system. See above portions around Business and Technical requirements plus the examples.
- Constraints – Requirements that restrict the amount of freedom in developing the design
- Hardware which already exists and must be used (for example,host or storage array)
- Physical limitations (distance between sites, datacenter space)
- Cost $$$
- Risks – Potential issues that may negatively impact the reliability of the design
- Lack of redundancy for specific hardware component
- Support staff has not had any training
- Assumptions – Suppositions made during the design process regarding the expected usage and implementation of a system
- Provides a sounding board for design decisions which must be validated
- Hardware required is installed before vCloud implementation
- Network bandwidth is not a limiting factor for external end users
- Appropriate training is provided to existing technical staff
- For assumptions and risks I like to get these highlighted to the customer right away as you normally don’t want any assumptions if possible and for the assumptions you record in your design you want these to be realistically clarified already so that the assumptions are only there to ensure that if what they promised would be there isn’t you can refer them to the assumptions they signed off.
Given customer requirements and product capabilities, determine the impact to a conceptual design.
- This I think is covered above in places but is also something you can only really learn from actually doing a design and understanding how requirements shape a design and what impacts each of them have. On a conceptual design it isn’t as much of an impact as in a logical and physical design but limitations like keeping workloads in specific geographies and the capability of vCloud stretched clusters between the two locations for example are something that will impact the conceptual design. I would also read the Service definitions listed below in the recommended tools from the blueprint and the implementation examples from the vCAT.
- Functional vs. Non-Functional Requirements
- Conceptual, Logical, Physical: It is Simple
- Private VMware vCloud Service Definition – This is in the vCAT
- Public VMware vCloud Service Definition – This is in the vCAT
- Hybrid VMware vCloud Use Case – This is in the vCAT
- Product Documentation
If you feel I have missed something or am wrong on something then please do comment as I don’t proclaim to be the best and am always learning and welcome constructive criticism and feedback