2. Preliminary Phase

This chapter describes the preparation and initiation activities required to meet the business directive for a new Enterprise Architecture, including the definition of an Organization-Specific Architecture framework and the definition of principles.

2.1 Objectives

The objectives of the Preliminary Phase are to:

1. Determine the Architecture Capability desired by the organization:
   • Review the organizational context for conducting Enterprise Architecture
   • Identify and scope the elements of the enterprise organizations affected by the Architecture Capability
   • Identify the established frameworks, methods, and processes that intersect with the Architecture Capability
   • Establish Capability Maturity target
2. Establish the Architecture Capability:
   • Define and establish the Organizational Model for Enterprise Architecture
   • Define and establish the detailed process and resources for Architecture Governance
   • Select and implement tools that support the Architecture Capability
   • Define the Architecture Principles

2.2 Inputs

This section defines the inputs to the Preliminary Phase.

2.2.1 Reference Materials External to the Enterprise

• The TOGAF Library
• Other architecture framework(s), if required

2.2.2 Non-Architectural Inputs

• Board strategies and board business plans, business strategy, IT strategy, business principles, business goals, and business drivers, when pre-existing
• Major frameworks operating in the business; e.g., project/portfolio management
• Governance and legal frameworks, including Architecture Governance strategy, when pre-existing
• Architecture capability
• Partnership and contract agreements

2.2.3 Architectural Inputs

Pre-existing models for operating an Enterprise Architecture Capability can be used as a baseline for the Preliminary Phase. Inputs would include:

• Organizational Model for Enterprise Architecture (see the TOGAF Standard — Architecture Content), including:
  • Scope of organizations impacted
  • Maturity assessment, gaps, and resolution approach
  • Roles and responsibilities for architecture team(s)
  • Budget requirements
  • Governance and support strategy
• Existing Architecture Framework, if any, including:
  • Architecture method
  • Architecture content
  • Configured and deployed tools
  • Architecture Principles
  • Architecture Repository

2.3 Steps

The TOGAF ADM is a generic method, intended to be used by a wide variety of different enterprises, and in conjunction with a wide variety of other architecture frameworks, if required. The Preliminary Phase therefore involves doing any necessary work to initiate and adapt the ADM to define an organization-specific framework. The issues involved with adapting the ADM to a specific organizational context are discussed in detail in 1.3 Adapting the ADM .

The level of detail addressed in the Preliminary Phase will depend on the scope and goals of the overall architecture effort.

The order of the steps in the Preliminary Phase as well as the time at which they are formally started and completed should be adapted to the situation at hand in accordance with the established Architecture Governance.

The steps within the Preliminary Phase are as follows:

• Scope the enterprise organizations impacted (see 2.3.1 Scope the Enterprise Organizations Impacted )
• Confirm governance and support frameworks (see 2.3.2 Confirm Governance and Support Frameworks )
• Define and establish Enterprise Architecture team and organization (see 2.3.3 Define and Establish Enterprise Architecture Team and Organization)
• Identify and establish Architecture Principles (see 2.3.4 Identify and Establish Architecture Principles)
• Tailor the TOGAF framework and, if any, other selected architecture frameworks (see 2.3.5 Tailor the TOGAF Framework and, if any, Other Selected Architecture Framework(s))
• Develop a strategy and implementation plan for tools and techniques (see 2.3.6 Develop a Strategy and Implementation Plan for Tools and Techniques)

2.3.1 Scope the Enterprise Organizations Impacted

• Identify core enterprise (units) — those who are most affected and achieve most value from the work
• Identify soft enterprise (units) — those who will see change to their capability and work with core units but are otherwise not directly affected
• Identify extended enterprise (units) — those units outside the scoped enterprise who will be affected in their own Enterprise Architecture
• Identify communities involved (enterprises) — those stakeholders who will be affected and who are in groups of communities
• Identify governance involved, including legal frameworks and geographies (enterprises)

2.3.2 Confirm Governance and Support Frameworks

The architecture framework will form the keystone to the flavor (centralized or federated, light or heavy, etc.) of Architecture Governance organization and guidelines that need to be developed. Part of the major output of this phase is a framework for Architecture Governance. We need to understand how architectural material (standards, guidelines, models, compliance reports, etc.) is brought under governance; i.e., what type of governance repository characteristics are going to be required, what relationships and status recording are necessary to ascertain which governance process (dispensation, compliance, take-on, retirement, etc.) has ownership of an architectural artifact.

It is likely that the existing governance and support models of an organization will need to change to support the newly adopted architecture framework.

To manage the organizational change required to adopt the new architectural framework, the current enterprise governance and support models will need to be assessed to understand their overall shape and content. Additionally, the sponsors and stakeholders for architecture will need to be consulted on potential impacts that could occur.

Upon completion of this step, the architecture touch-points and likely impacts should be understood and agreed by relevant stakeholders.

2.3.3 Define and Establish Enterprise Architecture Team and Organization

• Determine existing enterprise and business capability
• Conduct an Enterprise Architecture/business change maturity assessment, if required
• Identify gaps in existing work areas
• Allocate key roles and responsibilities for Enterprise Architecture Capability management and governance
  
• Define requests for change to existing business programs and projects:
  • Inform existing Enterprise Architecture and IT architecture work of stakeholder requirements
  • Request assessment of impact on their plans and work
  • Identify common areas of interest
  • Identify any critical differences and conflicts of interest
  • Produce requests for change to stakeholder activities
• Determine constraints on Enterprise Architecture work
• Review and agree with sponsors and board
• Assess budget requirements

2.3.4 Identify and Establish Architecture Principles

Architecture Principles (see the TOGAF Standard — ADM Techniques) are based on business principles and are critical in setting the foundation for Architecture Governance. Once the organizational context is understood, define a set of Architecture Principles that is appropriate to the enterprise.

2.3.5 Tailor the TOGAF Framework and, if any, Other Selected Architecture Framework(s)

In this step, determine what tailoring of the TOGAF framework is required. Consider the need for:

• Terminology Tailoring: architecture practitioners should use terminology that is generally understood across the enterprise

  Tailoring should produce an agreed terminology set for description of architectural content. Consideration should be given to the creation of an Enterprise Glossary, to be updated throughout the architecture process.

• Process Tailoring: the TOGAF ADM provides a generic process for carrying out architecture

  Process tailoring provides the opportunity to remove tasks that are already carried out elsewhere in the organization, add organization-specific tasks (such as specific checkpoints), and to align the ADM processes to external process frameworks and touch-points. Key touch-points to be addressed would include:

  • Links to (project and service) portfolio management processes
  • Links to project lifecycle
  • Links to operations handover processes
  • Links to operational management processes (including configuration management, change management, and service management)
  • Links to procurement processes
• Content Tailoring: using the TOGAF Architecture Content Framework and Enterprise Continuum as a basis, tailoring of content structure and classification approach allows adoption of third-party content frameworks and also allows for customization of the framework to support organization-specific requirements

2.3.6 Develop a Strategy and Implementation Plan for Tools and Techniques

There are many tools and techniques which may be used to develop Enterprise Architecture across many domains. The development of a tools strategy is recommended that reflects the understanding and level of formality required by the enterprise's stakeholders. Architecture content will be highly dependent on the scale, sophistication, and culture of both the stakeholders and the Architecture Capability within the organization. A tools strategy which recognizes the stakeholders' articulation requirements will enable more effective and rapid decision-making by stakeholders and their ownership of artifacts.

The strategy should encompass management techniques, decision management, workshop techniques, business modeling, detailed infrastructure modeling, office products, languages, and repository management as well as more formal architecture tools. For example, the Balanced Scorecard technique is a best practice performance measurement tool used by business schools and many organizations that can be used successfully in architecture projects.

The implementation of the tools strategy may be based on common desktop and office tools or may be based on a customized deployment of specialist management and architecture tools. Change management of the artifact deliverables is a major consideration and a degree of management control and governance of artifacts needs to be considered. Access to decisions needs to be managed carefully as many of the artifacts may contain sensitive information. Therefore the tools implementation, access, and security of the content needs to reflect the sensitivity requirements.

2.3.6.1 Issues in Tools Standardization

In the current state of the tools market, many enterprises developing Enterprise Architectures struggle with the issue of standardizing on tools, whether they seek a single "one size fits all" tool or a multi-tool suite for modeling architectures and generating the different architecture views required.

There are ostensible advantages associated with selecting a single tool. Organizations following such a policy can hope to realize benefits such as reduced training, shared licenses, quantity discounts, maintenance, and easier data interchange. However, there are also reasons for refusing to identify a single mandated tool, including reasons of principle (endorsing a single architecture tool would not encourage competitive commercial innovation or the development of advanced tool capability); and the fact that a single tool would not accommodate a variety of architecture development "maturity levels" and specific needs across an enterprise.

Successful Enterprise Architecture teams are often those that harmonize their architecture tools with their architecture maturity level, team/organizational capabilities, and objectives or focus. If different organizations within an enterprise are at different architecture maturity levels and have different objectives or focus (e.g., Enterprise versus Business versus Technology Architecture), it becomes very difficult for one tool to satisfy all organizations' needs.

2.4 Outputs

The outputs of the Preliminary Phase may include, but are not restricted to:

• Organizational Model for Enterprise Architecture (see the TOGAF Standard — Architecture Content), including:
  • Scope of organizations impacted
  • Maturity assessment, gaps, and resolution approach
  • Roles and responsibilities for architecture team(s)
  • Constraints on architecture work
  • Budget requirements
  • Governance and support strategy
• Tailored Architecture Framework (see the TOGAF Standard — Architecture Content), including:
  • Tailored architecture method
  • Tailored architecture content (deliverables and artifacts)
  • Architecture Principles (see the TOGAF Standard — Architecture Content)
  • Configured and deployed tools
• Initial Architecture Repository (see the TOGAF Standard — Architecture Content), populated with framework content
• Restatement of, or reference to, business principles, business goals, and business drivers (see the TOGAF Standard — Architecture Content)
• Request for Architecture Work (optional) (see the TOGAF Standard — Architecture Content)
• Architecture Governance Framework (see the TOGAF Standard — EA Capability and Governance)
• The Architecture of the Enterprise Architecture Capability (see the TOGAF Standard — EA Capability and Governance)

The outputs may include some or all of the following:

• Catalogs:
  • Principles catalog

2.5 Approach

This Preliminary Phase is about defining "where, what, why, who, and how we do architecture" in the enterprise concerned. The main aspects are as follows:

• Defining the enterprise
• Identifying key drivers and elements in the organizational context
• Defining the requirements for architecture work
• Defining the Architecture Principles that will inform any architecture work
• Defining the framework to be used
• Defining the relationships between management frameworks
• Evaluating the Enterprise Architecture maturity

The Enterprise Architecture provides a strategic, top-down view of an organization to enable executives, planners, architects, and engineers to coherently co-ordinate, integrate, and conduct their activities. The Enterprise Architecture framework provides the strategic context within which this team can operate.

Therefore, developing the Enterprise Architecture is not a solitary activity and the Enterprise Architects need to recognize the interoperability between their frameworks and the rest of the business.

Strategic, interim, and tactical business objectives and aspirations need to be met. Similarly, the Enterprise Architecture needs to reflect this requirement and allow for operation of architecture discipline at different levels within the organization.

Depending on the scale of the enterprise and the level of budgetary commitment to Enterprise Architecture discipline, a number of approaches may be adopted to sub-divide or partition architecture teams, processes, and deliverables. Approaches for architecture partitioning are discussed in the TOGAF Standard — Architecture Content. The Preliminary Phase should be used to determine the desired approach to partitioning and to establish the groundwork for the selected approach to be put into practice.

The Preliminary Phase may be revisited, from the Architecture Vision phase (see the TOGAF Standard — Applying the ADM), in order to ensure that the organization's Architecture Capability is suitable to address a specific architecture problem.

The Preliminary Phase is about creating an architecture for the Enterprise Architecture Capability in an organization. As such, the same best practices employed in developing any architecture should be used here. Refer to the TOGAF Standard — EA Capability and Governance for an explanation about the application of the TOGAF ADM to establish the Enterprise Architecture Capability.

Further guidance on how to construct an Enterprise Architecture Capability may be found in the following document:

• TOGAF® Series Guide: The TOGAF Leader's Guide to Establishing and Evolving an EA Capability

2.5.1 Enterprise

One of the main challenges of Enterprise Architecture is that of enterprise scope.

The scope of the enterprise, and whether it is federated, will determine those stakeholders who will derive most benefit from the Enterprise Architecture Capability. It is imperative that a sponsor is appointed at this stage to ensure that the resultant activity has resources to proceed and the clear support of the business management. The enterprise may encompass many organizations and the duties of the sponsor are to ensure that all stakeholders are included in defining, establishing, and using the Architecture Capability.

2.5.2 Organizational Context

In order to make effective and informed decisions about the framework for architecture to be used within a particular enterprise, it is necessary to understand the context surrounding the architecture framework. Specific areas to consider would include:

• The commercial models for Enterprise Architecture and budgetary plans for Enterprise Architecture activity; where no such plans exist, the Preliminary Phase should be used to develop a budget plan
• The stakeholders for architecture in the enterprise; their key issues and concerns
• The intentions and culture of the organization, as captured within board business directives, business imperatives, business strategies, business principles, business goals, and business drivers
• Current processes that support execution of change and operation of the enterprise, including the structure of the process and also the level of rigor and formality applied within the organization

  Areas for focus should include:

  • Current methods for architecture description
  • Current project management frameworks and methods
  • Current systems management frameworks and methods
  • Current project portfolio management processes and methods
  • Current application portfolio management processes and methods
  • Current technology portfolio management processes and methods
  • Current information portfolio management processes and methods
  • Current systems design and development frameworks and methods
• The Baseline Architecture landscape, including the state of the enterprise and also how the landscape is currently represented in documentation form
• The skills and capabilities of the enterprise and specific organizations that will be adopting the framework

Review of the organizational context should provide valuable requirements on how to tailor the architecture framework in terms of:

• Level of formality and rigor to be applied
• Level of sophistication and expenditure required
• Touch-points with other organizations, processes, roles, and responsibilities
• Focus of content coverage

2.5.3 Requirements for Architecture Work

The business imperatives behind the Enterprise Architecture work drive the requirements and performance metrics for the architecture work. They should be sufficiently clear so that this phase may scope the business outcomes and resource requirements, and define the outline enterprise business information requirements and associated strategies of the Enterprise Architecture work to be done. For example, these may include:

• Business requirements
• Cultural aspirations
• Organization intents
• Strategic intent
• Forecast financial requirements

Significant elements of these need to be articulated so that the sponsor can identify all the key decision-makers and stakeholders involved in defining and establishing an Architecture Capability.

2.5.4 Principles

The Preliminary Phase defines the Architecture Principles that will form part of the constraints on any architecture work undertaken in the enterprise. The issues involved in this are explained in the TOGAF Standard — ADM Techniques.

The definition of Architecture Principles is fundamental to the development of an Enterprise Architecture. Architecture work is informed by business principles as well as Architecture Principles. The Architecture Principles themselves are also normally based in part on business principles. Defining business principles normally lies outside the scope of the architecture function. However, depending on how such principles are defined and promulgated within the enterprise, it may be possible for the set of Architecture Principles to also restate, or cross-refer to a set of business principles, business goals, and strategic business drivers defined elsewhere within the enterprise. Within an architecture project, the architect will normally need to ensure that the definitions of these business principles, goals, and strategic drivers are current, and to clarify any areas of ambiguity.

The issue of Architecture Governance is closely linked to that of Architecture Principles. The body responsible for governance will also normally be responsible for approving the Architecture Principles, and for resolving architecture issues. The issues involved in governance are explained in the TOGAF Standard — EA Capability and Governance.

2.5.5 Management Frameworks

The TOGAF ADM is a generic method, intended to be used by enterprises in a wide variety of industry types and geographies. It is also designed for use with a wide variety of other Enterprise Architecture frameworks, if required (although it can be used perfectly well in its own right, without adaptation).

The TOGAF framework has to co-exist with and enhance the operational capabilities of other management frameworks that are present within any organization either formally or informally. In addition to these frameworks, most organizations have a method for the development of solutions, most of which have an IT component. The significance of systems is that they bring together the various domains (also known as People, Processes, and Material/Technology) to deliver a business capability.

The main frameworks suggested to be co-ordinated with the TOGAF framework are:

• Business Capability Management that determines what business capabilities are required to deliver business value including the definition of return on investment and the requisite control/performance measures
• Project/Portfolio Management Methods that determine how a company manages its change initiatives
• Operations Management Methods that describe how a company runs its day-to-day operations, including IT
• Solution Development Methods that formalize the way that business systems are delivered in accordance with the structures developed in the IT architecture

As illustrated in Figure 2-2 , these frameworks are not discrete and there are significant overlaps between them and the Business Capability Management. The latter includes the delivery of performance measured business value.

The overall significance is that the Enterprise Architect applying the TOGAF framework cannot narrowly focus on the IT implementation, but must be aware of the impact that the architecture has on the entire enterprise.

The Preliminary Phase therefore involves doing any necessary work to adapt the ADM to define an organization-specific framework, using either the TOGAF deliverables or the deliverables of another framework. The issues involved in this are discussed in 1.3 Adapting the ADM .

2.5.6 Relating the Management Frameworks

Figure 2-3 illustrates a more detailed set of dependencies between the various frameworks and business planning activity that incorporates the enterprise's strategic plan and direction. The Enterprise Architecture can be used to provide a structure for all of the corporate initiatives, the Portfolio Management Framework can be used to deliver the components of the architecture, and the Operations Management Framework supports incorporation of these new components within the corporate infrastructure.

The business planners are present throughout the process and are in a position to support and enforce the architecture by retaining approval for resources at the various stages of planning and development.

The solution development methodology is used within the Portfolio Management Framework to plan, create, and deliver the architectural components specified in the project and portfolio charters. These deliverables include, but are not exclusively, IT; for example, a new building, a new set of skills, production equipment, hiring, marketing, and so on. Enterprise Architecture potentially provides the context for all enterprise activities.

The management frameworks are required to complement each other and work in close harmony for the good of the enterprise.

Business planning at the strategy level provides the initial direction to Enterprise Architecture. Updates at the annual planning level provide a finer level of ongoing guidance. Capability-based planning is one of many popular techniques for business planning.

Enterprise Architecture structures the business planning into an integrated framework that regards the enterprise as a system or system of systems. This integrated approach will validate the business plan and can provide valuable feedback to the corporate planners. In some organizations, the Enterprise Architects have been moved to or work very closely with the strategic direction groups. The TOGAF approach delivers a framework for Enterprise Architecture.

Project/portfolio management is the delivery framework that receives the structured, detailed direction that enables them to plan and build what is required, knowing that each assigned deliverable will be in context (i.e., the piece of the puzzle that they deliver will fit into the corporate puzzle that is the Enterprise Architecture). Often this framework is based upon the Project Management Institute or UK Office of Government Commerce (PRINCE2®) project management methodologies. Project architectures and detailed out-of-context design are often based upon systems design methodologies.

Guidance on how to use the TOGAF ADM along with a Project Management framework may be found in the TOGAF® Series Guide: Architecture Project Management.

Operations management receives the deliverables and then integrates and sustains them within the corporate infrastructure. Often the IT service management services are based upon the IT4IT Reference Architecture, ITIL®, and ISO/IEC 20000:2011.

2.5.7 Planning for Enterprise Architecture/Business Change Maturity Evaluation

Capability Maturity Models are useful ways of assessing the ability of an enterprise to exercise different capabilities.

Capability Maturity Models typically identify selected factors that are required to exercise a capability. An organization's ability to execute specific factors provides a measure of maturity and can be used to recommend a series of sequential steps to improve a capability. It is an assessment that gives executives an insight into pragmatically improving a capability.

A good Enterprise Architecture maturity model covers the characteristics necessary to develop and consume Enterprise Architecture. Organizations can determine their own factors and derive the appropriate maturity models, but it is recommended to take an existing model and customize it as required.

Several good models exist, including National Association of State CIOs (NASCIO), and the US Department of Commerce Architecture Capability Maturity Model. Other examples include the US Federal Enterprise Architecture Maturity Model. Even though the models are originally from government, they are equally applicable to industry.

---

---