Solution Architecture
<PROJECT NAME>
Version 0.3
[Publish Date]
Solution Architecture
<project name>
REVISION HISTORY
Date
[Publish
Date]
Version
Description of Change/Revision
Author
0.3
APPROVALS
Group /
Committee
Name
Members
Date of Issue
Version
DISTRIBUTION
Role
Version 0.3
Print Name
Date of Issue
Page 2 of 22
Solution Architecture
<project name>
TABLE OF CONTENTS
1
Document Overview .......................................................................................................................... 4
1.1
Context.................................................................................................................................. 4
1.2
Purpose ................................................................................................................................. 5
2
The Case for Change .......................................................................................................................... 6
2.1
Background ........................................................................................................................... 6
2.2
Current State......................................................................................................................... 6
2.3
Envisioned Future State ........................................................................................................ 6
3
Project Overview ............................................................................................................................... 7
3.1
Scope..................................................................................................................................... 7
3.2
Approach ............................................................................................................................... 7
3.3
Timeline ................................................................................................................................ 7
3.4
Assumptions.......................................................................................................................... 7
3.5
Constraints ............................................................................................................................ 7
4
Solution Outline ................................................................................................................................. 9
4.1
Architecture Overview .......................................................................................................... 9
4.2
System Context ..................................................................................................................... 9
4.3
Assumptions........................................................................................................................ 10
4.4
Constraints .......................................................................................................................... 10
4.5
Risks .................................................................................................................................... 10
4.6
Important Considerations ................................................................................................... 11
5
System Architecture ........................................................................................................................ 12
5.1
Component Model .............................................................................................................. 12
5.2
Data Model ......................................................................................................................... 13
5.3
Security Model .................................................................................................................... 13
5.4
Technology Model .............................................................................................................. 13
6
Deployment Architecture ................................................................................................................ 15
6.1
Bill-of-Materials Summary .................................................................................................. 15
6.2
Production Environment..................................................................................................... 16
6.3
Pre-Production Environment .............................................................................................. 17
6.4
Training Environment ......................................................................................................... 17
6.5
Test Environment ................................................................................................................ 18
6.6
Development Environment................................................................................................. 18
7
Architecture Decisions ..................................................................................................................... 19
8
Glossary ........................................................................................................................................... 20
9
References ....................................................................................................................................... 21
Appendix A:
Version 0.3
Risk Rating Determination Matrix ................................................................................... 22
Page 3 of 22
Solution Architecture
<project name>
1 DOCUMENT OVERVIEW
1.1 Context
IT projects that deliver enterprise support for the University of Adelaide are managed in accordance
with the Project Management Framework. The primary goals of this framework are:
 To improve the delivery performance of IT projects by applying a consistent approach, sharing best
practices, and enabling continuous process improvement.
 To ensure that the University can exercise an appropriate level of control and oversight over IT
projects from a strategic, financial, technical, and management perspective.
For more information on the Project Management Framework, please refer to:
https://www.adelaide.edu.au/infrastructure/solution_delivery/framework/lifecycle/.
This Solution Architecture has been produced in the Feasibility phase of the Project Management
Framework as shown in the following figure.
Concept
Feasibility
Define needs,
alignment with
enterprise strategy,
solution scope and
approach, and plan for
next phase
Define business
requirements, IT
system requirements,
product selection,
solution architecture,
business benefits,
business case, and
plan for next phase
Detailed
Design/
Planning
Build/
Configure/
Test
Deployment/
Handover/
Closure
Conduct detailed
solution design and
delivery planning. Final
scope, deliverables,
and design should be
agreed
Based on detailed
design, the build,
configuration and
testing for the project
takes place. These
steps may be
performed iteratively
Agreed deliverables
deployed, users
trained, & solution
handed over to
operations. Sponsor
provides final
acceptance & sign off
Gate 0
Gate 1
Gate 2
Gate 3
Gate 4
Registration
and Process
Advice
Feasibility
Assessment
Delivery
Readiness
Review
Deployment
Readiness
Review
Benefits
Realisation
Planning &
Closure
Figure 1: Feasibility phase highlighted in the Project Management Framework
The primary objective of the Feasibility phase of the project is to produce a reliable statement of
agreement between the stakeholder group and the delivery group in terms of investment versus
outcome – in other words, an approved business case. It achieves this by:
 Defining the business and IT system requirements
The business requirements are defined in terms of organisational context, user roles, business
processes, business information, business rules, and business operations. Through analysis of
existing IT systems, manual vs. automated processes, the conceptual IT system is scoped and
defined in terms of functional and non-functional requirements.
 Evaluating IT options and defining the recommended solution
Where the IT solution is not defined in the Concept phase, IT system requirements are used to seek
and evaluate IT solution alternatives. Mechanisms such EOI (expression of interest), RFI (request
for information), or RFT (request for tender) may be used for engaging with the market, and
numerically-based scoring methods for comparative evaluation. The recommended option is
endorsed by all relevant stakeholders prior to its more detailed solution architecture definition for
the purpose of project planning and estimating.
 Planning and estimating
Based on the recommended solution architecture, the business case is developed to bring together
Version 0.3
Page 4 of 22
Solution Architecture
<project name>
the proposed outcome (scope, new capabilities, business benefits, business change, etc.) with the
required investment (capital costs, resources, time, operating costs, etc.).
These elements are depicted in the following figure with this document highlighted.
Feasibility
Requirements
Options and
Architecture
Business
Specification
Options
Analysis
IT System
Specification
Solution
Architecture
Planning and
Estimation
Business
Case
Gate 1
Feasibility
Assessment
Figure 2: Solution Architecture document highlighted in the context of the Feasibility phase
1.2 Purpose
The purpose of this document is to:
 Define the scope and boundary of the IT system to be delivered – ‘IT system’ in this context is a
singular representation of all IT elements delivered by the project
 Define the internal structure of the IT system in terms of its components, their allocated
functionality, and their interrelationships
 Define the interfaces between the IT system and external systems
 Define the security implementation of the IT system
 Define the technology platforms used within or required by the IT system
 Define the new or existing technology infrastructure required by the IT system for production
operations, development and maintenance, testing, user training, etc.
Version 0.3
Page 5 of 22
Solution Architecture
<project name>
2 THE CASE FOR CHANGE
2.1 Background
Background and context to the project.
2.2 Current State
“Where are we now…” – provide a very brief overview of the current situation giving rise to the need
for a solution.
2.3 Envisioned Future State
“Where do we want to be...” – provide a very brief overview of the future state after the solution has
been delivered.
Version 0.3
Page 6 of 22
Solution Architecture
<project name>
3 PROJECT OVERVIEW
3.1 Scope
The following tables define the project scope inclusions and exclusions respectively.
Table 1: Project scope inclusions
ID
Scope Inclusion
SI001
SI002
SI003
Table 2: Project scope exclusions
ID
Scope Exclusion
SE001
SE002
SE003
3.2 Approach
3.3 Timeline
3.4 Assumptions
The assumptions in the following table are known facts that have the effect of enabling, supporting, or
justifying specific aspects of the project.
Table 3: Project assumptions
ID
Project Assumption
PA001
PA002
PA003
3.5 Constraints
The constraints in the following table are known facts that have the effect of impacting or limiting the
project.
Version 0.3
Page 7 of 22
Solution Architecture
<project name>
Table 4: Project constraints
ID
Project Constraint
PC001
PC002
PC003
Version 0.3
Page 8 of 22
Solution Architecture
<project name>
4 SOLUTION OUTLINE
4.1 Architecture Overview
The architecture overview provides a high level depiction of the composition and structure of the key
elements of the proposed solution. Its key purpose is to communicate the solution clearly and
effectively to all stakeholders, both business and technical.
Figure 3: Architecture overview
4.2 System Context
The system context shown in the figure below represents the proposed solution as a single logical
system in the context of the external entities with which it interacts. External entities can be users,
other applications or systems, external organisations, etc. This representation broadly identifies the
information and control flows that cross the system boundary, and provides a guide as to the delivery
scope of the project.
Version 0.3
Page 9 of 22
Solution Architecture
<project name>
External
Entity #1
External
Entity #3
System
External
Entity #2
External
Entity #4
Figure 4: System context
4.3 Assumptions
The assumptions in the following table are known facts that have the effect enabling, supporting, or
justifying specific elements of the solution.
Table 5: Solution assumptions
ID
Solution Assumption
SA001
SA002
SA003
4.4 Constraints
The constraints in the following table are known facts that have the effect of impacting or limiting the
solution.
Table 6: Solution constraints
ID
Solution Constraint
SC001
SC002
SC003
4.5 Risks
Solution risks are possible future scenarios with the potential to negatively impact the viability or
deliverability of the solution. Each risk has a likelihood of occurrence, and a degree of impact on the
project in the event that it does occur. The rating of a risk in terms of priority for mitigation is
determined as a product of likelihood and impact in accordance with the matrix shown in Appendix A:.
The identified solution risks for this project are listed and assessed in the following table.
Version 0.3
Page 10 of 22
Solution Architecture
<project name>
Table 7: Solution risk identification and assessment
ID
Solution Risk
Likelihood
Impact
Rating
SR001
SR002
SR003
SR004
SR005
4.6 Important Considerations
The considerations in the following table represent areas requiring follow-up or aspects to be taken
into account as the solution is further developed in the Delivery phase.
Table 8: Important considerations
ID
Important Consideration
IC001
IC002
IC003
IC004
IC005
Version 0.3
Page 11 of 22
Solution Architecture
<project name>
5 SYSTEM ARCHITECTURE
5.1 Component Model
The component model describes the system architecture in terms of components and their
interactions. Each component has a well-defined set of capabilities, responsibilities, and interfaces
through which it interacts with other components. At this level, components represent a logical
grouping of related functions rather than specific software or hardware modules. The purpose of the
component model is to depict the overall functionality and topology of the system.
ResearchMaster
Symplectic
Ethics Management
Profiles
Grants Management
Data Access API
ARC
E1 {Grant}
«flow»
E19 {Grant}
Non-ARC Grant
Bodies
N30 {Publication}
«flow»
«flow»
Publications
Management
Harv ester
E10 {Publication}
Publication
Publication
Publication
«flow»
«flow»
«flow»
«flow»
DSPACE
Scopus
Web of Science
Figure 5: Components and information flows
The following table provides an overview of the components depicted in the figure above.
Table 9: Solution components
ID
Component
Allocated Functions
Implementation Notes
C001
C002
C003
The following table provides an overview of the information flows depicted in the figure above.
Version 0.3
Page 12 of 22
Solution Architecture
<project name>
Table 10: Solution information flows
ID
Information
Source
Target
IF001
IF002
IF003
5.2 Data Model
Discuss data migration considerations here if required…?
5.3 Security Model
The following table describes how the solution addresses key security aspects in accordance with the
non-functional system requirements.
Table 11: Solution approach for key security aspects
Security Aspect
Solution Approach
Authentication
Authorisation
Audit
Confidentiality
Integrity
Availability
5.4 Technology Model
The following table provides an inventory of all products, services, and standards used to deliver and
run the solution.
Table 12: Solution technology inventory
Technology Area
Products, Services, or Standards
User Interface and Client
Device
Data Management and
Reporting
Programming Languages
and Runtime Environments
Version 0.3
Page 13 of 22
Solution Architecture
<project name>
Technology Area
Products, Services, or Standards
Web and Application
Servers
Integration Middleware
Operating Systems
Systems Management and
Security
Design Modelling (data,
services, etc.)
Source Control and
Configuration Management
Test and Defect
Management
Version 0.3
Page 14 of 22
Solution Architecture
<project name>
6 DEPLOYMENT ARCHITECTURE
6.1 Bill-of-Materials Summary
The following table lists all new software, hardware, and services to be acquired for the solution,
inclusive of all environments from development to production.
Table 13: Software, hardware, and services to be acquired
Item
Description
Qty/Capacity
The following table lists all existing software, hardware, and services to be re-used or shared by the
solution, inclusive of all environments from development to production.
Table 14: Existing software, hardware, and services to be re-used or shared
Item
Version 0.3
Description
Qty/Capacity
Page 15 of 22
Solution Architecture
<project name>
6.2 Production Environment
Production:::RM
Application
Serv er
«server»
tags
hostname = sprat.ad.adelaide.edu.au
memory = 8 GB
o/s = Windows Server 2012 (64 bit)
platform = Intel x64 VM
vcpu = 4
Production:::RM
Database Serv er
«server»
tags
hostname = catfish.ad.adelaide.edu.au
memory = 32 GB
o/s = Windows Server 2012 (64 bit)
platform = HP DL680
processor = 2 sockets x 10 cores
storage = 100 GB
Client Dev ice
«user pc»
tags
Compatibility = HTML5
Production:::
Symplectic
Serv er
«server»
tags
hostname = cod.ad.adelaide.edu.au
memory = 32 GB
o/s = Windows Server 2012 (64 bit)
platform = HP DL380
processor = 4 sockets x 10 cores
storage = 200 GB
Figure 6: Node architecture for the production environment
Version 0.3
Page 16 of 22
Solution Architecture
<project name>
«executable»
Production::RM :Internet
Information Serv er 8.0
Production:::RM Application Serv er
«deploy»
«executable»
Production:::RM6
«deploy»
tags
hostname = sprat.ad.adelaide.edu.au
memory = 8 GB
o/s = Windows Server 2012 (64 bit)
platform = Intel x64 VM
vcpu = 4
Production:::RM Database Serv er
«executable»
Production::RM :SQL Serv er 2012
«deploy»
tags
hostname = catfish.ad.adelaide.edu.au
memory = 32 GB
o/s = Windows Server 2012 (64 bit)
platform = HP DL680
processor = 2 sockets x 10 cores
storage = 100 GB
Figure 7: Allocation of ResearchMaster software to nodes for the production environment
«executable»
Production::Symplectic :Internet
Information Serv er 8.0
«executable»
Production:::Elements v 4.0
Production:::Symplectic Serv er
«deploy»
«deploy»
«executable»
Production::Symplectic :SQL
Serv er 2012
tags
hostname = cod.ad.adelaide.edu.au
memory = 32 GB
o/s = Windows Server 2012 (64 bit)
platform = HP DL380
processor = 4 sockets x 10 cores
storage = 200 GB
«deploy»
Figure 8: Allocation of Symplectic software to nodes for the production environment
6.3 Pre-Production Environment
6.4 Training Environment
Version 0.3
Page 17 of 22
Solution Architecture
<project name>
6.5 Test Environment
6.6 Development Environment
Version 0.3
Page 18 of 22
Solution Architecture
<project name>
7 ARCHITECTURE DECISIONS
The following tables provide an outline of the architecture decisions made in the course of developing
this solution.
Table 15: AD001 – …
Domain
Context
Decision
Alternatives
Considered

Assumptions

Rationale

Implications

Version 0.3
Page 19 of 22
Solution Architecture
<project name>
8 GLOSSARY
The following table provides a brief definition of the terms and acronyms used in this document.
Table 16: Definition of terms and acronyms
Term/Acronym
Definition
TCO
Total Cost of Ownership – the total cost of a solution over a prescribed
number of years including both the implementation project costs as well as
the net change in annual operating costs.
PMF
Project Management Framework – the defined approach to IT project
delivery used by the University of Adelaide.
Version 0.3
Page 20 of 22
Solution Architecture
<project name>
9 REFERENCES
The following references were cited in this document:There are no sources in the current document.
Version 0.3
Page 21 of 22
Solution Architecture
<project name>
APPENDIX A: RISK RATING DETERMINATION MATRIX
Likelihood
Risks are rated as ‘High’, ‘Medium’, or ‘Low’ based on likelihood and impact in accordance with the
following matrix.
Impact
Risk
Rating
Low
Medium
High
Low
Low
Low
Medium
Medium
Low
Medium
High
High
Medium
High
Extreme
Figure 9: Risk rating determination matrix
Version 0.3
Page 22 of 22