Solution Design Template
Solution Design Template
Solution Design Template
Confidentiality Statement
The information and data contained herein are the proprietary and confidential information and data
of Employers Direct Insurance Company.
<System or Project Name> Solution Design
Document Information
File Name Location
<system or project name> EDC wiki > Project Documentation > <project name>
Design.doc
Related Documents
Document # Document Title Location
<relDocNo> <relDocTitle> <drive>:\directory\ or EDC wiki >
GLO-01-01 IT Glossary
<existing Solution Design>
<existing system admin and
maintenance SOP>
<Stories or other report
requirements artifacts>
POL-01-02 IT Security Policy EDC wiki > IT Effective Documents
POL-04-02 IT Backup and Restore Policy EDC wiki > IT Effective Documents
POL-06-01 IT Record and Data Retention EDC wiki > IT Effective Documents
Policy
SOP-10-02 IT Infrastructure Monitoring EDC wiki > IT Effective Documents
Standard SOP
SOP-11-02 IT Operations Standard Operating EDC wiki > IT Effective Documents
Procedure
SOP-12-02 IT Backup and Restore Standard EDC wiki > IT Effective Documents
Operating Procedure
SOP-13-02 Business Continuity Planning and EDC wiki > IT Effective Documents
Disaster Recovery Standard
Operating Procedure
SOP-16-02 IT Security Standard Operating EDC wiki > IT Effective Documents
Procedure
References
Document Title Location
<refDocTitle> <drive>:\directory\ or physical location or EDC wiki >
Network Design Diagram EDC wiki > IT Infrastructure
<system name> System Diagram EDC wiki > IT Infrastructure > System & Network Documents > <file
name>
<existing application configuration EDC wiki > <system name> > <EDIC configuration file name>
guidelines>
<existing server/other component EDC wiki > IT Infrastructure > Server Device Setup and Configuration
configuration guidelines > <for example, SQL Server Standard Baseline Configuration>
<vendor documentation>
<industry coding standards>
<EDIC coding standards>
Contributors
<examples of responsibilities related to the solution design that should be considered in compiling content for
the solution design>
Approvals
<sample approvers with titles as of July 2009>
Name Title, Department Signature Date
John Barrus Senior Technology
<include in SOP-24 Architect, Information
infrastructure arch Technology
role and SOP-16
security officer role>
Joe Cardenas Vice President/Chief
Information Officer,
Information Technology
LuNell Gilliland IT Manager, Information
Technology
Table of Contents
1.0 Overview................................................................................................................................. 2
2.0 Purpose.................................................................................................................................. 2
3.0 Scope...................................................................................................................................... 2
8.2. Operations.................................................................................................................................. 2
8.3. Backup and Restore................................................................................................................... 2
8.4. Disaster Recovery...................................................................................................................... 2
1.0 Overview
<Reference the project requirements artifacts. Is this a new system or an enhancement to an existing system?
>
2.0 Purpose
The purpose of this <system name> Solution Design is to translate business requirements and functional
specifications to a logical and a physical solution design. To provide a documented description of the design of
the project solution that can be reviewed and approved, the artifact:
Specifies the project architecture, interfaces and sub-system requirements in enough detail so
component parts can be procured and built
Provide the build-to specification for software and hardware during construction and the as-build
specification upon acceptance of the Designated Release
Describes the IT components in sufficient detail for them to be maintained and upgraded.
3.0 Scope
<Describe the design components. State which of the following need to be addressed in this document:
database requirements, file format, data dictionary, system flow diagrams, program modules, system
operations requirements, screen designs, report designs and other components as applicable.>
<Describe the solution that is to be delivered at high level, overview of architecture, design goals, design
approach and components logical design diagram.>
This section describes the assumptions, dependencies, constraints and exclusions of the design solution.
5.1. Assumptions
<Describe any assumptions (a starting point, something taken for graned) relating to this solution. This
includes integration processes, related software or hardware, end-user characteristics and so forth (for
example, this solution requires the installation of Adobe 9.0 that supports a new and needed feature so
assumption is that Adobe will release the new version 9.0 by x date).
5.2. Dependencies
<Describe any dependencies (something this design relies on) relating to this solution. Identify dependencies
with existing applications and components (such as data warehouse, reporting, ETL or integration systems).
Example dependency may be that development of the ClaimCenter-dependent module cannot begin until
version 5.3 is available in the dev environment.>
5.3. Constraints
<High-level description of restrictions, limitations or constraints surrounding this solution design. Constraints
may be anything that prevents development or infrastructure from implementing a particular requirement, story,
report or PBI (for example, a component required to support the requested feature currently does not exist in
the COTS or SaaS orDWH system available to EDIC IT so design is constrained to use of whatever the
alternative is, such as same-sign-on rather than single-sign-on). Timing is common constraint such as a
business requirement constrains delivery to no later than set date. Could be regulatory timing constraint that
requires a report delivery on set date.>
5.4. Exclusions
<Identify solution design exclusions in reference to requirements/stories/reports/PBI that are not addressed by
this solution design to be delivered as part of this project. For example, a requirement or story or PBI that will
be documented in a different, related system.>
<Describe the high-level design plan. This should briefly discuss all the major components and their
interactions, key technologies, standards, integrations and workflow. EDIC architectural strategy (SaaS, Web
Services, loose-coupling) should also be discussed. Reference <existing or new> <system name> System
Diagrams.>
The following sections document the software, data, workflow, output and secure access design.
7.1. Software
<Describe the high-level design plan. This should briefly discuss all the major components and their
interactions, key technologies, standards, integrations and workflow. EDIC architectural strategy (SaaS, Web
Services, loose-coupling) should also be discussed. Reference <existing or new> <system name> System
Diagrams.>
Field name, description, data type, mapping to database elements, data validation, events
Screen design: fields in each screen and the purpose of each field, description of how screen is
triggered, logical flow of the screens by specifying screens that pull from other screens (such as
Screen Flow Diagram), input checks performed, description of error messages>
This solution design is consistent with <or exception to/requires revision of> IT Record and Data Retention
Policy (POL-06-01) [Note to add Data Privacy Policy/SOP when effective.]
<Describe structure in the software, relationship between data elements and file requirements (description of
each file (such as input, temporary, output, type of information that it contains), file access method, list of the
fields in a record (record layout), data attributes (number of positions, numeric versus alpha), anticipated
number of records>
<Include the data warehouse design or changes and any necessary ETL designs>
7.3.1. Automation
<Scheduling, Events, Triggers, Batch processing. Define software automation tools related to this solution
such as Microsoft Task Scheduler (Windows), AutoMate from Network Automation, DCO Scheduler. Describe
type of integration such as business component, query pages, Web parts and portal pages and thin client
access. Describe method for enforcing data integrity.>
7.3.2. Integration
7.3.3. Rules
7.4.1. Reports
<Address any report or future report phase requirements that this design requires, when applicable>
This solution design complies with IT Security Policy (POL-01-02) and is <consistent with or requires revisions
to the IT Security Standard Operating Procedure (SOP-16-02). <Reference existing Network Design Diagram
and specify <system name> System Diagram as related to system access control.>
< How is access and authorization designed? For example, the application or report is designed for use by xyz
departments as currently documented in the Cognos Reporting System Administration and Maintenance
Standard Operating Procedure (SOP-07-01) or in the Cognos Reporting Solution Design artifactthe system
database is shared by system A and system B, and so on.>
7.5.2. Authentication
<Does this use an internal, Single-Sign-On/Same-Sign-on, Active Directory, LDAP or another authentication
mechanism? Reference name and location where those are documented. When user role authenticated at
application level specify design/configuration.>
<Specify how access to user role/permission/privilege/menu/(whatever this system calls it) is controlled--
through the application, through Active Directory or a combination of both. Define and describe various system
(application and database) roles and parameters [whats meant by parameters? Application-defined vs.
configurable parameters?].
Define any service accounts needed and their use and how they are controlled and if any are exceptions to
POL-01.>
<Describe when design requires users to access this feature or application using a Web Server, Terminal
Server, Quest Software (formerly Provision Networks) or VPN and how secured.
Specify any unique solution design for components to be accessible by vendors, customers or the general
public?>
<When data is transferred outside of the EDIC network, what type of encryption is necessary and does comply
with or need to be documented exception to the IT Security Policy (POL-01) and IT Security Standard
Operating Procedure (SOP-16-02)?>
The following sections specify environment minimums and other design considerations in support of IT
infrastructure and system operations procedures.
8.1. Environments
8.2. Operations
This solution design is consistent with <or exception to/revisions needed to> the IT Operations Standard
Operating Procedure (SOP-11-02). <Design of job scheduling, managed reports, non-managed reports, job
monitoring, operations deployment.> Delivery of the solution Designated Release for operational deployment
is consistent with the IT Change Management Standard Operating Procedure (SOP-19-02).
This solution design complies with the IT Backup and Restore Policy (POL-04-02) and is consistent with <or is
exception/requires revision of> IT Backup and Restore Standard Operating Procedure (SOP-12-02).
<Describe design considerations addressing backup and restore procedures specific to this solution or
application. Do not duplicate system administration and maintenance procedures documented as part of the
systems existing SASOP.>
This solution design is consistent with <or is exception/requires revision to> Business Continuity Planning and
Disaster Recovery Standard Operating Procedure (SOP-13-02).
<Response to any DR requirements specific to this solution, any other DR documents if applicable or note
special recovery requirements.>
<Review and reference existing documents to determine if revisions or additional docs needed including
<Doc owner/author note for review prior to submitting for approvalsdelete this checklist from final doc:
Checklist: Critical Information
Does the Solution Design artifact include definition of requirements unique to the chosen architecture
[interfaces between sub-systems, for instance]? Are interfaces that are not shared with systems
completely specified in this Solution Design? Are integrations between this system and others completely
specified in this Solution Design or referenced to a related document that can be verified?
Are system requirements traced to the sub-systems in the <system name> System Design reference
artifact?
Are COTS/SaaS products identified?
Is the architecture, both hardware and software, of the sub-systems [components and interconnections]
defined?
Are any necessary database schema and structures defined?
Are the hardware components defined in enough detail to support procurement or fabrication?
Has the trace from requirements to hardware and software components been checked and verified?
Is the Solution Design artifact linked to the source code components, that is, do they use the same object
names, file names, attribute names, and method names? >