This chapter provides a set of role, skill, and experience norms for staff undertaking enterprise architecture work.

52.1 Introduction

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 fulfil 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.

52.2 Need for an Enterprise Architecture Skills Framework

52.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 usages 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.

52.2.2 Basis of an Internal 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, as a means of fostering 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 is 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.

Because of the complexity, time, and cost involved, many enterprises do not have an internal enterprise architect certification program, preferring instead to simply interview and recruit architecture staff on an ad hoc basis. There are serious risks associated with this approach:

• Communication between recruiting organizations, consultancies, and employment agencies is very difficult.
• Time is wasted interviewing staff who may have applied in all good faith, but still lack the skills and/or experience required by the employer.
• Staff that are capable of filling architecture roles may be overlooked, or may not identify themselves with advertised positions and hence not even apply.
• There is increased risk of unsuitable personnel being employed or engaged, through no-one's fault, and despite everyone involved acting in good faith. This in turn can:
  • Increase personnel costs, through the need to rehire or reassign staff
  • Adversely impact the time, cost, and quality of operational IT systems, and the projects that deliver them

52.3 Goals/Rationale

52.3.1 Certification of Enterprise Architects

The main purpose behind an enterprise setting up an internal enterprise architect certification program is two-fold:

1. To formally recognize the skill of its practicing architects, as part of the task of establishing and maintaining a professional architecting organization
2. To ensure the alignment of necessary staff skills and experience with the architecture tasks that 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

52.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
• Reduced time and cost to set up an internal architecture practice:
  • Many enterprises do not have an internal 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 TOGAF, 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 internal architecture practice are able to set enterprise-wide norms, but still experience difficulties as outlined above in recruiting staff, or engaging consultants, from external sources, due to the lack of uniformity between different enterprises. By aligning its existing skills framework with the industry-accepted definitions provided by The Open Group, an enterprise can greatly simplify these problems.
• Reduced time and cost to implement an architecture practice helps reduce the time, cost, and risk of overall solution development:
  • Enterprises that do not have an internal architecture practice run the risk of unsuitable personnel being employed or engaged, through no-one's fault, and despite everyone involved acting in good faith. The resultant time and cost penalties far outweigh the time and cost of having an internal architecture practice:
    • Personnel costs are increased, through the occasional need to rehire or reassign staff.
    • Even more important is the adverse impact on the time, cost, and quality of operational IT systems, and the projects to deliver them, resulting from poor staff assignments.

52.4 Enterprise Architecture Role and Skill Categories

52.4.1 Overview

This section describes the role of an enterprise architect, the fundamental skills required, and some possible disciplines in which an enterprise architect might specialize.

TOGAF delivers an enterprise architecture, and therefore requires both business and IT-trained 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 fulfil 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

52.4.2 TOGAF Roles

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

• Architecture Board Members
• Architecture Sponsor
• Architecture Manager
• Architects for:
  • Enterprise Architecture (which for the purpose of the tables shown below 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
• And many others ...

The tables that follow 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. 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. 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.).

52.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 business cases, business process, strategic planning, etc.
• Enterprise Architecture Skills: - typically comprising modeling, building block design, applications and role design, 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, migration planning, SLAs, etc.
• Technical IT Skills: - typically comprising software engineering, security, data interchange, data management, etc.
• Legal Environment: - typically comprising data protection laws, contract law, procurement law, fraud, etc.

The tables that follow illustrate each of these categories of skills.

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

52.4.4 Proficiency Levels

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

52.5 Enterprise Architecture Role and Skill Definitions

52.5.1 Generic Skills

52.5.2 Business Skills & Methods

52.5.3 Enterprise Architecture Skills

52.5.4 Program or Project Management Skills

52.5.5 IT General Knowledge Skills

52.5.6 Technical IT Skills

52.5.7 Legal Environment

52.6 Generic Role and Skills of the Enterprise Architect

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 section therefore explores in some detail the generic 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.).

52.6.1 Generic Role

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 50. Architecture Governance) for the enterprise, so design decisions are not circumvented for tactical convenience.

The enterprise architect produces documentation of design decisions for application development teams or product implementation 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 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 client, 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. 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. 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 (especially 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.

52.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 a 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 functions 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 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.

52.6.3 Key Characteristics of an Enterprise Architect

52.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.

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

An 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, including distributed systems and traditional mainframe environments. 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.

52.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 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.

52.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.

52.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 clients they serve, and management.

52.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.

52.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 technical leadership.

52.7 Conclusions

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 internal IT architecture practice, hopefully based on (or at least leveraging) the role and skill definitions provided.
return to top of page

The TOGAF document set is designed for use with frames. To navigate around the document:

• In the main Contents frame in the left margin of the page, click the relevant hyperlink to load the Contents List for that Part of the TOGAF document or go direct to a chapter within the document.
  
• Within a chapter you can select Previous and Next at the top and bottom of the page to move to the previous or next chapter, or select Home to return to the welcome page.
  

Downloads of the TOGAF documentation, are available under license from the TOGAF information web site. The license is free to any organization wishing to use TOGAF entirely for internal purposes (for example, to develop an information system architecture for use within that organization). A book is also available (in hardcopy and pdf) from The Open Group Bookstore as document G091.