Work
Home | Work | Play | Photos | Contact | About
Technical Design Authority (TDA)
Home > Work \ Technical Design Authority
Introduction
This post defines the purpose and scope of a Technical Design Authority (TDA). It identifies its participants; processes; outputs; and establishes a schedule. These four topics fall under the remit of the TDA -
- Technology Roadmaps
- Architecture Design Sessions
- Technical Design Reviews
- TDA Reviews
This post must remain succinct, unambiguous and useful 🤨
Purpose
The objective of the TDA is to ensure that IT projects create value, reduce development and operational costs, and where prudent, conform to published standards.
The TDA will meet this objective through compulsory technical reviews of:
- Proposed architectures, which are evaluated against project requirements and organisational standards. Evaluations also verify the outcomes of previous reviews and activities, and identify issues before committing to further work.
- Development practices, tools and technologies, which are evaluated against published standards and practices.
- Test practices, tools and technologies, which are evaluated against published standards and practices.
The TDA will run optional Architecture Design Sessions with project teams to assist in the tasks listed above, and the creation of the outputs described in the Outputs section.
The TDA will also maintain a technology roadmap by regularly assessing and when appropriate, recommending the adoption or abandonment of tools, technologies and related processes.
Finally, the TDA will monitor and track its effectiveness by periodically conducting reviews/self-assessments, and canvassing others (notably those it serves).
Scope
In Scope
The TDA concerns itself with broadly technical matters that facilitate a system-wide perspective. This includes:
- Systems and solutions
- Data
- Communications
- Quality objectives, including security
- Development and development operations (devops)
- Infrastructure including but not limited to directories; networks; servers, both on-site and remote/in clouds; workstations and mobile devices.
- Testing
- Tools, techniques, platforms, languages and frameworks
- Locations
Out of Scope
The following functions are too technically granular or not technical at all, and therefore beyond the scope of the TDA:
- Narrowly-scoped, localised technical concerns, such as a marketing department wishing to produce or edit video
- Business readiness
- Project governance
- Project management
- Troubleshooting existing projects and solutions
- Compliance (e.g. topics covered by the Change Advisory Board; privacy impact assessments)
- Low-level documentation, such as interface definitions and data dictionaries
The Privacy Impact Assessment
If you're in Europe you'll encounter the Privacy Impact Assessment (PIA). Assorted US agencies (the SEC, HHS, FTC, IRS, and DOD, to name a few) also require the completion of a PIA.
The PIA describes compliance with the data protection act (or your local version), which feeds into requirements. Completing a PIA is a function of business analysis. The PIA will certainly surface requirements that result in technical controls being implemented. These however, should be documented as requirements through established requirements gathering processes.
Responsibility for the PIA lies with governance, business readiness and compliance.
Data
The other thing the TDA should avoid is reviewing the data dictionary/data architecture
The TDA concerns itself with broadly-scoped technical concerns. A data dictionary is a fine-grained model of a physical data store, and is therefore beyond the remit of the TDA.
Responsibility for the data dictionary lies with governance, and may be tracked as any other project task is tracked.
Participants
By definition, a review must include both the project team and people external to it. As a recommended minimum the following people or roles should be required to participate in reviews:
- Project representative
- Solutions architecture
- Infrastructure architecture
- Development management
- Test management
- Operational management
Inputs
The ! symbol identifies mandatory inputs.
- Conceptual design ! – documents the vision and scope, and high-level components of the system, their inter-relationships, and external dependencies. The conceptual design is written for technical and non-technical audiences, such as management, marketing, and users. It consists of an architecture diagram (without interface detail); an informal specification for each tier and component; a conceptual data model; and defines system quality objectives.
- Technical design – defines products and technologies; makes externally visible properties of the components precise and unambiguous through an interface and component specification. It may also document the logical data design, system layers, key architectural mechanisms; and refine quality objectives.
- Deployment model ! – describes the physical environment that the system will operate in. The model shows the mapping of (physical) components to nodes of the physical system, and includes external or shared components that provide security or operational functions.
- Development and test health checks ! – assesses the technical and quality processes, tools and telemetry required to deliver project requirements.
Processes
Architecture Design Sessions
The main, verifiable goal of an Architecture Design Session (ADS) is decision-maker agreement to a preliminary solution. However, every ADS should also:
- Document the customer's high-level needs
- Understand the customer's challenges
- Remove technical objections, blockers, and risks (real and perceived)
- Get the project started with the right tools and techniques
- Assist in creating a technical design
Architecture Design Sessions are recommended, but optional.
Technical Assessments
The primary goal of the TDA is to review, guide, and record architectural decisions. To meet this goal, the TDA will review technical project documentation as described in section 3 above, and the output created in an ADS. Specifically,
- Project representatives will create and distribute documentation produced by the ADS
- The TDA will assess, review and approve technical solution designs, and ongoing development and test health checks
- The TDA will document suggested guidance; monitor technical risks and issues; and document organisational and technical debt
- Project representatives will apply guidance, and manage risks and issues
Technology Roadmaps
A secondary goal of the TDA is to assess, review and recommend technical techniques, tools, platforms, and languages and frameworks for use within the organisation. Recommendations are recorded in a document which is made available to all technical stakeholders throughout the group.
TDA Reviews
The TDA will undertake self-assessments to review its effectiveness and judge how well it performs in relation to its stated objectives. TDA members will score the TDA as a whole, and external stakeholders will be asked to complete or participate in reviews, which will be used to fine-tune the TDA's role, its processes and its membership.
Outputs
Architecture Design Sessions
- Conceptual design - describes how the features and functions will operate together to form the solution. It identifies the specific components of the solution and their relationships. The conceptual design converts the list of features and functions into a description of a fully functional, integrated environment
- Technical design - documents the application of specific tools and technologies to the conceptual design. It is a high-level description of the key products and technologies to be used in developing the solution
The above can be combined into a single document.
Technical Assessments
- Design review outcomes
- Meeting minutes
Development health checks
- Development health check document
- Test health check document (may be combined with the development health check document)
Technology Roadmap
- A document that highlights changes to techniques, tools, platforms, or languages and frameworks that are deemed relevant and/or interesting - things that the company should use, develop skills in, or simply monitor for potential applications within the company. See the Wikipedia article for more.
TDA Reviews
- The purpose, structure and operating procedures of the TDA will be recorded and revised in this document (TDA Terms of Reference). If required, the document is revised and published after TDA reviews.
Schedule
- Architecture Design Sessions - ADSs are driven by project needs, and are scheduled on an ad hoc basis by project representatives as required.
- Technical assessments - the TDA meets twice a month. Emergency TDAs are discouraged but may be required to meet deadlines or avoid schedule conflicts. Be pragmatic.
- Technology roadmap - the TDA will meet twice a year to review the technology roadmap. Additional meetings can be requested where warranted by a new discovery or shift in techniques, tools, platforms or languages and frameworks.
- TDA Reviews - The TDA will conduct self-assessments twice a year.
Technical assessments will be minuted. All documents by or for the TDA will be stored in an architecture document repository capable of enforcing organisational security practices and policies.
< Back to Work | ^ Back to top
All content copyright © Michael Wittenburg 1995 to 2024. All rights reserved.
Merch (t-shirts designed by my twin)