Terms of Reference
Technical Design Authority
IT Strategy and Architecture
Infrastructure, Property and Technology
Version 1.06, Approved – 31/05/2013
Version 1.06, Minor modifications to membership – 16 June 2014
1.
Establishment
When:
By authority of:
For period:
Reporting to:
2.
February, 2013
University ICT Architecture Committee
Review effectiveness and terms of reference in January, 2014
University ICT Architecture Committee and Project Boards as appropriate
Scope, Context, and Objectives
All projects that deliver enterprise support for the University and have an ICT component are managed
and controlled in accordance with the Project Management Framework established by the Project
Management Office (Technology) in Infrastructure, Property and Technology.
The Project Management Framework promotes an effective and consistent approach to key disciplines
such as project management and systems development lifecycle, along with supporting the goals of IT
governance, enterprise architecture, and technical assurance.
The primary objective of the Technical Design Authority is to provide technical assurance for projects
throughout their lifecycle. It achieves this by conducting Technical Assurance Reviews in designated
lifecycle stages as a requirement of authority to proceed through the associated stage gate. The
candidate reviews are shown in the following figure. The Enterprise Architecture Review conducted by
the University ICT Architecture Committee is also shown for context and completeness.
Figure 1: Candidate reviews in the context of the Project Management Framework
Terms of Reference
Technical Design Authority
Version 1.06, Approved
31/05/2013
The University of Adelaide
Page 1 of 5
A key objective of all Technical Assurance Reviews is to ensure that technical deliverables pertaining to
the review are of sufficient accuracy, completeness, and quality to be “fit for purpose” to serve the
needs of the project. In addition, the following key review objectives apply corresponding to the
respective phase/stage and stage gate in the project lifecycle:
 Feasibility – Gate 1: That the IT system architecture is sufficiently defined and complete to ensure
that all costs, resources, and associated impacts can be identified in the project Business Case.
 Detailed Design/Planning – Gate 2: That the IT system design meets technical goals that include
compatibility, usability, performance, security, reliability, maintainability, reuse/reusability,
supportability, and recoverability in production operations.
 Build/Configure/Test – Gate 3: That the IT system “as built” conforms to its approved design.
The particular Technical Assurance Reviews to be applied for each project are determined at the
discretion of the IT Strategy and Architecture group in consultation with the Project Management
Office.
3.
Responsibilities
3.1. Project Management Office
The Project Management Office is responsible for:
 Ensuring that all projects are recorded in a project register and notifying the IT Strategy and
Architecture group when this occurs.
 Ensuring that the required Technical Assurance Review is completed and approved prior to
granting authority to proceed through the associated stage gate.
3.2. IT Strategy and Architecture
IT Strategy and Architecture is responsible for:
 Notifying the Project Management Office when projects are identified to enable them to be added
to the project register.
 Conducting an assessment of each project in consultation with the Project Management Office to
determine the Technical Assurance Reviews to be applied.
3.3. Project Manager
The Project Manager is responsible for:
 Scheduling all required Technical Assurance Reviews noting that the Technical Design Authority
must be requested to provide the assigned membership for each review.
 Distributing review materials to all members of the Technical Design Authority with sufficient lead
time prior to the meeting to allow detailed review (at least 5 business days).
 Presenting review materials at the meeting, with the attendance and assistance of other project
team members as required.
Terms of Reference
Technical Design Authority
Version 1.06, Approved
31/05/2013
The University of Adelaide
Page 2 of 5
3.4. Technical Design Authority
The Technical Design Authority is responsible for:
 Advising Project Managers of the membership of the Technical Design Authority for each Technical
Design Review. This membership is tailored by the Standing Members of the Technical Design
Authority based on the areas impacted, subject matter expertise required, and staff availability.
 Facilitating and participating in Technical Assurance Review meetings – providing review feedback,
recommendations, required actions, and approvals.
 Documenting the proceedings of Technical Assurance Review meetings and distributing this to the
Project Manager, Project Board, and University ICT Architecture Committee (within 5 business
days).
3.5. Technology Portfolio Review Board
The Technology Portfolio Review Board is responsible for:
 Acting as an escalation point for technical design issues that cannot be resolved at the level of the
Technical Design Authority, Project Manager, and Project Board.
3.6. University ICT Architecture Committee
The University ICT Architecture Committee is responsible for:
 Acting as an escalation point for business and technical architecture issues that cannot be resolved
at the level of the Technical Design Authority, Project Manager, Project Board, and Technology
Portfolio Review Board.
 Overseeing the operation and performance of the Technical Design Authority.
Note: This committee is also responsible for conducting Enterprise Architecture Reviews required for
authority to proceed through Gate 0.
4.
Technical Assurance Review Scope
The scope of Technical Assurance Reviews includes the following:
 Traceability of the architecture and design to requirements
 Solution level architecture and design
 Selection and use of technology for systems development/maintenance and production operations
 Information security and ICT infrastructure protection
 Impacts to existing infrastructure capacity
 Non-functional characteristics including performance, availability, scalability, resilience
 Environments for production and non-production (development, test, QA, training)
 Production operations and support
 Software licensing impacts (where relevant)
 From a service-oriented architecture (SOA) perspective:
 re-use of existing services from the Service Registry
 application of design principles for new services to maximise their potential for re-use
Terms of Reference
Technical Design Authority
Version 1.06, Approved
31/05/2013
The University of Adelaide
Page 3 of 5
 changes to existing services to ensure are made in a controlled manner: i.e. include impact
assessment in consultation with the business and technical owners, regression testing of any
impacted systems, and planned migration into production
 Conformance to the University’s strategic direction and corresponding enterprise architecture
principles, architectures, and roadmaps
 Guidance and advice on leading practices, industry standards and conventions, and frameworks
and methods
 Technical risks and mitigation strategies
On a practical level, the scope of each Technical Assurance Review is to be constrained to those
aspects relevant to the associated lifecycle stage and characteristics of the solution.
The following areas are assumed to be reviewed and assured by the Project Management Office and
are therefore excluded from the Technical Assurance Review scope:
 Project management
 Financial and commercial management
 Business risk management
 Business solution deployment
 Business change management
However, the Technical Design Authority can and should bring concerns raised in these areas to the
attention of the Project Management Office on an exception basis.
5.
Technical Design Authority Membership
5.1. Standing Members
The following members form the core of the Technical Design Authority:




Enterprise Architect (Julius Schaffer – Chair)
Solution Architect (Andrew Stebbing)
Executive Officer (Melissa Gibbs)
Technology Team Managers (or proxies)
o Application Integration (Cosette Au-Yeung)
o Client Computing Services (Rob Lee)
o Client Delivery (Noel Threapleton)
o Enterprise Systems (Andrew Miller)
o Network Services (Pater Hughes)
o On Site Support (Lynette Paltridge)
o PeopleSoft Services (Vu Luc)
o Research Admin (Colin Gould)
o Security Services (Shu Sakai)
o Server and Storage Services (Mark Larsen)
o Service Desk (Natasha Crawford)
o Teaching Applications (Ian Roberts)
o Training Services (Terry O’Donnell)
 Manager, Business Intelligence, Planning and Performance Reporting (Adam Gardner)
 Deputy CIO, Application Services (Kerrie Campbell)
Terms of Reference
Technical Design Authority
Version 1.06, Approved
31/05/2013
The University of Adelaide
Page 4 of 5
5.2. Review Participant Members
In addition to standing members, the Technical Design Authority for a given Technical Assurance
Review will include additional members as nominated by the standing members together with the
TDA proposers. Nominations are to be made on the basis of areas of expertise and responsibility, and
can take into account the availability of particular individuals. Other subject matter experts from
Technology Services or other areas of the University may be called upon to participate in particular
reviews based on their expertise and availability.
6.
Technical Assurance Review Meetings
Quorum:
There is no formal requirement for a quorum.
Procedures:
Determined by itself.
Frequency of meetings:
Meetings are scheduled fortnightly on Thursdays from 9 to 10 am and
held as required.
List of any sub-committees:
No formal sub-committees are planned, although informal working
parties may be convened to develop specific documentation relating
to technical standards, reference architectures, and design patterns.
Terms of Reference
Technical Design Authority
Version 1.06, Approved
31/05/2013
The University of Adelaide
Page 5 of 5