TOGAF4G pillars

TOGAF4G Architecture Domains

TOGAF is based on four highly related specialisations called architecture domains. From these we evolve the TOGAF4G four pillars:

  • Country Governance Architecture
    • The strategy, governance, organisation, and key processes of the country governance
  • Government Architecture
    • A detailed plan for the government systems to be deployed, the interactions between these systems, and their relationships to the core governance processes with the frameworks for services to be exposed as government functions
  • Data Architecture
    • The structure of a country’s governance logical and physical data assets and the associated data management resources.
  • Technical architecture
    • Technology for governance, which describes the hardware, software, and network infrastructure needed to support the deployment of core, mission-critical applications

Architecture Development Method

The TOGAF Architecture Development Method (ADM).

The Architecture Development Method (ADM) is applied to develop an enterprise architecture which will meet the business and information technology needs of an organisation. It may be tailored to the organisation’s needs and is then employed to manage the execution of architecture planning activities.The process is iterative and cyclic. Each step checks with Requirements. Phase C involves some combination of both Data Architecture and Applications Architecture. Additional clarity can be added between steps B and C in order to provide a complete information architecture.

Performance engineering working practices are applied to the Requirements phase, and to the Business Architecture, Information System Architecture, and Technology architecture phases. Within Information System Architecture, it is applied to both the Data Architecture and Application Architecture.

Enterprise Continuum

The Enterprise Continuum is a way of classifying solutions and architectures on a continuum that ranges from generic foundation architectures through to tailored organization-specific both within and outside the Architecture Repository.These include architectural models, architectural patterns, architecture descriptions, and other artefacts. These artefacts may exist within the enterprise and also in the IT industry at large.

The Enterprise Continuum consists of both the Architecture Continuum and the Solutions Continuum. The Architecture Continuum specifies the structuring of reusable architecture assets and includes rules, representations, and relationships of the information system(s) available to the enterprise. The Solutions Continuum describes the implementation of the Architecture Continuum by defining reusable solutions building blocks.


Despite TOGAF being considered as the de facto standard in an EA practice, it is not without its critics. In this section, I will try and predict the future criticisms of the TOGAF4G variant.

  • Research evidence shows that “most TOGAF recommendations are usually found inapplicable” and not followed even in the organisations included in the list of TOGAF-users provided by The Open Group. That is why TOGAF can be considered only as “a toolkit of random EA-related recommendations” and “‘using TOGAF’ can be best explained as ‘studying TOGAF and then doing something else instead’”
    • Using full or entire TOGAF on any project or in any enterprise is very counter effective. TOGAF is vast. It was never designed to be used without some serious tailoring first. TOGAF works best when it is tailored a to a specific context.
    • TOGAF4G is probably a specific variant of TOGAF to evolve from it by crafty tailoring.
    • TOGAF4G is envisioned as a subset of TOGAF
    • Best TOGAF practitioners are the ones capable of effective refactoring of it for the particular organisation and the refactoring out that for particular projects in the organisations.
  • Real examples demonstrating the actual practical usage of TOGAF’s recommendations are missing. “There is a pressing need for some detailed worked examples and use cases. Although these were requested, they were not forthcoming from TOGAF trainers or The Open Group”
    • I have seen dozens of very good examples where organisations have made and TOGAF friendly environment by both organising architecture leadership and not imposing the full TOGAF on other roles in the teams.
  • EA practitioners report that TOGAF can hardly be followed step-by-step. “Our initial assumptions about TOGAF were that it would be a sort of ‘methodology’ that we could follow to produce our EA. However, this turned out not to be the case”
    • TOGAF is too big to be used as effective methodology out of the box.
    • It is critical to use its subset defined by resident TOGAF expert/
  • TOGAF’s prescriptions are vague and inarticulate since it “only states that the ADM should be adapted without specifying how”
    • “adapting the ADM” is wrong. The whole method has to be adapted by using its subset for the given context.

Better than doing nothing?

Well in the context of country governance and government that is certainly true. But in practice never the case. No government “does nothing”. But every government is constantly under monetary and political pressure to be more productive, resilient to change and to act as a robust and efficient system.
The aim of TOGAF4G is quite clear and simple: it is very efficient idea to start shaping up most productive and effective government.