9 Organization Model for the EA Team

Keep in mind that this Guide discusses establishing and evolving an EA Capability. This Guide does not suggest that creation of such a team would guarantee a successful outcome from the EA Capability. This Guide does not explicitly discuss an organizational element that could be designated as an EA department.

The required EA Capability must be supported by the correct organization, roles, and responsibilities. Of particular importance is the definition of boundaries between different EA practitioners and creating the organizational model that realizes the governance framework.

Creating an EA Capability team requires the following questions to be answered:

This chapter is about considerations to create the team structure for the EA Capability. This should not be confused with Organization Model of the Enterprise (Section 4.2.3), which is all about capturing the existing structure of the enterprise as a whole. At this point, if an EA Capability organization does not exist at the enterprise, reset this thinking – it is now an organization of one – composed of the Leader. When initiated by an executive sponsor, it is a team of two. How to go about building the rest of the team? The rest of this chapter is about factors to consider while creating a new team:

9.1 Shared Roles and Alignment

Developing, implementing, and managing an EA practice requires multi-discipline engagement. To define the structure and capacity for the EA Capability, involvement of personnel executing business strategy development, project, program and portfolio management (both operations and IT), quality management (process and product), governance (financial, legal, others), and IT delivery functions should be defined. Rationale and engagement levels with other disciplines are discussed in Chapter 6 (Architecture Governance) and Chapter 10 (Process Model). It is more than likely that the enterprise already has individual people or teams that perform these functions embedded in other broader functions. To build cross-team alignment, it is necessary to identify the teams or individuals who perform strategy development and program management.

9.2 Alignment

Most likely, the sponsor of the EA Capability has already defined how the team interfaces with the rest of the enterprise. Figure 12 below shows some of the variants of organizational alignment of a team providing the EA Capability in the industry. They are used to convey an idea and do not account for preferences like customer segment, product lines, or country and geography an enterprise may have. It is likely that the enterprise is experimenting with EA and has chartered the Leader to work with external consultants and service providers. This Guide does not take into account where the professionals come from.

Table 5: Examples of Management Systems Integrating/Interoperating with the EA Capability

Examples of Management Systems with which the EA Capability must Integrate and Interoperate

Business Strategy and Planning

Solutions Delivery

Business Intelligence

Security

Business Process Management

Application Portfolio Management

Finance

Technology Planning and Management

Systems Planning, Management, Operations

…

Its context provides an important part of the requirements and constraints on an EA Capability. In the case of the EA Capability, its interactions will be with the other management systems that support or govern the work of enterprise transformation.

To keep the visualizations simple, teams like project management and quality are not called out explicitly. As they are also shared functions like EA, it is fair to assume they will also follow a model very similar to EA.

In a strategy-centric model, EA can be aligned with corporate strategy, overall operations, or finance. The team providing the EA Capability extends its services to the rest of the enterprise based on the charter (sustained growth, operational efficiency, cost and risk reduction).

The charter of the EA Capability will determine the coordination and reporting structure the shared teams will have. Business objectives and empowerment provided by the sponsor are sources that will help to identify the alignment model. Variants of the alignment model shown below are not intended to suggest that all activities within an EA Capability should exist within one functional unit.

In a function-centric model, it is possible that EA is part of each of the functional verticals and one of the teams consolidates all EA activities. Another variant is EA could be part of the dominant or key function of the enterprise. In this variant, it may be prudent to draw members of the team providing the EA Capability from each of the functional units having extended responsibility for a common goal, from an HR management perspective, and report to respective functional or regional business leaders.

Function-Centric EA

IT-Centric EA

Strategy-Centric EA

Figure 12: Possibilities for EA Team Alignment

In an IT-centric model, EA is normally aligned to the IT organization, irrespective of how it is named. The charter for the team may vary depending upon how IT is structured within the organization. When IT is aligned to the CFO, the charter for the EA team may be driving operational efficiency and cost control. When IT is aligned to delivery or marketing, the charter is more likely to focus on agility and efficiency. Understand the context, and draw members with process analysis and cost management expertise or deep functional knowledge of operations.

When there are multiple EA teams, there is one EA Capability and there should be one Leader. All teams should work under the guidance of this Leader and collaborate. The reporting and funding hierarchies of the teams can be separated from alignment and execution against EA Capability objectives.

9.3 Structure

The structure of the team providing the EA Capability depends on the activities to be performed against the charter. Figure 13 summarizes a high-level view of activities and suggests some of their relationships to each other. Skills required to build and use have different requirements with few overlaps.

The EA Capability must run efficiently, effectively, and in line with changing operational and financial practices. It is conceptually similar to operating any function in the organization. It consists of EA-specific activities and activities that are general to any business.

EA-specific activities are either foundational or purpose-specific. The nature of work done by the team providing the EA Capability invariably places them as a shared function. The team needs continuous input from impacted teams on relevance, efficiency, effectiveness, and growth – it is imperative to have common foundational elements of the EA Capability.

Figure 13: Decomposition of EA Capability Model

An interesting aspect of leading an EA Capability is the need to apply EA services to the EA Capability. This Guide is based upon the premise that a properly architected EA Capability out-performs an ad hoc organizational design. In fact, this Guide follows an approach applicable to architecture to support portfolio to define and describe the required EA Capability. The EA Capability will create and revise a unified EA strategy and accompanying EA plans, and will produce an integrated EA roadmap. This activity must grasp the current state and future direction of the business and its supporting systems, and have ongoing interactions with the people who are responsible for achieving the target state across several enterprise functions.

A certain amount of the EA Capability must be in place before architecture work can start; consequently, boot-strapping is necessary. For a budding EA Capability team, there will be an expectation to build a roadmap to develop the capability and to produce usable architecture. The Leader will have to pay attention and track these as separate efforts.

Well-formed EA Capability teams have specialists in each of the main domains like business, information, applications, technology, and security. Depending on organizational alignment, sponsorship, and funding, the team providing the EA Capability may employ specialists per suite of solution areas like enterprise resource planning, customer relationship management, sales force automation, core banking, and treasury. Other cross-disciplines to consider are strategic planners, financial and market analysts, line of business leaders, or subject matter experts, and service or support personnel. It is advisable to keep such functional specialists as part of an extended EA team. The core team is focused on strategies, processes, and advice.

Figure 14: Teams Executing the EA Capability

This Guide now addresses the matter of having an architecture board or a governance council. Chapter 6 (Architecture Governance) discussed the composition of the team and its functions. Regarding the purpose and approach to staffing the architecture board, apply the separation of duties principle. The architecture board is equivalent to the “board of directors” of the EA Capability’s business-in-a-business. Members of the governance team should have direct influence over the direction of the business or the outcome of the initiatives architected by the EA. This body sets and manages overall direction for the enterprise. It is not a successful pattern to embed rights for certain classes of architecture decisions in this body. For example, defining the constitution of an architecture building block, solution building block, or a trade-off decision around directory services or assembly line layouts is better decided at the extended EA team level.

The EA Capability, like any other business, must carry out a basic set of general actions. This includes things like finance and budgeting, team development, risk management, and performance management. All of these must be adapted to the specific EA Capability and enterprise. In most enterprises these functions are shared, and EA should benefit from tapping into these teams. Occasionally, to scale the reach of the EA functions, it may be necessary to franchise some of the activities to teams outside the team providing the EA Capability.

9.3.1 Roles and Responsibilities

Every enterprise has a predefined set of roles and responsibilities. If one already exists, use it, test waters, and refine it. While refining, start with defining roles and then think of titles. From a simple people portability and recruitment point of view, it is imperative that you keep the functional titles and roles in common with industry standard titles. It is best practice to separate functional titles from pay grades.

Consider context, charter, culture, clarity of expectations, collaboration, communication and co-ordination, separation of concerns, control, competence, and creative innovation while defining each of the roles and responsibilities.

There is sufficient literature in organization theory and design. Here are some quick pointers (see Referenced Documents):

It is likely that the enterprise may not have a team model specifically for EA or for any architecture role. In such a case, consider the catalog of models (organization, process, information flow, infrastructure topography) to be created for the enterprise. If no one has been formally building and maintaining an organization model, the team providing the EA Capability should assume the responsibility until a formal owner is identified. Lack of such ownership is an architectural gap and should be part of the work packages to address.

When forward-looking technology research is not conducted (or it is being conducted, but not operationalized), the team providing the EA Capability should assume ownership until it can be moved to an appropriate owner. These activities may include validating vendor-supplied solutions, component design to be deployed on board an automobile, or be as complex as joint development of a tamper-proof credit card and Point of Sale (POS) solution.

9.3.2 Skills Framework

Governments and private forums within government like the US Department of Labor Occupational Outlook Handbook, the Skills Framework for the Information Age (SFIA), and The Open Group Certified Architect (Open CA) Program Conformance Requirements (see Referenced Documents) have defined detailed expectations for various architect roles. Some of these frameworks also provide a career and certification progression from beginner level architect to industry leading roles. Use these models before inventing one for the enterprise. It will simplify the engagement with the HR team.

9.3.3 Performance Evaluation (of the EA Capability)

The absence of an approach to evaluate architects has been a common hindrance to growth for many in this profession. In most organizations, the existing HR framework is likely to have value measurement and communication approaches. When an evaluation criteria does exist, it is invariably a measure of models, documents, and visualizations produced (local to efficiency of building the EA Capability). These are inadequate to communicate value delivered by the architects.

Some of the major categories to consider for defining value metrics are financial, risk reduction, benefit realization, growth and innovation, proactive readiness, development of organizational capability, and ease of change management. To be specific, consider how the professionals:

9.4 Capacity

Architect skill growth invariably starts with domain-level specialization and branches into cross-domain expertise. Organizational structure, dynamics, or funding level may force the Leader to create capacity via federated or virtual teams. If the EA Capability is being resurrected, it would be difficult to discern qualified and semi-qualified architects embedded in various parts of the enterprise. Focusing on measures like adherence to objectives, EA process, and value creation approach have proven to surface the right talent to acquire both internally and externally.

Refer to the sample EA Capability models shown in Figure 22 and Figure 23. Develop a model to assess how many architects would be required to cover development of these EA Capabilities or apply parts of these EA Capabilities to achieve the business. Team members will be spending time to keep the architecture repository current or managing changes to the EA Capability and the enterprise. In addition to the skills framework, consider the talent mix to perform these activities while maintaining deep engagement with all stakeholders.

One of the most common mistakes in building capacity relates to the time required to coach and mentor. The architecture discipline is partly about delivery. Driving change in the thought process of leadership and delivery teams that everything is a trade-off, including that sub-optimization exists in the short term, consumes time. Such coaching invariably results in random disruptions inhibiting members of the EA Capability team to meet their schedule. Likewise, it takes time to mentor aspiring candidates. Mentors may be mostly productive, but mentee time should not be accounted as “available”. Estimate overhead time before committing to delivery schedule or capacity.

Members of the EA Capability team may possess a level of maturity and capability to deliver against the business objectives and timelines. Experience has shown that organizational maturity is needed to understand and execute on the roadmap, and, if this is not understood, it can result in failure and over committing the team. Like performance criteria, define capacity assessment criteria like time, specialization, and maturity. If there is no measurement, there is no way to identify the need to add more or adjust focus.

As mentioned in the previous chapter, it is advisable to have a set of analysts as resources who can manage and curate the EA repository. It is advisable to employ a graphic designer, on an as-needed basis. While budgeting for the total spend on the EA Capability team, consider such part-time resource needs.

9.4.1 Recruiting to Build Capacity

When the EA Capability is being re-booted or the team providing the EA Capability is federated, it is likely that existing pools of architects would be inherited. It may be baggage or a bonus. There is value to institutional knowledge and rapport – only when balanced against tenure, awareness, and institutional bias. Irrespective of the latitude given to the Leader to build the team, a good approach to recruiting members of the EA Capability team is to follow the knowledge, skill, and talent framework. Also, pay attention to the personal growth path desire of the individual and balance it against the financial accounting model of the team providing the EA Capability. As much as the architect is required to present all facets of a problem or topic, the architect is also required to take a stand and argue on the merits and metrics. Look beyond the daily activities; look for diversity of domains and transferrable skills across business domains and problem patterns.

EA is not all about definitions of trade-off criteria to reduce risk or cost and to improve sustainability over a period. Understanding the organization’s objectives, legal environment, financial model, and operating model clarifies that trade-off decisions normally cover more than one dimension. A retractable road barrier is a clear example of innovative design to avoid trading off security concerns against emergency and usability concerns. Enterprise Architects will have to look across the functional and departmental barriers of the enterprise, so that innovative alternatives or trade-off can be taken into account before presenting decision-ready options. It is recommended to have people of varying skills, but who have a common thread in thought process: how to set and follow trade-off analysis to deliver decision-ready recommendations. A deductive reasoning process is not the same as belief and bias-oriented black-and-white thinking. As times change, some of the concerns change as well. What used to be non-functional requirements – like visual appeal and performance – are becoming key functional differentiators (as of 2015-2016). A prerequisite for an individual to be an Enterprise Architect is the ability to keep current and be imaginative.

9.5 Scoping the Depth and Breadth of Business Impact with the EA Capability

The enterprise context, EA context, and purpose of the EA Capability drive the determination of scoping decisions. The EA Capability delivers optimal results when different aspects (like environment, strategy, internal and external interactions, automation, etc.) are handled the way they should be.

This section helps to answer the following questions:

Earlier this Guide discussed enterprise, segment, and capability-based approaches for separation and scoping. These are natural mechanisms, if already available in your enterprise, that could be leveraged.

In order to deliver value, any business should have three scoping statements: customer demography or segment being addressed, products (vertical integration) delivered, and geography being covered. Likewise, EA should also address business capabilities, architectural or business domains, and solution coverage. The Leader will have to create a matrix of these in a grid, either follow a row or a column to arrive at the right size for the team, and to articulate the value being delivered by the EA Capability. Unless the variant chosen is proving to be a deterrent to deliver value, it is prudent to stick to one approach.

9.5.1 Value Chains, Value Streams, and Capabilities

The major approaches are capability, process, and value stream-based segmentation of the business. A capability-based system focuses on what sets the enterprise apart from the competition. In a value-centric system, the focus is on how to deliver the products and services to the customers. It is possible for the enterprise to follow value-based or capability-based models in two different business units or the same business unit in different geographies. For example, customer center operations may be managed as a capability whereas sales may be handled as a process.

In some businesses, terms like front-office, middle-office, and back-office are commonly used to describe the way operations are managed. Front-office means customer-facing operations like branches, counters, or vending machines where customers appear and interact. Back-office implies capabilities like logistics, infrastructure, legal, and finance. Middle-office can indicate nearly everything else. Even though different terms are used to describe value stream and capabilities, use of front, middle, and back office is a common variation.

In the event the enterprise does not have a value chain, value stream map, or capability map, but prefers to anchor on one of them, a good place to start would be the American Productivity and Quality Center (APQC) capability map or value chain or value stream map.

There are businesses like telecom and technology sales where the scope for capability or value stream definition may be constrained by a country; in China, Vietnam, and Thailand local regulations and market behavior are so different that they demand special treatment. Likewise, nuances in the mining industry demand that each mine be scoped differently for operational purposes, but the entire business has to be handled as one unit for strategy purposes.

In the event of managing a Merger and Acquisition (M&A) or divestiture activity, the scope may be just that: land the transition from two entities to one. When performing business as part of an alliance or consortium, scoping should be handled carefully to treat each of the legal entities participating in the alliance and the alliance as a whole in the context of respective legal boundaries.

Some businesses prefer to handle segmentation based on their portfolio of efforts such as growth markets and emerging markets. Such marketing taxonomy indicates geographical boundaries and a set of processes or capabilities to achieve business goals. From the EA Capability standpoint, care must be taken to clarify the set of processes, capabilities, and geography that is within scope.

Identify the best suited analysis model for the enterprise – value chain, value stream, or capabilities. Validate whether the analysis model can be used to drive change and communicate the architecture. Align and define the EA team model to the appropriate analysis model and architecture delivery model.

9.5.2 Domains and Layers

This Guide discusses domains and layers for awareness and provides clarity on nomenclature. It is sufficient to know that domain knowledge constitutes criteria to staff the team.

Domains and layers are typical words in the dictionary of a technologist. The TOGAF framework suggests that the word “domain” should always be prefixed by a modifying noun to provide context; e.g., architecture domain, business domain, and security domain.

Domain can be defined in a different context as well. Industry-based business domain context for each enterprise is defined and a known context for the enterprise.

For the purpose of this Guide, the (architecture) domains are limited to business, data (and information), application, technology (infrastructure and integration), and security. This view is based on the meaning of the word domain as “a field of thought, action, influence”. This definition is very similar to terms defined in the TOGAF framework. See Figure 15 for details on the scope of each of these architectural sub-domains.

A security architecture is a structure of organizational, conceptual, logical, and physical components that interact in a coherent fashion to achieve and maintain a state of managed risk. It is an enabler of secure, safe, resilient, and reliable behavior and upholds privacy at risk areas throughout the whole enterprise.

Security architecture components always have a relationship with other elements in the architecture. Thus, although the security architecture might be viewed as one architecture, it can never be an isolated architecture. That would be meaningless. After all, security is not the problem of security architects; it is a concern for the enterprise.

In the context of security architecture, risk can be operational or business-related. Security architecture contains a balanced view on risk: negative consequences are kept to an acceptable level, and positive opportunities are exploited to their maximum. The business-driven approach is key for the security architecture: business drivers offer the context for risk assessments. They define whether compliance with any control framework is necessary, and they justify the need for security measures.

In Figure 15, the visualization does not convey that one domain is a subset of the other. The idea is that integration and security domains touch business, data, application, and technology domains. Security architecture is a cross-cutting concern, pervasive through the whole EA.

As a cross-cutting concern, the security architecture impacts and informs business, application, data, and technology architectures. The security architecture may often be organized outside of the architecture scope, yet parts of it need to be developed in an integrated fashion with the architecture. See Figure 16 for a view of how the layers interact with each other, and a cross-cutting concern.

Figure 15: Commonly Accepted Domains

When dealing with function or strategy-specific EA efforts, it is preferable to consider domains first and, as needed, consider introducing the concept of (architecture) layers. When EA is IT-centric, use of layers to define standard guides may be useful for the enterprise. Layers are normally based on man-to-machine or machine-to-machine interactions. Commonly used layers are presentations or user experience (or client tier), service (end-points or front tier), business rule and logic (middle tier), integration and workflow (middle tier), and storage (data tier). As transitions happen to cloud, mobility, and the Internet of Things (IoT), the architectural layers in the IT landscape will change significantly.

The Open Group SOA Reference Architecture (see Referenced Documents) provides a logical solution view, which talks about consumers and providers who are brought together via consumer interfaces, business processes, services, service components, and operational systems. Consumers’ loyalty, usability, and consumption are governed and assured by the quality of the service, enabling information exchange between participating members. The OSGi Alliance model, the OSI model based on the ISO/IEC 7498-1:1994 standard, or Functions, Flows (Processes), Layers, and Views (FFLV), are other concepts on technology or architecture layers that can be leveraged.

Figure 16: Security as a Cross-Cutting Concern through the Architecture

When communicating domain architectures, terms like conceptual, logical, and physical layers are used. Use of the term “layer” in that context is about level of abstraction in the detail being communicated in models and documentation about the architecture. Conceptual, logical, and physical explicitly indicate the intent of the level of detail that can be found in the architecture.

When defining the scope for architecture work, the terms enterprise, segment, and capability or project are used. Enterprise, segment, and capability classification is used to convey how the architecture project is scoped. Purpose-based classification is aimed at addressing the outcome of the architecture work. For a capability level, all four purposes apply. Always remember the distinction between scoping intent and outcome intent. When directing the EA team and when communicating with stakeholders, be specific and clear about the intent and purpose of the architecture work.

9.5.3 Depth and Breadth

Clarity in business objectives provides hints for what to focus on first: the entire breadth of the enterprise or specific areas. Building on the discussion about scoping the EA effort in Section 4.2.4, consideration to grow the enterprise via M&A or through organic expansion should be included. Objectives like due diligence for M&A would start with understanding all capabilities (breadth) and then go into each unit or capability stack (depth). Objectives like cost and incident reduction would start with a specific capability (depth) and then replicate the process across the business (breadth).

Sometimes, the size of the enterprise or the “span of control” of the sponsor may call for partitioning. The constraint is either capacity of the team providing the EA Capability or value proposition perceived by the sponsors. Either way, the only trade-off that can be made is time to cover the entire enterprise (or delivering value) against the ability to keep the architecture documentation current. When dealing with an enterprise structure where the EA lead is a coordinator across architects from various business units, a need for unification, standardization, or replication of standards, reference models, and reference architecture arises. Partitioning enables scale to cover the breadth. The Leader should drive clarity on principles to employ, approach to classification, and avoidance of duplicate architectural work in the unification or diversification model. In these scenarios, there is a need to consider carving out a separate integration architecture effort.

The approach to scope the EA work is also called “partitioning” and each scoped slice is called an architecture partition. Architectures that are created to address a subset of issues within an enterprise require a consistent frame of reference so that they can be considered as a group as well as point deliverables. The dimensions that are used to define the scope boundary of a single architecture (e.g., level of detail, architecture domain) are typically the same dimensions used to integrate the subset of architectures.

9.5.4 Impact of Time Dimension on Scope

The capability map or value stream provides a pivot to build the end-to-end view of the enterprise. The level of detail to which they are explored depends on the scope. The strategy and operations of the business change with time. The impact could be in the partition that a team of architects is currently engaged, part of a backlog item, or part of those pending elaboration in the future. It is also possible that concurrent elaboration activities can occur, based on the EA team capacity. Pragmatically, the EA Capability must isolate the impact of changes across concurrent architecture efforts. A side-effect of such isolations or concurrent development is architecture in silos.

Having defined the boundary of the EA Landscape to be fleshed out, the approach to fleshing out the details contained within the EA Landscape should be approached differently. Defining the boundary sets the context for interoperability concerns. Details of the landscape set the context for purpose and outcome. One of the common failure patterns is to scope the architecture project efforts to flesh out the details of the EA Landscape without consideration of the impact to neighboring landscapes. The key principle that should never be compromised or traded-off is that EA is about a system of systems. Cross-system dependency and interaction management should take precedence over the needs of the project or success of the “scoped effort”. Care must be taken to define the criteria for optimizing or sub-optimizing a particular area for the overall benefit of the enterprise.

Having executed on this chapter, use this checklist to assess progress made in developing the EA Capability.

return to top of page

Copyright © 2022 The Open Group, All Rights Reserved.
TOGAF® is a registered trademark of The Open Group
<<< Previous Home Next >>>