Study guide
My target this month to attend to VCAP7-DTM Design exam. The following study material will be used for my preparation which. Based on the latest exam blue print:
Section 1 – Create Horizon Conceptual Design
Objective 1.1 – Gather and analyze requirements
Objective 1.2 – Gather
and analyze application requirements
Objective 1.3 –
Differentiate requirements, risks, constraints and assumptions
Objective 1.4 – Evaluate
existing business practices against established use cases
Let us understand these terms in EUC concept, our target to become Design expert in EUC , so all discussions here will be related to design VMware Horizon solutions , products, techniques and integrations from design perspective and under EUC or VMware Desktop and Mobility umbrella
So any project or solution need to be designed correctly , otherwise we would get unexpected results , the design phase include 3 stages of designs :
- Conceptual Design
- Logical Design
- Physical Design
We start with Requirements Gathering to start build our cases and design , technically this would be done through design workshops, Interviews and Surveys with Stakeholder and technical teams who can provide information about the design requirements , the inputs from these workshops will results in:
- Solution Requirements :A requirement can be defined as a need that must be met, Any project’s requirements need to be well thought out, balanced and clearly understood by all involved, the requirements can be Functional and can be Non-Functional requirements
Functional requirements specify specific behavior or functions in otherer wards “what system must do or accomplish”, for example:
Some of the more typical functional requirements include:
- Business Rules
- Transaction corrections, adjustments and cancellations
- Administrative functions
- Authentication
- Authorization levels
- Audit Tracking
- External Interfaces
- Certification Requirements
- Reporting Requirements
- Historical Data
- Legal or Regulatory Requirements
For our EUC design functional requirements can be :
- Users must be able to access the system from within the corporate
- System should not be accessible from internet
- Applications XYZ must be accessible to users only in a specified group
- There must be no single points of failure
- Solution must comply with ISO standards
The other one is Non-Functional Requirements which is simply the characteristics of a solution in other wards it describe how the system works, Some typical non-functional requirements are:
- Performance
- Scalability
- Capacity
- Availability
- Reliability
- Recoverability
- Maintainability
- Serviceability
- Security
- Regulatory
- Manageability
- Environmental
- Data Integrity
- Usability
- Interoperability
For EUC such requirements can be :
- Solution up time 99.9%
- Consider 30% expansion for future use
- The RPO for solution should not exceed 1 hour
- Consider high viability for all solution component
- Log on times should not exceed 30 seconds
- Gather and analyze application requirements: we need to know and to
understand the application requirements in general , these applications can be:
- Business applications (ERP)
- Default applications (MS Office, browsers )
- Utilities and tools
- Printing solutions
- 3D graphic application
- Endpoint protect solutions as Antiviruses
- Operating system (windows 7, 10)
And applications requirements need to cover :
- What is the
current application involved in our solution
- License model for application
- Is it new, old ,or legacy application
- How many user can access each application
- The backend service for these apps
- Criticality for each app
- Whist is the limitation in thee apps
- Dose it need special hardware access
- Dose it need GPU
- What is the current print solution
- What is the support status of these application
- Dose these support EUC solutions
- How user would access these applications
- How is the update methodology for these apps
- How many user per applications
- Who is the administrator or the owner for each apps
- What is the Antiviruses assigned for the solutions
Understand the application behavior and requirements is important to propose the right bussies case
- Differentiate requirements, risks, constraints and assumptions : since we have collected all the information’s its time to extract and differentiate the solution design parameters :
| Term | Explanation | example |
| Requirements | Functional and can be Non-Functional requirements | (explained above in detail ) |
| Constraint | a limitation or restriction or are conditions that provide boundaries to the design which can be time based, financial or anything else that places a caveat on a decision | The system has to be operational in 4 months”“The budget for this system is $50,000”storage infrastructure must use existing EMC storage arrays for this project.The hardware vendor has to been selected already |
| Risk | factors or circumstance might prevent achieving the project goals or negatively affect the design | User or resources availability could be a problem in every project (No Storage administrator available in the site or he has no prior experience, )Single point of failures in the existing environment (power , network, AC)Any factor delay the project is a risk in most of cases (dependency on another project , The hardware of this project is no available yet and it depend in another project)Current storage is not under support |
| Assumption | something taken for granted | Customer will provide all the required MS license include SQL DBAny factor has not been proven it is an assumptionEquipment will be available at a certain dateThe organization has sufficient network bandwidthStakeholders will make a decision in the next meetingServer hardware has to be separated between DMZ and internal servers |
| Scope | Agree and state and define what include in the project scope and is out of scope of this project | -in scope : provide the group policy setting for the VDI -out of scope: configure the AD GPOs -Out of scope : any civil work |
| Design Goals | what is the purpose of the design, and over what time frame | Define project goal in S.M.A.R.T Specific – target a specific area for improvement. Measurable – quantify or at least suggest an indicator of progress. Assignable – specify who will do it. Realistic – state what results can realistically be achieved, given available resources. Time-related – specify when the result(s) can be achieved. |
All of the above should be documented and tracked. One approach would be to create a ‘workbook’ document where all requirements, risks, constraints etc are listed.
- Evaluate existing business practices against established use cases : now we have all the design parameters, limitations boundaries and we can start imagine the solution architecture(capacity , compute resource …) and we can build the use case , and we can evaluate its by applying business need to see if it achieving the required requirements and we can match key requirements to known Horizon use cases