Working Page for the Views & Viewpoints Working Group – All Materials are DRAFT. 


This framework[1]  starts with a ‘5Ps’ variant of the old Group Dynamics project life-cycle, with Purpose, People, Preparation, Process and Performance. This concept is outlined in table 1.

Purpose About WHY of business, beginnings, intentions, strategy, direction
People About WHO, teams, skill-sets and relationships that we need to put the strategy into action
Preparation About WHAT, WHERE, WHEN, HOW, It grounds the ideas and arguments into a concrete plan
Process (or Practice) Puts that plan into action
Performance Assesses the results – not just of the Process, but also of the Integration of the whole – feeding back into the Purpose for a new cycle.

Table 1: 5P’s variant

Each of these points in the cycle is also a perspective onto the whole, and provides shared requirements that impact on the rest of the enterprise.


Figure 1: Life-cycle framework

Mapping these, in turn to the issues and artefacts that would be the concern of enterprise architecture, we find a framework that looks like this:


Figure 2: Life-cycle framework with EA artefacts.

The framework applies a systems-principle called recursion, and get each view to look at each of the others, and at the integration of the whole. In other words, each view also contains within itself a sense of all the others.

Although they are similar to those ‘5Ps’, we give these sideways views a slight twist, to give us the keywords:

  • Efficient
  • Reliable
  • Elegant
  • Appropriate
  • Integrated

The Viewpoints

The previous set of views-within-views give an overall framework that takes very little effort to translate it into practice. Its consistency and symmetry make it easy to apply across the full scope of the enterprise.

This provides the skeleton of the framework: one section for each of the five focus-types, each with five short chapters emphasizing specific aspects of effectiveness in relation to enterprise architecture.

Each view is named with a label into two-letter codes as follows:


Table 2: Set of views-within-views.

The following sections explain each group.

D Group: Purpose – Direction


Table 3: Purpose (Direction) group

This is about the far future focus of business direction and strategy, typically the preserve of management.

  • DA: The aims of architecture

It explores the business drivers and the need to reduce cost and complexity, indentifies the overall purpose of the organizacion’s enterprise architect and delivers a list of core requirements and key success criteria.

  • DN: Architecture of the enterprise

It reviews the development of Enterprise Architecture from its roots in IT, identifies the scope for the enterprise architecture and assesses the maturity level of the present architecture.

  • DR: The Architecture of the everyday

It illustrates the need for Enterprise Architecture to be relevant to everyday practice, assisting in the day-to-day decisions and identifies the purpose of the day-to day architecture activities and the interaction and impacts these will have with other activities within and beyond the organization.

  • DE: Architecture on purpose

It explores the audit-trail of visión, role, missions and goals which provide the anchor for business motivation and establishes foundation for enterprise business motivation model and framework for motivation audit-trail processes.

  • DL: Architecture is a feeling

It reminds us that an Enterprise is made up of people and identifies values to be expressed and embedded in the enterprise architecture and to be used as a bridge with customers, partners and other stakeholders.

P Group – People


Table 4: People group.

  • PL: The Architecture team

It addresses the nature of the EA team itself and identifies the make-up of the enterprise architecture team, the required collective and individual skill-set and performance criteria.

  • PA: The politics of purpose

It reminds us that everything in an Enterprise is underpinned by the complex politics of change and identifies change management strategy required to address likey challenges to development and roll-out of whole of organization enterprise architecture.

  • PR: A problem of power

It tackles the subtle balance of power and responsibility upon which the successful implementation of the EA will depend and establishes a framework to monitor the ability to do work across the enterprise and to guide responses to issues identified in such monitoring.

  • PN: The role of the generalist

It identifies both the difficulties faced by those often unnoticed work provides the bridges between organisational silos and any additional cross-functional generalist roles required to implement enterprise architecture, the requird skill sets and recommended performance criteria.

  • PE: What’s the story?

It focuses on the narrative knowledge shared by and between people and identifies the scope and support for non IT based knowledge and key players within the narrative knowledge network.

K Group: Preparation – Knowledge


Table 5: Preparation (Knowledge) group.

  • KE: Dimensions of Architecture

It takes a more in-depth look at the business dimensions that underpin the framework and establishes a framework for whole of organization integration.

  • KN: An emphasis on effectiveness

It expands on those views for assessing effectiveness: efficient, reliable, elegant, apropiate, integrated and establishes frameworks for assessment, review and meauserement of cross functional effectiveness.

  • KA: Architecture as a way of thinking

It introduces the strange realms of system-theory and their inmediate practical Applications and identifies the key frameworks and theorical models that will be used to guide enterprise architecture principles and practice.

  • KL: A question of responsibility

It addressess the importance of responsibility-based ownership for the non-tangible assets (projects, business data, business rules) and establishes framework for responsibility-based ownership of core non-tangible assets.

  • KR: The centrality of services

It expands the core concept of service in a Service Oriented Architecture. Establish framework for a high level service oriented architecture.

T Group: Process – Tasks


Table 6: Process (Tasks) group.

  • TE: Requirements for agility

IT Surveys some of the agile methodologies such as XP and DSDM and establishes a methodology and cross-functional repository for business-system requirements.

  • TN: Managing services

It describes the role of complementary frameworks such as ITIL, TQM and COBIT, and the Integration into a broader EA and establishes framework for management and governance of high level service oriented architecture.

  • TR: The practice of architecture

It goes into more detail on the iterative, recursive process of creating and managing compliance to an EA and establishes and use methodology for operation, management and governance of whole of enterprise architecture, including toolsets.

  • TL: The art of integration

It looks at how to use a unifying theme: privacy, quality, trust or waste-reduction, and identifies and establish frameworks to use one or more unifying themes for integration.

  • TA: What’s the SCORE

It introduces a strategic tool to assess potential impacts on overall efectiveness and establish framework for strategic and architectural assessment of cross-functional effectiveness.

M Group: Performance – Metrics, artefacts and outcomes


Table 7: Performance (Metrics) group.

  • MR: Real-time scoreboards

It investigates sources for key information in a balance scorecard to track Enterprise performance and establishes framework and metrics to track integration and performance in real time.

  • ME: Closing the loop

It explore the mechanisms needed for feedback from other áreas into the EA and establishes framework for feedback into enterprise architecture.

  • ML: People and performance

It describes a method to identify the ability to do work across the Enterprise, and how to use that information and establishes framework for monitoring cross-functional ability to work.

  • MA: Measuring maturity

Is about the capability of the EA itself, and what needs to be done at each stage to expand its potential. It establishes framework and metrics to monitor performance and maturity for enterprise architecture.

  • MN: Monitoring Integration

It summarizes the frameworks and metrics needed to monitor impact of EA and establishes framework and metrics to monitor impact of enterprise architecture on the organization integration.


This approach is about the practice of enterprise architecture at the level of the whole enterprise. It is for anyone who works with the enterprise as a whole: chief officers, strategists, programme management office and that kind of roles.

General Advice

The suggestion is apply this framework using the same sequence as the main pattern: purpose (Direction), people, preparation (Knowledge), process (Tasks) and performance (Metrics).


Figure 3: 5P’s architecture framework.

If the Open Group Architecture Framework is familiar, is possible recognize some similarities of the ADM with the cycle shown. The difference is that there is no special emphasis given to IT: it is just one part of a much larger whole.


[1]. Real Enterprise Architecture. Beyond IT to the whole enterprise. Tom Graves. ISBN 978-1-906681-00-5



Hernan Dario Rodriguez,   CITA-F  TOGAF

Hernan Dario Rodriguez is a consultant Enterprise/Solution Architect that works in Colombia. He has more than 16 years of experience in different industries such as healthcare, oil & gas, pharma and technology consulting. He is an IASA member, CITA Foundation Certified Architect and TOGAF 9 Certified.

He currently works as Information Architect for a leading digital company in financial services sector.

Check out his profile on