1.1 Objective

This document provides a set of role, skill, and experience norms for staff undertaking Enterprise Architecture work.

1.2 Overview

Skills frameworks provide a view of the competency levels required for specific roles. They define:

• The roles within a work area
• The skills required by each role
• The depth of knowledge required to fulfill the role successfully

They are relatively common for defining the skills required for a consultancy and/or project management assignment, to deliver a specific project or work package. They are also widely used by recruitment and search agencies to match candidates and roles.

Their value derives from their ability to provide a means of rapidly identifying skill matches and gaps. Successfully applied, they can ensure that candidates are fit for the jobs assigned to them.

Their value in the context of Enterprise Architecture arises from the immaturity of the Enterprise Architecture discipline, and the problems that arise from this.

2.1 Definitional Rigor

“Enterprise Architecture” and “Enterprise Architect” are widely used but poorly defined terms in industry today. They are used to denote a variety of practices and skills applied in a wide variety of architecture domains. There is a need for better classification to enable more implicit understanding of what type of architecture/architect is being described.

This lack of uniformity leads to difficulties for organizations seeking to recruit or assign/promote staff to fill positions in the architecture field. Because of the different usage of terms, there is often misunderstanding and miscommunication between those seeking to recruit for, and those seeking to fill, the various roles of the architect.

2.2 Basis of an Enterprise Architecture Practice

Despite the lack of uniform terminology, architecture skills are in increasing demand, as the discipline of architecture gains increasing attention within industry.

Many enterprises have set up, or are considering setting up, an Enterprise Architecture Practice, One of the benefits is the development of the necessary skills and experience among in-house staff to undertake the various architecting tasks required by the enterprise.

An Enterprise Architecture Practice requires a formal program of development and certification, by which an enterprise formally recognizes the skills of its practicing architects, as demonstrated by their work. Such a program is essential in order to ensure the alignment of staff skills and experience with the architecture tasks that the enterprise wishes to be performed.

The role and skill definitions on which such a program needs to be based are also required, by both recruiting and supplying organizations, in cases where external personnel are to be engaged to perform architecture work (for example, as part of a consultancy engagement).

An Enterprise Architecture Practice is both difficult and costly to set up. It is normally built around a process of peer review, and involves the time and talent of the strategic technical leadership of an enterprise. Typically it involves establishment of a peer review board, and documentation of the process, and of the requirements for internal certification. Time is also required of candidates to prepare for peer review, by creating a portfolio of their work to demonstrate their skills, experiences, and contributions to the profession.

The TOGAF Architecture Skills Framework attempts to address this need by providing definitions of the architecting skills and proficiency levels required of personnel, internal or external, who are to perform the various architecting roles defined within the TOGAF framework.

3.1 Certification of Enterprise Architects

The main purpose behind an enterprise setting up an internal Enterprise Architect certification program is three-fold:

1. To define needed architectural competencies while aligning necessary staff skills and experience with the architecture tasks the enterprise wishes to be performed, whether these are to be performed internally to the enterprise or externally; for example, as part of a consultancy engagement.
2. To formally recognize the skill of its practicing architects, as part of the task of establishing and maintaining a professional architecting organization.
3. To provide a competency development path for persons working with Enterprise Architecture and to ensure a minimal competency level whereby the enterprise’s confidence in the architecture activities performed by those certified meets an acceptable level.

3.2 Specific Benefits

Specific benefits anticipated from use of the TOGAF Architecture Skills Framework include:

• Reduced time, cost, and risk in training, hiring, and managing architecture professionals, both internal and external:

—  Simplifies communication between recruiting organizations, consultancies, and employment agencies

—  Avoids wasting time interviewing staff who may have applied in all good faith, but still lack the skills and/or experience required by the employer

—  Avoids staff who are capable of filling architecture roles being overlooked, or not identifying themselves with advertised positions and hence not even applying

—  Provides a clear documented set of skills for internal development of architects

—  Allows employees to self-assess against a set of required skills to prepare training and career plans

—  Allows managers/supervisors to assess levels of talent and where investments in training should be made based on common skill gaps

—  Creates a stable base of future architects and allows determination of those close to being ready to enable application of limited mentoring resources

—  Provides a career path for aspiring architects improves employee retention

• Reduced time and cost to set up an Enterprise Architecture Practice:

—  Adversely impacts the time, cost, and quality of Enterprise Architecture and hence to business and operational IT systems

—  Many enterprises do not have an Enterprise Architecture Practice due to the complexity involved in setting one up, preferring instead to simply interview and recruit architecture staff on an ad hoc basis

—  By providing definitions of the architecting skills and proficiency levels required of personnel who are to perform the various architecting roles defined within the TOGAF Standard, the Architecture Skills Framework greatly reduces the time, cost, and risk of setting up a practice for the first time, and avoids "re-inventing wheels"

—  Enterprises that already have an Enterprise Architecture Practice are able to set enterprise-wide norms and find it easier to recruit staff, or engage consultants, from external sources when there exists an industry-accepted TOGAF Architecture Skills Framework

• Reduced time and cost to implement an Enterprise Architecture Practice helps reduce the time, cost, and risk of overall solution development:

—  Even enterprises that do not have an Enterprise Architecture Practice are able to hire suitable personnel with satisfactory skills

The associated costs of having an Enterprise Architecture Practice are less than the resultant time and cost penalties if the practice is absent:

—     Personnel costs are decreased because there is less need to hire new staff or to perform staff reassignments

—     More important is that good staff assignments impact time, cost, and quality of operational IT systems and the projects to deliver them in a positive way

4.1 Overview

This chapter describes the role of an Enterprise Architect, the fundamental skills required, and some possible disciplines in which an Enterprise Architect might specialize.

The TOGAF Standard provides a framework for developing Enterprise Architectures encompassing business activities and capabilities, information, and technology. It therefore requires both business and IT professionals to develop the Enterprise Architecture.

The TOGAF Architecture Skills Framework provides a view of the competency levels for specific roles within the Enterprise Architecture team. The Framework defines:

• The roles within an Enterprise Architecture work area
• The skills required by those roles
• The depth of knowledge required to fulfill each role successfully

The value is in providing a rapid means of identifying skills and gaps. Successfully applied, the Framework can be used as a measure for:

• Staff development
• Ensuring that the right person does the right job

4.2 TOGAF Roles

A typical architecture team undertaking the development of an Enterprise Architecture as described in the TOGAF Standard would comprise the following roles:

• Architecture Board Members
• Architecture Sponsor
• Architecture Manager
• Architects for:

—  Enterprise Architecture (which for the purpose of the tables below and in Chapter 5 can be considered as a superset of Business, Data, Application, and Technology Architecture)

—  Business Architecture

—  Data Architecture

—  Application Architecture

—  Technology Architecture

• Program and/or Project Managers
• IT Designer
• Solution Architect
• And many others …

Solution Architecture is the practice of defining and describing an architecture (all landscapes) system that is delivered in the context of a specific solution.

The roles and responsibilities of a Solution Architecture are to:

• Conceptualize technical solutions to complex problems and maximize benefit to the IT system investments
• Verify stability, interoperability, portability, security, or scalability of the system architecture
• Collaborate with stakeholders to gain organizational commitments for all process, systems, and application plans
• Communicate project information through presentations, technical reports, or white papers
• Evaluate the existing operating environment to determine effectiveness and suggest changes to meet organizational requirements along with identification of redundant/ineffective systems
• Evaluate and guide selection of technologies required to complete those plans

The tables below and in Chapter 5 show, for each of these roles, the skills required and the desirable level of proficiency in each skill.

Of all the roles listed above, the one that needs particularly detailed analysis and definition is of course the central role of Enterprise Architect. “Enterprise Architecture” and “Enterprise Architect” are terms that are very widely used but not consistently defined, denoting a variety of practices and skills applied in a variety of architecture domains (see also Chapter 6). There is often confusion between the role of an architect and that of a designer or builder. Many of the skills required by an Enterprise Architect are also required by the designer, who delivers the solutions. While their skills are complementary, those of the designer are primarily technology-focused and translate the architecture into deliverable components.

The final subsection below therefore explores in some detail the generic characteristics of the role of Enterprise Architect, and the key skill requirements, whatever the particular architecture domain (Enterprise Architecture, Business Architecture, Data Architecture, Application Architecture, Technology Architecture, etc.).

4.3 Categories of Skills

The TOGAF team skill set will need to include the following main categories of skills:

• Generic Skills: typically comprising leadership, teamworking, inter-personal skills, etc.
• Business Skills & Methods: typically comprising enterprise organization knowledge, business cases, business process, strategic planning, etc.
• Enterprise Architecture Skills: typically comprising modeling, building block design, application high-level design, role definition, architecture principle design, high-level migration planning, architectural building-block management,, systems integration, etc.
• Program or Project Management Skills: typically comprising managing business change, project management methods and tools, etc.
• IT General Knowledge Skills: typically comprising brokering applications, asset management, IT system migration planning, SLAs, etc.
• Technical IT Skills: typically comprising software engineering, security, compute and network infrastructure, data interchange, data management, etc.
• Legal Environment: typically comprising data protection laws, contract law, procurement law, fraud, etc.

The tables below and in Chapter 5 illustrate each of these categories of skills.

The tables below and in Chapter 5 show, for each of these skills, the roles to which they are relevant and the desirable level of proficiency in each skill.

4.4 Proficiency Levels

The TOGAF Architecture Skills Framework identifies four levels of knowledge or proficiency in any area:

The following tables show a notional alignment of maturity/skill level versus role. Certain pursuits may require different levels of sophistication for specific roles than those identified herein.

5.1 Generic Skills

5.2 Business Skills & Methods

5.3 Enterprise Architecture Skills

5.4 Program or Project Management Skills

5.5 IT General Knowledge Skills

5.6 Technical IT Skills

5.7 Legal Environment

Of all the roles listed above, the one that needs particularly detailed analysis and definition is, of course, the central role of Enterprise Architect. As explained above, “Enterprise Architecture” and “Enterprise Architect” are terms that are very widely used but very poorly defined in industry today, denoting a wide variety of practices and skills applied in a wide variety of architecture domains.

This chapter therefore explores in some detail the characteristics of the role of Enterprise Architect, and some key skill requirements, whatever the particular architecture domain (Enterprise Architecture, Business Architecture, Data Architecture, Application Architecture, Technology Architecture, etc.).

6.1 Role Description

Enterprise Architects are visionaries, coaches, team leaders, business-to-technical liaisons, computer scientists, and industry experts.

The following is effectively a job description for an Enterprise Architect:

“The architect has a responsibility for ensuring the completeness (fitness-for-purpose) of the architecture, in terms of adequately addressing all the pertinent concerns of its stakeholders; and the integrity of the architecture, in terms of connecting all the various views to each other, satisfactorily reconciling the conflicting concerns of different stakeholders, and showing the trade-offs made in so doing (as between security and performance, for example).

The choice of which particular architecture views to develop is one of the key decisions that the Enterprise Architect has to make. The choice has to be constrained by considerations of practicality, and by the principle of fitness-for-purpose (i.e., the architecture should be developed only to the point at which it is fit-for-purpose, and not reiterated ad infinitum as an academic exercise).”

The role of the Enterprise Architect is more like that of a city planner than that of a building architect, and the product of the Enterprise Architect is more aptly characterized as a planned community (as opposed to an unconstrained urban sprawl), rather than as a well-designed building or set of buildings.

An Enterprise Architect does not create the technical vision of the enterprise, but has professional relationships with executives of the enterprise to gather and articulate the technical vision, and to produce the strategic plan for realizing it. This plan is always tied to the business plans of the enterprise, and design decisions are traceable to the business plan.

The strategic plan of the Enterprise Architect is tied to the Architecture Governance process (see the TOGAF^® Standard – Enterprise Architecture Capability and Governance) for the enterprise, so design decisions are not circumvented for tactical convenience.

The Enterprise Architect produces documentation and rationale of high-level design decisions for Segment and Solution Architects, business development, application development, or product development teams to execute.

An architect is involved in the entire process; beginning with working with the customer to understand real needs, as opposed to wants, and then throughout the process to translate those needs into capabilities verified to meet the needs. Additionally, the architect may present different models to the customer that communicate how those needs may be met, and is therefore an essential participant in the consultative selling process.

However, the architect is not the builder, and must remain at a level of abstraction necessary to ensure that they do not get in the way of practical implementation.

The following excerpt from The Art of Systems Architecting (Rechtin & Maier, 2000) depicts this notion:

“It is the responsibility of the architect to know and concentrate on the critical few details and interfaces that really matter, and not to become overloaded with the rest.”

The architect’s focus is on understanding what it takes to satisfy the stakeholders, where qualitative worth is used more than quantitative measures. The architect uses more inductive skills than the deductive skills of the builder. The architect deals more with guidelines, rather than rules that builders use as a necessity.

It also must be clear that the role of an architect may be performed by an engineer. A goal of this document is to describe the role – what should be done, regardless of who is performing it.

Thus, the role of the architect can be summarized as to:

• Understand and interpret requirements

Probe for information, listen to information, influence people, facilitate consensus building, synthesize and translate ideas into actionable requirements, articulate those ideas to others, and identify use or purpose, constraints, risks, etc.

The architect participates in the discovery and documentation of the customer’s business scenarios that are driving the solution. The architect is responsible for requirements understanding and embodies that requirements understanding in the architecture specification.

• Create a useful model

Take the requirements and develop well-formulated models of the components of the solution, augmenting the models as necessary to fit all of the circumstances, and show multiple views through models to communicate the ideas effectively.

The architect is responsible for the overall architecture integrity and maintaining the vision of the offering from an architectural perspective. The architect also ensures leverage opportunities are identified, using building blocks, and is a liaison between the functional groups (for example, development and marketing) to ensure that the leverage opportunities are realized.

The architect provides and maintains these models as a framework for understanding the domain(s) of development work, guiding what should be done within the organization, or outside the organization. The architect must represent the organization view of the architecture by understanding all the necessary business components.

• Validate, refine, and expand the model

Verify assumptions, bring in subject matter experts, etc. in order to improve the model and to further define it, adding as necessary new ideas to make the result more flexible and more tightly linked to current and expected requirements.

The architect additionally should assess the value of solution-enhancing developments emanating from field work and incorporate these into the architecture models as appropriate.

• Manage the architecture

Continuously monitor the models and update them as necessary to show changes, additions, and alterations.

Represent architecture and issues during development and decision points of the program. The architect is an “agent of change”, representing that need for the implementation of the architecture. Through this development cycle, the architect continuously fosters the sharing of customer, architecture, and technical information between organizations.

6.2 Characterization in Terms of the Enterprise Continuum

Under certain circumstances, the complexity of a solution may require additional architects to support the architecture effort. The different categories of architects are described below, but as they are architects, they all perform the tasks described above. Any combination of Enterprise, Enterprise Solution, and Solution Architects may be utilized as a team. In such cases each member may have a specific focus, if not specific roles and responsibilities, within the phases of the development process. In cases where a team of architects is deemed necessary, a lead Enterprise Architect should be assigned to manage and lead the team members.

• The Enterprise Architect has the responsibility for architectural design and documentation at an architectural landscape and technical reference model level

The Enterprise Architect often leads a group of the Segment Architects and/or Solution Architects related to a given program. The focus of the Enterprise Architect is on enterprise-level business capabilities required.

• The Segment Architect has the responsibility for architectural design and documentation of specific business problems or organizations

A Segment Architect re-uses the output from all other architects, joining detailed technical solutions to the overall architectural landscape. The focus of the Segment Architect is on enterprise-level business solutions in a given domain, such as finance, human resources, sales, etc.

The Segment Architect’s skill set is similar to that of the Enterprise Architect, the only difference is that they do not have to understand the whole enterprise’s business and related IT. Typically, a Segment Architect needs an understanding of all architecture domains and all the skills related to them.

• The Solution Architect has the responsibility for architectural design and documentation at a system or subsystem level, such as management or security

A Solution Architect may shield the Enterprise/Segment Architect from the unnecessary details of the systems, products, and/or technologies. The focus of the Solution Architect is on system technology solutions; for example, a component of a solution such as enterprise data warehousing.

The Solution Architect is more IT centered than the Enterprise Architect but needs to understand the business environment where the solution will be delivered. The Solution Architect does not need to be an expert in business modeling or business process design. The focus of the required skills is more in the application, data, and technical domains.

Figure 1 illustrates the difference between Segment Architecture and Solution Architecture.

Figure 1: Segment and Solution Architectures

Figure 2 illustrates the different skills required of the Segment and Solution Architect.

Figure 2: Segment and Solution Architect Skills

For more information about Solution and Segment Architects and Architecture, see the TOGAF Standard.

6.3 Key Characteristics of an Enterprise Architect

6.3.1 Skills and Experience in Producing Designs

An Enterprise Architect must be proficient in the techniques that go into producing designs of complex systems, including requirements discovery and analysis, formulation of solution context, identification of solution alternatives and their assessment, technology selection, and design configuration.

6.3.2 Extensive Technical Breadth, with Technical Depth in One or a Few Disciplines

A lead Enterprise Architect should possess an extensive technical breadth through experience in the IT industry. This breadth should be in areas of application development and deployment, and in the areas of creation and maintenance of the infrastructure to support the complex application environment. Current IT environments are heterogeneous by nature, and the experienced Enterprise Architect will have skills across multiple platforms. Enterprise Architects will have, as a result of their careers, skills in at least one discipline that is considered to be at the level of a subject matter expert.

6.3.3 Method-Driven Approach to Execution

Enterprise Architects approach their job through the consistent use of recognized design methods such as the TOGAF Architecture Development Method (ADM). Enterprise Architects should have working knowledge of more than one design method and be comfortable deploying parts of methods appropriate to the situation in which they are working. This should be seen in the body of design work the Enterprise Architect has produced through repeated successful use of more than one design method. Proficiency in methodology use is in knowing what parts of methods to use in a given situation, and what methods not to use.

6.3.4 Full Project Scope Experience

While Enterprise Architects are responsible for design and hand-off of the project to implementors, it is vital that they have experience with all aspects of a project from design through development, testing, implementation, and production. This scope of experience will serve to keep Enterprise Architects grounded in the notion of fitness-for-purpose and the practical nature of system implementation. The impact of full project scope experience should lead the Enterprise Architect to make better design decisions, and better inform the trade-offs made in those decisions.

6.3.5 Leadership

Communication and team building are key to the successful role of the Enterprise Architect. The mix of good technical skill and the ability to lead are crucial to the job. The Enterprise Architect should be viewed as a leader in the enterprise by the IT organization, the stakeholders they serve, and management.

6.3.6 Personal and Professional Skills

The Enterprise Architect must have strong communications and relationship skills. A major task of the Enterprise Architect is to communicate complex technical information to all stakeholders of the project, including those who do not have a technical background. Strong negotiation and problem-solving skills are also required. The Enterprise Architect must work with the project management team to make decisions in a timely manner to keep projects on track.

6.3.7 Skills and Experience in One or More Industries

Industry skill and experience will make the task of gathering requirements and deciding priorities easier and more effective for the Enterprise Architect. Enterprise Architects must understand the business processes of the enterprise in which they work, and how those processes work with other peer enterprises in the industry. They should also be able to spot key trends and correct flawed processes, giving the IT organization the capability to lead the enterprise, not just respond to requests. The mission of the Enterprise Architect is strategic architectural leadership.

The TOGAF Architecture Skills Framework provides an assessment of the skills required to deliver a successful Enterprise Architecture.

It is hoped that the provision of this Architecture Skills Framework will help reduce the time, cost, and risk involved in training, recruiting, and managing IT architecture professionals, and at the same time enable and encourage more organizations to institute an Enterprise Architecture Practice, hopefully based on (or at least leveraging) the role and skill definitions provided.