A practical guide to TOGAF for government architects

Government architecture is the discipline of connecting public policy, services, information, technology and organisational capability. A ministry may have a clear strategic goal, yet still struggle with duplicated systems, inconsistent data, ageing infrastructure or procurement decisions made without a long-term view. Enterprise architecture provides a structured way to understand those relationships and make better investment choices.

TOGAF, the Open Group Architecture Framework, is widely used as a reference for this work. It is not a government operating model, a software product or a mandatory set of templates. It is a framework that helps architects organise decisions, engage stakeholders and guide change from a current state towards a target state.

For Australian public-sector teams, the framework needs to fit a federated environment. Commonwealth departments, state and territory agencies, local councils and government-owned organisations have different mandates, budgets, security obligations and delivery methods. An architecture approach that works for a large Canberra department may need substantial adaptation for a council serving regional communities or a shared-services agency in Melbourne.

This practical guide focuses on how government architects can use TOGAF without creating unnecessary bureaucracy. It explains the core ideas, relates them to public administration, and shows how to connect architecture work with funding, procurement, cybersecurity, legislation and service delivery.

Area	TOGAF provides	Government architects still need
Strategy	A method for translating goals into architecture work	Policy interpretation, ministerial priorities and public-value measures
Architecture domains	Business, data, application and technology viewpoints	Agency-specific capability models and operational knowledge
Delivery	Phases for planning, designing, implementing and governing change	Agile delivery methods, investment gates and vendor management
Governance	Decision rights, principles and compliance checkpoints	Legislative authority, security accreditation and accountability
Outputs	Reusable artefacts, roadmaps and architecture definitions	Clear, proportionate documentation that teams will actually use

What TOGAF is designed to do

TOGAF gives an organisation a repeatable architecture development method. Its central idea is the Architecture Development Method, commonly called the ADM. The ADM takes architects through a cycle that begins with preparation and vision, moves through business, information systems and technology architecture, and continues into opportunities, migration planning, implementation governance and change management.

The cycle is intended to be iterative. A government program may begin with a broad service vision, discover a legal or technical constraint during data analysis, and then revisit the target architecture. This is useful in public administration because policy, funding and delivery conditions often change before a multi-year program is complete.

The framework also promotes architecture content and capability. Content describes the building blocks, deliverables and artefacts used to explain an architecture. Capability covers the people, governance arrangements, skills, tools and processes required to perform architecture work consistently. These areas help prevent an architecture practice from becoming dependent on one senior specialist.

TOGAF does not tell an agency which cloud provider to choose, whether a service should be built in-house, or how to comply with every Australian obligation. Its value is in providing a common language and decision process. Architects must combine it with local policy, security standards, financial rules, procurement requirements and delivery expertise.

Start with the public value and problem

A weak architecture engagement often starts with a requested system: replace the grants platform, establish a data lake, procure a customer relationship system or move workloads to the cloud. A stronger engagement starts with the public outcome. The question becomes what the agency needs to achieve for citizens, businesses, frontline staff and government decision-makers.

For example, a state transport agency may want to reduce the time required to report a lost concession card. The architecture problem could involve identity verification, eligibility data, mobile service design, integration with payment systems and accessible support channels. Treating the request as “build an app” would hide most of the important decisions.

The Architecture Vision phase is especially valuable for creating a shared understanding. A concise vision should state the problem, desired outcomes, scope, affected stakeholders, constraints, risks and measures of success. It should be understandable to a deputy secretary, program director, procurement adviser and technical lead without requiring each person to interpret specialist diagrams.

Government architects should identify the authority for the work at this stage. A program may be driven by legislation, a budget announcement, an audit recommendation, a cabinet decision or a service standard. Recording that source clarifies why the architecture matters and prevents the team from designing an attractive solution without a legitimate mandate.

Build the four architecture views

TOGAF commonly describes four connected domains: business architecture, data architecture, application architecture and technology architecture. They should be treated as different views of one operating model rather than four isolated documents.

Business architecture explains capabilities, value streams, services, roles and organisational responsibilities. In government, it can reveal that several agencies perform similar functions under different names, or that a citizen journey crosses departmental boundaries. Capability mapping is particularly useful for investment planning because it shows where a capability is weak, duplicated or strategically important.

Data architecture addresses information ownership, definitions, quality, movement, access and retention. This is a major concern where agencies exchange information about individuals, businesses, health, welfare or property. In Australia, design decisions must take account of the Privacy Act 1988 and applicable state or territory privacy legislation, alongside records obligations and information-sharing authorities.

Application architecture describes the systems and services that support business capabilities, including interfaces and dependencies. Technology architecture covers platforms, networks, hosting, devices, identity services and technical standards. A practical architecture links all four views: a service capability depends on particular information, which is handled by applications running on technology under defined security controls.

The relationship can be explained through a traceability chain: policy outcome, business capability, information requirement, application service, technology component and delivery initiative. This chain helps executives understand why a technical investment is needed and helps delivery teams see how their work contributes to a public result.

Adapt the ADM to Australian government

The full ADM can appear heavy when applied to a small project. Government architects should tailor the method according to risk, complexity, duration and public impact. A modest internal workflow may need a short architecture decision record, while a national identity service requires extensive security, privacy, interoperability and operational analysis.

Australian agencies also work within several governance environments. Commonwealth projects may need to align with the Digital Service Standard, the Protective Security Policy Framework, the Information Security Manual and the Commonwealth Procurement Rules. State and territory agencies have their own policies, assurance processes and technology panels. Architecture governance should map these obligations rather than create a parallel compliance system.

Procurement needs early attention. If a target architecture assumes a particular proprietary platform before the market is tested, the agency may limit competition or create a long-term dependency. Architects should describe required capabilities, interoperability, service levels, security outcomes and exit conditions clearly enough for the market to respond. This is particularly important in a local market where specialist suppliers may be concentrated in Sydney, Melbourne, Brisbane and Canberra.

The ADM can operate alongside agile delivery. Architecture establishes guardrails, target states and important decisions, while product teams refine increments through discovery, delivery and user research. An architecture runway can identify the enabling work needed for future releases without requiring every detail to be designed years in advance.

Make governance useful rather than ceremonial

Architecture governance is the system for making, recording and reviewing significant decisions. It may involve an architecture board, design authority, security advisers, data custodians, finance representatives, procurement specialists and business owners. The structure should match the agency’s authority and scale rather than imitate a large corporate model.

A useful governance forum focuses on decisions that affect multiple teams or create material risk. Examples include adopting a shared identity service, approving an integration pattern, accepting a data-quality limitation, choosing a hosting model or allowing an exception to an architecture principle. Each decision should have an owner, evidence, conditions and a review point.

Architecture principles should be short and actionable. “Use open standards where practical”, “protect information according to its sensitivity”, “design for reuse”, and “make services accessible” are more useful when accompanied by decision tests and named accountability. Principles should support judgement, not replace it.

A decision register is often more valuable than a large repository of diagrams. It records what was decided, why it was decided, what alternatives were considered and when the decision should be revisited. This improves continuity when staff change and provides an audit trail for major public investments.

Cybersecurity and privacy should be built into every domain. Architects can support non-technical executives by explaining threat exposure, likely impacts, treatment options and residual risk in plain language. A cybersecurity policy guide can help teams frame those issues for decision-makers who are responsible for risk but do not work with security controls every day.

Turn architecture into a roadmap

A target architecture has little practical value unless it can be reached through funded and governed change. Migration planning converts the target state into a sequence of work packages, dependencies, transition architectures, costs, risks and benefits. It should show what can be delivered now, what must wait, and which temporary states are acceptable.

Transition architectures are especially important in government. An agency may need to run a legacy case-management system while introducing a new digital channel, shared identity capability or data exchange layer. The interim state should be deliberate, with a retirement or containment plan, rather than becoming an accidental permanent arrangement.

Roadmaps should connect to budget cycles, portfolio plans, procurement timing and workforce capacity. A technically logical sequence may be impossible if funding is annual, a contract expires in six months, or the agency lacks specialists to operate a new platform. Architecture teams need enough commercial and operational awareness to identify these realities early.

Benefits should be measurable where possible. Measures might include reduced processing time, fewer duplicated records, improved service availability, lower infrastructure cost, faster information exchange or better accessibility. Public value may also include stronger resilience, improved trust and reduced risk, even when savings are not immediate.

The E-Pragati resource hub offers broader unofficial reference material on digital governance, ICT management, cybersecurity and government transformation. It is an independent information website, not an Australian or foreign government department, so architects should verify official requirements through the relevant agency and legislation.

Use architecture to improve citizen services

The best test of an architecture is whether it improves the experience and outcomes of people using a public service. A technically elegant platform can still fail if residents cannot understand eligibility, must repeat information, or are excluded by poor accessibility, limited connectivity or a lack of assisted support.

Australian service design should account for different contexts: a busy commuter in Sydney, an older resident in regional South Australia, a small business in Brisbane, and an Aboriginal community with specific cultural and connectivity needs may interact with the same service in very different ways. Architecture should support multiple channels and avoid assuming that every transaction will occur through a smartphone.

Artificial intelligence and chatbots introduce additional architecture questions. Teams need to consider identity, content sources, records, accessibility, escalation to staff, hallucination risk, privacy and monitoring. A chatbot should be treated as part of a broader service and information architecture rather than installed as an isolated conversational feature. Guidance on government chatbot use can help frame these questions before a pilot moves into production.

A mature architecture practice keeps learning after implementation. Post-delivery reviews should examine whether the expected outcomes were achieved, whether controls worked, which assumptions changed and whether reusable components can support another service. Feedback from call-centre staff, case workers, community organisations and citizens can reveal architectural problems that technical monitoring alone will miss.

Government architects can begin with one significant service or program, define the public outcome, map its capabilities and dependencies, and create a small set of architecture principles and decision records. Use the TOGAF method as a practical navigation aid, tailor its deliverables to risk, and connect every major design choice to law, policy, funding, security and human needs. That approach turns enterprise architecture from a document exercise into a disciplined way to deliver better government.