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: February, 2013
By authority of: University ICT Architecture Committee
For period: Review effectiveness and terms of reference in January, 2014
Reporting to: University ICT Architecture Committee and Project Boards as appropriate
2. 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
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.
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
§ 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)
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 Version 1.06, Approved The University of Adelaide
Technical Design Authority 31/05/2013 Page 1 of 5