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

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.

The Need for an IT Architecture Skills Framework

Definitional Rigor

"IT Architecture" and "IT Architect" are widely used but poorly defined terms in the IT industry today. They are used to denote a variety of practices and skills applied in a wide variety of IT domains. There is a need for better classification to enable more implicit understanding of what type of architect/architecture 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.

The 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 the IT industry.

Many enterprises have set up, or are considering setting up, an IT 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 IT architecture practice is a formal program of development and certification, by which an enterprise formally recognizes the skills of its practicing IT architects, as demonstrated by their work. Such a program is essential in order to ensure the alignment of staff skills and experience with the IT 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 IT 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 IT 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 who 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

Goals/Rationale

Enterprise Certification of IT Architects

The main purpose behind an enterprise setting up an internal IT architect certification program are twofold:

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

Specific Benefits

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

• Reduced time, cost, and risk in training, hiring, and managing IT 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 IT 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 IT architecture practice:
  • Many enterprises do not have an internal IT 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 from scratch, and avoids "re-inventing wheels".
  • Enterprises that already have an internal IT 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 IT architect practice helps reduce the time, cost, and risk of overall IT development:
  • Enterprises that do not have an internal IT 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 IT 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.

IT Architecture Role and Skill Categories

Overview

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

TOGAF Version 8 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

TOGAF Roles

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

• Architecture Board Members
• Architecture Sponsor
• IT Architecture Manager
• IT Architects for:
  • Enterprise Architecture
  • Business Architecture
  • Data Architecture
  • Applications 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 IT architect. As explained above, "IT Architecture" and "IT Architect" are terms that are very widely used but very poorly defined in the IT industry today, denoting a wide variety of practices and skills applied in a wide variety of IT domains. There is often confusion between the role of an IT architect and that of an IT designer or IT builder. Many of the skills required by an IT architect are also required by the IT designer, who delivers the solutions. While their skills are complimentary, those of the IT designer are primarily technology focussed and translate the architecture into deliverable components.

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

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

Proficiency Levels

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

IT Architecture Role and Skill Definitions

Generic Skills

Business Skills & Methods

Enterprise Architecture Skills

Program or Project Management Skills

IT General Knowledge Skills

Technical IT Skills

Legal Environment

Generic Role and Skills of the IT Architect

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

This section therefore explores in some detail the generic characteristics of the role of IT architect, and some key skill requirements, whatever the particular IT domain (Enterprise Architecture, Business Architecture, Data Architecture, Applications Architecture, Technology Architecture, etc.).

Generic Role

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

The following is effectively a job description for an IT 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 IT architect has to make. The choice has to be constrained by considerations of practicality, and by the principal 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 IT architect is more like that of a city planner than that of a building architect, and the product of the IT 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 IT 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 IT architect is tied to the architecture governance process (see Architecture Governance) for the enterprise, so design decisions are not circumvented for tactical convenience.

The IT 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 s/he does 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.

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 foundation, systems, solutions, and customer 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 Architect should be assigned to manage and lead the team members.

• The Foundation Architect has the responsibility for architectural design and documentation at a technical reference model level. The Foundation Architect often leads a group of the System and/or Industry Architects related to a given program. The focus of the Foundation Architect is on enterprise-level business functions required.
• The System Architect has the responsibility for architectural design and documentation at a system or subsystem level, such as management or security. A System Architect may shield the Foundation Architect from the unnecessary details of the systems, products, and/or technologies. The focus of the System Architect is on system technology solutions; for example, a component of a solution such as enterprise data warehousing.
• The Industry Architect has the responsibility for architectural design and documentation at an industry level. The focus of the Industry Architect is on industry problems and solutions; for example, Petrochemical solutions, Banking solutions, Retail solutions.
• The Organization Architect has the responsibility for architectural design and documentation of specific organizations. An Organization Architect re-uses the output from all other architects. The focus of the Organization Architect is on enterprise-level business solutions in a given domain, such as finance, human resources, sales, etc.

Key Characteristics of an IT Architect

Skills and Experience in Producing Designs

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

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

An IT 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 IT architect will have skills across multiple platforms, including distributed systems and traditional mainframe environments. IT 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.

Method-Driven Approach to Execution

The IT architect approaches his or her job through the consistent use of recognized design methods such as the TOGAF Architecture Development Method (ADM). The IT architect should have working knowledge of more than one design method and be comfortable deploying parts of methods appropriate to the situation in which s/he is working. This should be seen in the body of design work the IT 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.

Full Project Scope Experience

While the IT architect is responsible for design and hand-off of the project to implementors, it is vital that s/he have experience with all aspects of a project from design through development, testing, implementation, and production. This scope of experience will serve to keep IT 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 IT architect to make better design decisions, and better inform the trade-offs made in those decisions.

Leadership

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

Personal and Professional Skills

The IT architect must have strong communications and relationship skills. A major task of the IT 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 IT architect must work with the project management team to make decisions in a timely manner to keep projects on track.

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 IT architect. The IT architect must understand the business processes of the enterprise in which he works, and how those processes work with other peer enterprises in the industry. S/he 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 IT architect is strategic technical leadership.

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 at the top of the page, click the relevant hyperlink (Part I, Part II, etc.) to load the Contents List for that Part of the TOGAF document into the Secondary Index frame in the left margin.
  
  
• Then click in that Contents List to load a page into this main frame.
  
  

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 hardcopy book is also available from The Open Group Bookstore as document G063.