Group Informatics

Solution Architecture
[Project Name]

Document ID: See EDMS

Version: 1.0

Effective Date: Date of last signature

PL id: 6771865/8

PMM Template Version: 6.0 [February 2014]

 Group Solution Architecture
Informatics
[Project Name]
Doc ID: See EDMS Effective Date: Date of last signature

Document Information
Project Name [Project Name]
Document Name Solution Architecture
Document Owner
Document Location
Associated Roche Global Informatics Directive: Data Classification
Documents Roche Global Informatics Instruction: Classifying and Securing Data
Corporate Records Management Directive
Standard for the Management and Retention of Electronic Records
Group Records Classification

Author
Role Name Dept. Signature Date
Author Electronically signed

Review
Role Name Dept. Signature Date
Electronically signed

Approval
Role Name Dept. Signature Date
Electronically signed

Note: The electronic signatures for this document can be found on the e-signature page(s). Manual signatures (if any)
are scanned and stored in a separate PDF file in the same location as the original document. This document is
considered uncontrolled when printed.

Document History
Version Changes Effective Date
1.0 First Approved version Date of last signature
PL id: 6771865/8

Version 1.0 Page 2 of 22

 Group Solution Architecture
Informatics
[Project Name]
Doc ID: See EDMS Effective Date: Date of last signature

Table of Contents Page

1. Purpose ................................................................................................................................. 6
1.1 Assumptions / Constraints ..................................................................................... 6

2. Definitions ............................................................................................................................. 6

3. AS-IS Architecture ................................................................................................................ 7

3.1 Overview and Shortcomings of the Current State .................................................. 7
3.2 Logical Architecture ............................................................................................... 7
3.3 Solution Retirement ............................................................................................... 8

4. TO-BE Architecture .............................................................................................................. 9

4.1 Proposed Solution ................................................................................................. 9
4.1.1 Evolutionary Considerations .................................................................................. 9
4.1.2 Alternatives Considered......................................................................................... 9
4.2 To-Be Business Architecture ............................................................................... 10
4.2.1 Business Process Diagram.................................................................................. 10
4.3 To-Be Data Architecture ...................................................................................... 11
4.3.1 Conceptual Data Model Information Entities ..................................................... 11
4.3.2 Data Governance and Compliance...................................................................... 12
4.3.3 System Context Diagram..................................................................................... 13
4.3.4 Interface Summary Table .................................................................................... 14
4.3.5 Data Migration/ Conversion ................................................................................. 14
4.4 To-Be Application Logical Architecture ................................................................ 15
4.5 To-Be Application Physical Architecture .............................................................. 17
4.5.1 Physical Architecture Diagram............................................................................. 18
4.5.2 Network Architecture ........................................................................................... 20
4.6 Solutions to Non-Functional Requirements.......................................................... 21
4.6.1 User Profile Table................................................................................................ 21
4.6.2 Performance Requirements................................................................................. 21
4.6.3 Capacity Requirements ....................................................................................... 21
4.6.4 Business Continuity ............................................................................................. 22
4.6.4.1 High-Availability Requirements............................................................................ 22
4.6.4.2 Disaster Recovery Requirements ........................................................................ 22
4.6.4.3 Backup and Archiving Requirements ................................................................... 22
4.6.4.4 Maintainability / Supportability ............................................................................. 22
PL id: 6771865/8

Version 1.0 Page 3 of 22

 Group Solution Architecture
Informatics
[Project Name]
Doc ID: See EDMS Effective Date: Date of last signature

Instructions for Authors:

The Solution Architecture document defines the components involved and their interactions. It
is created by the solution architect. The Solution Architecture document has two releases:
The Solution Architecture-Define document holds the initial description of the project
architecture and must be completed by the end of the Define Phase. It serves as a basis for
the initial architecture review at the Baseline Gate.
The Solution Architecture-Design document is optional, but may become mandatory during
the Baseline architecture review. This assumes all sections noted as mandatory are
completed in Baseline review. The Solution Architecture document must be updated if the
solution architecture has changed since the Baseline architecture review. Also, ensure that
action items identified in the Baseline architecture review have been addressed.
An ARB review is always done prior to the Baseline phase gate. An optional ARB review
may be required of projects at the Design phase, if there were outstanding questions from the
Initial ARB Review.
In the spirit of only requiring projects to get sign-off once for the SAD, we're proposing:
That the SAD is signed at the Define phase (prior to Baseline phase gate) if the Initial ARB
Review is sufficient, and no further ARB review is required at the Design phase;
However, if ARB review is required for Detailed Design, then SAD sign off will be at Design
phase (no sign-off required at Define phase);
In both cases, the project team will present the ARB minutes from Initial ARB Review during
Baseline phase gate review as evidence of having completed the Initial ARB review.
Solutions will be described with enough detail to allow an estimate of the effort for realization.
The intended audience of this document is Architects, Engineers, Developers, and all other
stakeholders involved in the solution definition and design.
Chapters are mandatory unless otherwise stated. If mandatory chapters are not used, please
state N/A and provide an explanation. Optional sections can be documented here, but if
documented in other documents, provide references for their location. Delete optional
chapters that do not apply. If more sections are required, the author may add them as
appropriate, using the same format.
Please note that all text in this document is for guidance only and needs to be adapted when
writing the final version.
Important: Please ensure that you provide a brief rationale for the deletion of any optional
sections (main chapters). Mandatory sections shall never be deleted. Please check PMM
Tailoring Options for further information (System Index and Tailoring).
Instructions are written in comment bubbles, which can be easily deleted after reading and
following them.
Text proposals and Examples are in blue. Please adapt them according to project specific
needs.
Use the File Properties function to maintain the Project Name and Version numbering in the
PL id: 6771865/8

title page and in the headers and footers throughout the document:

Version 1.0 Page 4 of 22

 Group Solution Architecture
Informatics
[Project Name]
Doc ID: See EDMS Effective Date: Date of last signature

o In the Word menu, select File - Properties - Advanced and open the Custom tab.
o In the list of Properties, select the Title field, enter the Project Name and click Modify.
o Click OK to close the Custom tab and click Home in the Word menu.
o Refresh the properties in your document. Press Ctrl-A and then [F9]. Repeat in the
headers and the footers.
Delete this text box before forwarding this document for review/approval.
PL id: 6771865/8

Version 1.0 Page 5 of 22

 Group Solution Architecture
Informatics
[Project Name]
Doc ID: See EDMS Effective Date: Date of last signature

1. Purpose
This document describes the high-level components of the proposed solution [system/project
name] in order to meet requirements across all architecture domains: Business, Data, Application
and Technology.
Its purpose is to provide enough detail to communicate a good understanding of the overall
solution, its components, and intended users, and to help Architecture and Engineering plan for
performance, capacity, testing, and deployment. The architecture is described in this document at
the conceptual and logical levels, and does not replace detailed design documents (e.g., Design
Specification).

1.1 Assumptions / Constraints

Your text.

2. Definitions
For terms related to the Project Management Methodology, please refer to the PMM glossary in
the intranet.
The following terms and abbreviations are used in this document:
Term Definition
PL id: 6771865/8

Version 1.0 Page 6 of 22

 Group Solution Architecture
Informatics
[Project Name]
Doc ID: See EDMS Effective Date: Date of last signature

3. AS-IS Architecture
The information in this section provides a high-level description of the systems current
architecture.
Your text.

3.1 Overview and Shortcomings of the Current State

Your text.

3.2 Logical Architecture

Your text.

The following diagram depicts the systems logical architecture:

Your diagram.
Example:
Doc. Inter-

Authoring

DocLink
Support
change

Document Portal
Solution

Authoring
PL id: 6771865/8

Version 1.0 Page 7 of 22

 Group Solution Architecture
Informatics
[Project Name]
Doc ID: See EDMS Effective Date: Date of last signature

Optional:
Your Application Interface Map (AIM)
Example:

Delete this box before forwarding this document for review / approval.

3.3 Solution Retirement

Your text.
PL id: 6771865/8

Version 1.0 Page 8 of 22

 Group Solution Architecture
Informatics
[Project Name]
Doc ID: See EDMS Effective Date: Date of last signature

4. TO-BE Architecture
This section provides descriptions and diagrams of the future architecture.

4.1 Proposed Solution

Your text.
Example:
Affiliates - France Commercial Operations CityScape
Sales Force Activities
Business Support (Operation Services) Medical Affairs
Sales Strategy Sales Force
Business Strategy & Planning Analytics
Datawarehouse Intelligens/Sieb Reportive Paris CIA Pharmacovigilance
Paris el CRM - Paris Business Datawarehouse Business
GEODE
Objects Paris Paris Objects Paris

MyRoche/Affilia Pharmaco
te Portal Paris

Sales Administration
Account Mgmt
PARIS KAM ULYSSE
Medical Services
Market Research
Intelligens/Sieb Intelligens/Sieb
el CRM - Paris el CRM - Paris
IDEAL PriMa
Marketing E-Doc
Pleiades Competitive Intelligence
Marketing Planning Promotional Activities Event Planning Network
Congress
EIPF Web Services Online
Publication Regulatory Affairs
Application Territory
Planning Tool Pricing / Reimbursement
Management MIS AMM
System -
France Scopco
Intelligens/Sieb
Email Vision Performance Management CRM
el CRM - Paris Trackwise Excel
Email Vision Intelligens/Sieb EMEA / NALA Deviation
Intelligens/Sieb
el CRM - Paris Tracking
el CRM - Paris
Roche.fr
Commercial Contracts
Omniture TVF (Customer Medical Communication
File)
Moebius EURYDICE

Non-promotional Support
Brand Management Local Compliance
EIPF Web Intelligens/Sieb Funding
Product
Application el CRM - Paris Complaints
Information
Portal Tracking for
French Authorities

4.1.1 Evolutionary Considerations

Your text.

4.1.2 Alternatives Considered

Your text.
PL id: 6771865/8

Version 1.0 Page 9 of 22

 Group Solution Architecture
Informatics
[Project Name]
Doc ID: See EDMS Effective Date: Date of last signature

4.2 To-Be Business Architecture

4.2.1 Business Process Diagram
The following diagram illustrates the future business process flow:
Your diagram.
Example:
PL id: 6771865/8

Version 1.0 Page 10 of 22

 Group Solution Architecture
Informatics
[Project Name]
Doc ID: See EDMS Effective Date: Date of last signature

4.3 To-Be Data Architecture

4.3.1 Conceptual Data Model Information Entities
The objective of this section is to list the Information Entities (i.e., the major/high-level data entities)
in scope for the project, and - if applicable - their potential relationships to master data and the
Canonical Message Model (CMM) library.
Your text.

The following list depicts the major information entities relevant to the project.
Your text
Example:
Information Entity Description CTMS CRM SAP
Customer * Investigator CRUD RU R
.

< * > indicates Master Data entity

PL id: 6771865/8

Version 1.0 Page 11 of 22

 Group Solution Architecture
Informatics
[Project Name]
Doc ID: See EDMS Effective Date: Date of last signature

4.3.2 Data Governance and Compliance

Example:
Data Domain (Information Entity or Data Domain Compliance Policies
Subject Area) Contact
Customer <add function or name> HIPAA

Compliance with the Standard for the Management and Retention of Electronic Records must be
ensured if one or multiple Data Domain(s)
are subject to external regulations that mandate accurate retention (e.g. 21 CFR Part 11)
need to be retained for more than 10 years1
of Global Impact2
require Computerized System Validation (CSV)
PL id: 6771865/8

1
Use the Group Records Classification: In scope are rows where column Retention equals IND or is +10Y ( or longer)
2
Use the Group Records Classification: In scope are rows where column GI equals TRUE

Version 1.0 Page 12 of 22

 Group Solution Architecture
Informatics
[Project Name]
Doc ID: See EDMS Effective Date: Date of last signature

4.3.3 System Context Diagram

The objective of this section is to describe the integration of the future system into its environment.
The system context diagram (SCD) illustrates the interaction between the system and its
interfaces; it depicts how the system will receive and send data flows to the external entities
involved. The system context diagram provides the baseline interaction between systems and
external entities.
The following diagram illustrates the data flows across applications:
Your diagram(s).
Example: e-Billing system
PL id: 6771865/8

Version 1.0 Page 13 of 22

 Group Solution Architecture
Informatics
[Project Name]
Doc ID: See EDMS Effective Date: Date of last signature

Example:

4.3.4 Interface Summary Table

The following table summarizes the future system interfaces:
Example:
Source Target Integration Information Frequency Message Message
Approach / Entities (real-time, Volume (# Size
Application Interface Application Interface Integration Exchanged near real- of records (per
Type (API) Type Middleware time, or record or
(API) hourly, messages) message)
daily,
monthly)

CTMS Tibco GLIDE File Correlate via Customer Hourly 10 100KB

messages Import a database
(ODS)

4.3.5 Data Migration/ Conversion

The following table lists the major information entities that you need to migrate/convert from legacy
data sources, as well as any conversion interfaces needed to build the solution.
Example:
Information Entity Current State; Future State; Conversion Interface
Source Target
Investigator TrialWorks CTMS Manual (M)
Interface (I)

PL id: 6771865/8

Version 1.0 Page 14 of 22

 Group Solution Architecture
Informatics
[Project Name]
Doc ID: See EDMS Effective Date: Date of last signature

4.4 To-Be Application Logical Architecture

The objective of this section is to describe the components that make up the application
architecture and how it relates to enterprise resources such as the Portal, LDAP, and user
interface/device.
Your text.
Example logical architecture:
PL id: 6771865/8

Version 1.0 Page 15 of 22

 Group Solution Architecture
Informatics
[Project Name]
Doc ID: See EDMS Effective Date: Date of last signature

Example logical/physical architecture:

PL id: 6771865/8

Version 1.0 Page 16 of 22

 Group Solution Architecture
Informatics
[Project Name]
Doc ID: See EDMS Effective Date: Date of last signature

4.5 To-Be Application Physical Architecture

Your text.
Example:
Layer/ System Environment Size Version Standard
Type Location (Data Yes/No
Centre)
(Lifecycle
Status)*
HP-UX 2 x Nutley Production MCS - clustered OS: 11.0 Yes
Server 1 x Basel Test (S)
1 x other site Development
Oracle DB 1 x Nutley 500 MB Oracle 9.2 No
(N)
Storage Nutley 150 Mid -Range / EMC
Basel 170 Low End EMC / NetApp
Other Site 350 Mid-Range / EMC
390 Archive
50 Mid-Range / 40
Low End
Win 5 x Nutley DMZ Small Server WSOE xxx
Server 5 x Nutley Midsize Server WSOE xxx

VM 4 x Basel Small Image WSOE xxx

Note:
* TAF lifecycle status: Standard (S); Contain (C ), Retire (R), Unsupported (U), Emerging (E)
DIA lifecycle status: Recommended, Discontinued, Obsolete
PL id: 6771865/8

Version 1.0 Page 17 of 22

 Group Solution Architecture
Informatics
[Project Name]
Doc ID: See EDMS Effective Date: Date of last signature

4.5.1 Physical Architecture Diagram

The section serves as input to the infrastructure component design.
The following diagram illustrates the future physical architecture of the system:
Your diagram.
Example 1:
PL id: 6771865/8

Version 1.0 Page 18 of 22

 Group Solution Architecture
Informatics
[Project Name]
Doc ID: See EDMS Effective Date: Date of last signature

Example 2:
Includes security protocols and trust boundaries, as well as any connections to 3rd parties:

Your text.
PL id: 6771865/8

Version 1.0 Page 19 of 22

 Group Solution Architecture
Informatics
[Project Name]
Doc ID: See EDMS Effective Date: Date of last signature

4.5.2 Network Architecture

Your text.
PL id: 6771865/8

Version 1.0 Page 20 of 22

 Group Solution Architecture
Informatics
[Project Name]
Doc ID: See EDMS Effective Date: Date of last signature

4.6 Solutions to Non-Functional Requirements

Your text.

4.6.1 User Profile Table

The following table provides profiles of the system users:
Type of Number User User Expected Peak Usage Expected Growth
User* of Users Functions Location Response Level (in # of Rate (over three
** Time users) years)?

Notes:
(*) Internal/external users, online/offline users
(**) EMEA, APAC, NA, LATAM

4.6.2 Performance Requirements

Your text.

4.6.3 Capacity Requirements

Your text.
PL id: 6771865/8

Version 1.0 Page 21 of 22

 Group Solution Architecture
Informatics
[Project Name]
Doc ID: See EDMS Effective Date: Date of last signature

4.6.4 Business Continuity

Your text.

4.6.4.1 High-Availability Requirements

Your text.

4.6.4.2 Disaster Recovery Requirements

Your text.

4.6.4.3 Backup and Archiving Requirements

Your text.

4.6.4.4 Maintainability / Supportability

Your text.
PL id: 6771865/8

Version 1.0 Page 22 of 22

 Electronic Signature Page

Project Name: PMM

Group Informatics Solution Architecture Template.doc

Version: 6.0
_______________________________________________________________________________

This document has been signed by:

Meaning: Sign for Approval

Function: Template released by PMM Process Owner
User Name: Griep, Mathias (griepm)
Date: 13-Feb-2014 19:37 Basel Server Time

Meaning: Sign for Approval

Function: Pharma IT Quality - assurance of continued alignment with CSV Policy and processes
User Name: Gniecko, Kathleen A (gnieckok)
Date: 14-Feb-2014 07:26 Basel Server Time
PL id: 6771865/8

The unique PL id (left) identifies this document within Project Library. The individually numbered signature page(s) created by Project Library and
the signed document are combined and rendered into this PDF.

Version: 6.0 Electronic Signature Page 1 of 1