The project’s conceptual data model (CDM) acts as a high-level representation of the data entities and their relationships. As per ProPath’s instructions, it does not normally include the data elements that comprise each entity, but rather is a first step toward developing the more detailed logical data model that will be provided during the Logical Data Design.
VEMS will utilize CRM COTS internal storage for entities related to case management and their relationships. Items such as a Veteran (Account), case interactions (email or phone call), documents, etc. will be stored in CRM and its associated SharePoint interface. Some related information such as eligibility will come from external systems of record and not be persisted unless necessary, and then only cached. For external storage VEMS will utilize a database specifically designed for items not contained in the COTS components.
The following figure illustrates the major entities and their relationships as understood currently. This canonical model will be extended throughout the design phase
The Conceptual Infrastructure Design for the VEMS application will be supported by cloud services technologies to securely host development, preproduction, and production environments. To preface, VEMS will be hosted in a FedRAMP approved cloud services provider location and the application itself will be portable in that its security boundary will not be dependent on its underlying infrastructure. As such, it is important that infrastructure design technologies implemented by the VEMS cloud host provider integrate One-VA TRM approved COTS products that are reliable and able to meet FISMA Moderate security controls to maintain a FedRAMP ATO and VA IA requirements.
The cloud services infrastructure supporting VEMS will incorporate the following design components: web servers, application servers, database servers, virtual machines, directory servers, network communication devices, network security devices, and network storage devices. Both the Test and Production environments will include core system elements listed below to support the VEMS application:
Microsoft Windows Operating System platform
Microsoft .NET Framework
Microsoft IIS Web Server
Microsoft SQL Server
Microsoft Active Directory Server
VMware VSphere ESXi
The VEMS conceptual infrastructure design will also include integration points to attach with the following systems:
The VEMS application infrastructure will meet criticality requirements to ensure high availability of 99% uptime not to include regularly scheduled hardware and software maintenance. The VEMS cloud service provider will sign an enforceable SLA to meet the 99% uptime requirement. The cloud provider will also meet an SLA disaster recovery requirement to not lose more than two hours of data due to a failure as its Recovery Point Objective, and a recovery from any failure in four hours or less as its Recovery Time Objective. The VEMS cloud provider will allocate the appropriate resources to maintain the 99% uptime SLA including workload distribution for web service availability and manage multiple alternate site gateways for geographic failover inherent to large cloud provider designs.
There are many reasons an infrastructure or platform failure may impact the VEMS application availability including security incidents that cause a denial of service. Infrastructure or platform security incidents that are root cause for an availability issue are counted against the 99% uptime SLA. The VEMS team will be responsible for any application failures or security incidents that cause an availability issue. Achieving a VEMS application ATO, applying strong application security vulnerability testing and patch management practices, performing periodic web application penetration testing, applying rigorous quality assurance measures, and having timely incident response procedures will ensure the VEMS team will meet the 99% application uptime requirement.
High Availability (HA) will be implemented and designed into all interactions of the COTS systems to include CRM, SharePoint, web server, etc. This design parameter will ensure that the horizontal scaling employed by the cloud provider will enhance user loading and ensure performance and reliability of the system.
CRM Server-Deploying Microsoft Dynamics CRM on a Network Load Balanced (NLB) server cluster is a supported way to get increased scalability and high availability performance from your CRM deployment. Using NLB, you can cluster multiple Windows 2008 servers together. It provides added scalability as you can easily add additional nodes to the cluster as your usage grows, and it provides high availability, because if one node fails, traffic will be routed to other servers in the cluster.
DB Server-The following SQL Server configurations are supported for use with Microsoft Dynamics CRM:
However, when implementing a hosted Microsoft Dynamics CRM solution, you should consider providing the benefit of high availability to customers and users through use of a fault tolerant configuration.
Although both mirrored and clustered SQL high availability configurations are supported
Other components of CRM can also be installed on multiple machines (synchronous and asynchronous services, email router, etc.) to also provide high availability.
Email Router-The E-mail Router services may be deployed on one or more individual server, a Windows cluster for high availability and failover, or multiple Windows Clusters for scaled-out highly available solution. In a hosted CRM environment, it is recommended to deploy the email router in a high availability and failover configuration using Microsoft Windows Clustering.
Service Level Agreements and User Load
EMS will be built to planned user loading over web and virtual desktop interfaces. These projections will be utilized to develop SLAs and hosting model for the cloud provider. When parameters change the cloud provider will be notified with sufficient notice to make infrastructure and platform modifications to ensure service delivery to the users. VEMS will be tested to ensure that the architecture and the hosting model meets or exceeds all uptime and performance SLAs.
Further SLAs will provide offsite backup, access controls, and other IA controls necessary to ensure FISMA conformance, this would include full disaster recovery SLAs to include restoration times.