Chapter 7. The Agile Organization Structure

An enterprise organization structure defines the relationships among people, along with their respective responsibilities and authority, as the basis of their collective efforts to achieve enterprise objectives. It also defines the chains of command through which enterprise management exerts leadership, accountability, and control. An agile enterprise changes these relationships by breaking down departmental silos into sharable service units and driving performance based on an SOA. The participation and relationships of people continue to be important in the agile enterprise, but the focus has shifted from performing production tasks to managing exceptions and resolving needs to address business challenges and opportunities.

Viewed from the bottom up, SOA is an approach to consolidation of duplicated capabilities to achieve economies of scale or control. However, when we view SOA as a fundamental approach to design of the organization, it yields a different vision. The enterprise becomes a network of services, contributing to value chains that achieve enterprise objectives. Essentially, service units are enterprise capabilities that can be engaged in a variety of enterprise pursuits. This is a sort of “hyper-matrix” structure because the cross-functional drivers are not restricted to a single dimension, such as products, customers, or markets. Instead, any new “matrix” can be established through the implementation of a value chain that engages the needed services to achieve particular business values.

In addition, people in the organization may have multiple roles and functional relationships, as depicted in Figure 7.1. This diagram depicts a hypothetical service unit and various relationships of personnel in that service unit. They are all part of a traditional management hierarchy, but they will participate in various other collaborative activities to implement changes or resolve issues that go beyond the interests of their individual service unit.

Figure 7.1. Organizational Relationships.

Some of these collaborative activities are with representatives of service units that are users of or providers to the subject service unit—to resolve service problems or negotiate changes in a service interface or level of service specifications. Some collaborations, such as the Information Technology Liaison, are to obtain support services from other service units. Still other collaborations involve participation in executive staff initiatives to design enterprise capabilities or implement changes. A number of these relationships are discussed further in Chapter 9 on governance. The diagram does not express the organizational aspects of role assignments for access authorization or management chains for approvals associated with the collaborative activities.

In the following sections we begin by examining design principles for an agile organization. Then we discuss several high-level categories of services that suggest primary departments of the organization structure. Next, we discuss design factors for grouping service units into an organization hierarchy. Finally, we consider a general approach to transforming an existing organization to achieve the agility and performance potential of a SOA.

Design Principles

Several design principles are important to the design of an agile organization structure.

Centralization for Enterprise Optimization

A major design goal is enterprise optimization: economies of scale and leveraged capabilities. This requires centralized management to address the following requirements:

• Definition of shared services must overcome resistance of organizations that experience loss of local control.
• Changes to a service interface (specification of interactions with a service) require consideration of the impact on related services and the potential replacement by alternative services.
• Investments in development and improvement of capabilities require setting enterprise priorities and balancing enterprise objectives
• Agility requires the ability to retrain and redeploy personnel for shifts in workload and transformations to address new business capabilities.
• Technical standards must be enforced, including product, production, and information technology standards, to support both economies of scale and enterprise flexibility.
• Purchase of equipment and facilities must be considered with respect to optimal utilization of assets and shared support services.

These considerations are explored further in Chapter 9 on governance.

Management Hierarchy

The management hierarchy of an agile enterprise is, in many ways, similar to the management hierarchy of traditional organizations. However, in a service-oriented enterprise, every manager is a provider of services. He or she is responsible to the service users for the cost, quality, and timeliness of the services provided (i.e., what is done) and to the management chain for the effective management of resources in compliance with government regulations and requirements for enterprise optimization (i.e., how it is done).

Managers higher in the management hierarchy have responsibility for an aggregation of services that generally have some similarities or common objectives, as discussed later. These service groups may include specialists and support services for services units in their area of responsibility. For example, a manufacturing manager may also have materials management, machine repair, and product repair service units to support the value chain operations for production.

The management chain has direct control of the way services are performed but must negotiate service requirements to optimize utilization of resources while meeting current and future needs of service users. The manager must pursue continuous improvement and adapt to changing business challenges and opportunities, to maintain at least an industry best-practice level of performance, if not a competitive advantage for the enterprise. In a sense, each manager is responsible for a subordinate enterprise that must meet the needs of its customers and achieve stockholder objectives.

Service Units as Building Blocks

Fundamental to the agile enterprise is the identification of service units that provide distinct business capabilities. These capabilities, for the most part, should survive changes in the business to deliver new products or pursue new markets. A service unit should be able to apply its capability in a number of business contexts as requests are received from different users of its services. As stable components of the enterprise, they are the building blocks of current and future business endeavors.

Note that a service unit is an organizational unit that applies a capability to deliver a result. The manager of a service unit has direct responsibility for resources except to the extent that management of some operations is delegated to other service units. The manager retains responsibility to ensure that either those operations that are delegated meet requirements or that alternative providers are considered. An organizational unit that is formed to manage other managers is not a service unit at all but rather an organization formed to improve management of resources and pursuit of enterprise objectives among the service units under that management.

Service Unit Autonomy

A service unit manager should have autonomy to improve the cost, quality, and timeliness of the service within the constraints established by enterprise-defined specifications for services, enterprise policies, and budget. As a stable, enterprise-building block, a service unit should have clear, long-term objectives and an expectation of adequate and stable staffing. The service unit manager and the personnel of the service unit should be the experts for the particular service, and they should be empowered to pursue improvements so that the enterprise realizes the benefit of their knowledge and their support for the implementation of change. The service unit manager should be able to plan and pursue process improvement, technology changes, and innovation within reasonable budgetary constraints. Where more substantial investment or broader-scope changes are needed, they should be proposed to higher levels in the management chain. Conversely, new business requirements may be defined at a higher management level, and requirements for adaptation may be delegated to individual service units for implementation.

Accountability

An agile enterprise has new mechanisms of accountability. Service units are accountable to their service users and to enterprise leadership for meeting service cost, quality, and timeliness requirements. This results from well-defined service specifications, performance reporting, visible contributions to value chains, and the responsibility of every service unit for its performance.

Though a service unit is directly accountable to service users for the result of a request, it is indirectly accountable to additional service units up the chain of requests along with the original requester. This accountability can be important in decision making regarding delivery of a service. For example, a customer order is received by an order-processing service that directs a request to an order fulfillment service, which directs a request to a shipping service. The shipping service requires a decision regarding transportation mode, which should be resolved by the original customer. This resolution might be accomplished by direct contact with the customer based on customer order information, but it should be accomplished by referring the decision back up the request chain so that appropriate controls and possible side effects (for example, a change in shipping charges) can be applied to the customer's specification. The latter approach is more adaptable since it does not cause the shipping service to make assumptions about the order, the options available to the customer, or proper identification of the decision maker.

In addition, from an enterprise perspective, every service unit contributes directly or indirectly to the enterprise value chain. The impact of each service on the success of the enterprise should be periodically evaluated from this perspective. This should be an important factor in the performance evaluation and incentives for the management of each service unit. The performance of some service units should be evaluated against similar activities in other enterprises and potential performance of equivalent outsourced services.

Collaborative Relationships

In general, service units should be expected to have consumer-provider relationships with services that are in separate management chains so that where there are issues involving these relationships, most should be resolved without appeal to a common manager—both because of the delay in resolution and the fact that managers at a high level probably lack the necessary expertise. Consequently, the issues must be resolved through collaboration. An agile enterprise relies heavily on collaboration to resolve problems and adapt to new business requirements.

These collaborations may vary in duration and intensity. Where the duration is longer or the level of participation is more intense, particularly where participation involves an employee on a full-time basis, the relationship should be formal and visible so that other members of related organizations know who has responsibility. Where significant resources are required, as with a full-time employee, participation should be viewed as a service to a responsible organization, and the cost of participation should be billed to that organization, assuming it is not the employee's home service unit that is the primary beneficiary of the initiative.

Collaborative relationships, particularly those of greater duration and intensity, often create alternative chains of command for review and approval. For example, persons who incur expenses as members of a project team probably need to have their expenses reviewed and approved by a project leader and possibly the manager responsible for the project. These relationships then provide the basis for business processes to engage individuals for review and approval.

Development and support of IT applications typically involve a variety of collaborative relationships. In general, these involve assignment of IT personnel as service providers and liaison persons to other organizations that should be billed to the organization requesting the participation and support as an investment in improvement.

Service Unit Types

From an enterprise perspective, services may be classified into several types based on their participation in value chains:

• Line-of-business service units
• Value chain service units
• Support service units
• Product development service units
• Master data service units
• Work management service units
• Transformation service units
• Portal service units
• Executive staff service units

These service unit types affect the cost and performance of value chains in different ways. In general, the differences in focus and planning horizons of these service types suggest that they should be in separate branches of the enterprise management hierarchy. However, though this is a significant factor at a high level, it is one of many considerations in the design of the organization; additional considerations are discussed later. In the following subsections we discuss the distinguishing characteristics of each of these service unit types.

Line-of-business Service Units

A line of business is a collection of similar products that are managed together for production synergy, economies of scale, or focus on a market segment. A line-of-business service unit is responsible for management of the full life cycle of the associated products, from concept through obsolescence; each product life cycle can be modeled and evaluated as a product value chain and managed as a product life-cycle project. The life cycle of a product is initiated by a management decision to develop a new product. For example, a manufacturing line-of-business service unit uses product development services to develop its products, uses operations engineering service units to develop the production capability, uses marketing and sales service units to promote and sell its products, and monitors production service units to ensure that the products are competitively produced and delivered. The line-of-business service unit may be viewed as a special case of the work management service unit, discussed later.

Line-of-business service units must respond to the marketplace to refine products or develop new ones. They engage various services from across the enterprise to support the product life cycle. They are concerned with the life-cycle value of the product to the enterprise—the return on investment.

Production Value Chain Service Units

A production value chain defines the contributions to units of production to achieve end customer value. Production value chain service units are those directly involved in adding value to a unit of production. This has been described as a line organization or an organization providing direct labor. These services are distinct because they directly affect the time to deliver the product or service as well as the cost and quality of the product or service. Each participating service unit provides specialized capabilities required to produce the product. These service units are the focus of initial SOA analysis because they are usually the primary sources of enterprise costs and because they directly affect the enterprise's ability to optimize and adapt to new business opportunities.

The goals and performance measures of a production value chain service unit must be aligned with its contributions to the value chain. The performance of value chain services rolls up, through the network of service usages, to the production value chain, independent of the organization hierarchy under which they are managed. Consequently, the managers of these service units necessarily focus on their contribution to value chains, and particularly contributions to cost, quality, and response time.

Production value chain service units are a primary target for automation and process improvement because that is where much of the cost of running the enterprise is incurred, they have direct impact on customer value, and the operations are typically highly repetitive.

Support Service Units

Support service units come in a variety of forms. They do not engage in activities that have a direct impact on a product value chain but instead provide ancillary services that ensure the effective development, availability, and management of the capabilities provided by the service units they support.

At the enterprise level, there are support service units that consolidate management functions from across the enterprise and enforce management controls. These services are generally organized into functional groups or departments. They include finance and accounting, human resources, purchasing, and information systems services. These enterprise support roles are discussed in greater detail in Chapter 9.

At an operational level, there are support service units that may be specific to particular segments of the business such as machinery maintenance, inventory management, quality control, and facilities management, but there are also operational-level aspects of the enterprise services, such as finance, human resources, purchasing, and information systems.

Support services essentially provide separation of control, economies of scale, or specialized capabilities that are more effective if managed separately.

Support services may interact with employees at all levels, depending on the nature of the service. In many cases, service unit managers are their customers. Managers or employees, depending on their roles, may request services and may be called on to participate in support services, i.e., respond to requests for inputs or approvals. The manager-customers may have different service expectations at different management levels.

Though these services do not directly affect the value produced by the user service unit, they are, nevertheless, part of the cost of adding value and can indirectly affect the performance of their internal customers. The cost of these services, like other services, must be recovered through a chargeback mechanism.

Product Development Service Units

Product development includes any activities that establish the capability to deliver a new or improved product (or service). Product development service units contribute to an internal value chain that provides value by developing a new product for a line of business. The product development value chain is a component of the broader product value chain that comprehends the entire product life cycle. A new product design changes the enterprise capability to deliver a new product. The cost defined by this value chain is associated with a particular product and is an investment that should be recovered through sales of the product.

Product development services define the product specifications and production requirements—requirements for adaptation of the enterprise. They effectively define what the production value chain services deliver. As such, their planning horizon is relatively long and their success is measured by the timely availability, market acceptance, and profitability of the new product.

Product development includes product research and may include development of special production tools, methods, specifications, and processes to produce a new product.

The eTOM framework was introduced in Chapter 2. The Strategy, Infrastructure, and Product segment is illustrated in Figure 7.2. In this context, product life-cycle management is shown as one of the vertical functional capabilities. It changes the enterprise capabilities to support production of a new product. The development of new products, as well as the adoption of new technologies and methods, is driven by the broader Strategy and Commit segment. We talk more about strategic planning and the development of enterprise capabilities in Chapter 9 on governance.

Figure 7.2. The eTOM Strategy, Infrastructure, and Product Segment.

Master Data Service Units

Various service units throughout the enterprise have responsibility for some segment of enterprise master data; the collective master data records are the current truth about the state of the enterprise. These service units are responsible for the integrity and confidentiality of their segments of the master data. They control updates and access to it, and they must ensure that it is available as needed to support other service unit operations.

A service unit need not be dedicated to master data management. Often the service unit that manages the most changes to the master data will include master data management responsibility. Nevertheless, the master data resource and effective management of it are key capabilities.

Work Management Service Units

We discussed work management service units in Chapter 2. The purpose of a work management service unit is to achieve a business objective involving several service units that cannot achieve an optimal result on their own. Most typical is a need to share resources to achieve economies of scale across the multiple service units.

In general, the optimization conflicts with the optimum that would be achieved by each of the service units acting on their own. So, manufacturing production scheduling is a work management service unit responsibility to optimize efficiency while minimizing the impact on delay of individual orders. Examples of the objectives to be pursued by work management service units were discussed in Chapter 2. Because the work management may adversely affect some of the performance of individual service units, the work management service unit generally reports to a manager who also has responsibility for the participating service units, so optimization is pursued from that manager's perspective.

Customer order management may be viewed as an enterprise-level work management service unit that is intended to optimize performance of business operations to serve the customer.

Transformation Service Units

Transformation services are not focused on particular products but instead on changing the way the enterprise does business. They develop and implement changes to the capabilities and potentially the design of the enterprise. These service units are separate from the other service types because the other services and their interactions become the work product of the transformation services. They need to bring an enterprise perspective and typically operate across organizational boundaries, sometimes making trade-offs and resolving role disputes between services and their users.

The scope and impact of transformation can vary widely from process improvement to large-scale reorganization. However, these services probably are not applicable to changes for a new product if the product impact is limited to variations in specifications, components, and configurations. They are applicable if the new product requires a new value chain, significant changes to an existing value chain, or major investment in service unit capabilities.

Enterprise transformations that involve multiple services and substantial enterprise investment or optimization must be managed by the Enterprise Transformation service group. The Enterprise Transformation service group is effectively both a transformation service and an executive staff service (discussed in a moment). This service is also discussed in greater detail in Chapter 9 on governance.

Large-scale business transformation occurs when there is a need for fundamental change in the enterprise capabilities and organization. These changes are driven by executive management as a result of strategic planning.

Service unit managers have primary responsibility for process improvement. This responsibility is generally limited by the scope of their service unit. Beyond the service unit scope, analyses must identify changes that optimize performance from an enterprise perspective, and proposed changes must be subject to enterprise-level review and approval.

The IT application development service units are transformation service units. Their responsibility is to ensure effective utilization of the technology and optimization of information systems and communications services. The application development services are utilized by individual service units to improve their capabilities and adapt applications to new business needs, and they are used by the enterprise transformation service to apply information technology in support of enterprise transformations.

In the eTOM framework, shown in Figure 7.2, some transformation services are represented by the Infrastructure Life-cycle Management capabilities. This framework does not explicitly address fundamental transformations to the design of the enterprise. It is focused more on the replacement and upgrade of telecommunication facilities. As with product development, the Infrastructure Life-cycle Management segment is driven by the Strategy and Commit segment.

Portal Service Units

A portal service unit provides services to a community of stakeholders, typically employees, customers, suppliers, or stockholders. These services may include call centers along with Web pages. The portal service unit provides a single point of contact from the stakeholder's perspective, directing requests to appropriate internal service units and tracking resolution of problems. The service unit tailors the portal to the particular needs of the stakeholder community.

Executive Staff Service Units

Executive management and the board of directors are served by executive staff service units that achieve coordination, control, optimization, and economies of scale at an enterprise level. These service units may respond to a variety of requests from executive managers and may have a number of defined services to serve the rest of the enterprise. For example, an executive staff process would review and authorize deviation from standards or review and approve changes to service interfaces. Strategic planning is an executive staff service.

Executive staff services must report to the CEO or a person reporting directly to the CEO to ensure that they function with an enterprisewide perspective. The executive staff services provide the mechanisms for governance and transformation of the enterprise. These services are discussed in Chapter 9.

Hierarchy Design Factors

Design of the organization hierarchy is a complex ongoing task involving many factors.

Current-day organization hierarchies often reflect groupings of people engaged in functionally related activities. However, in some cases the clustering is based on business operations required decades ago, the remnants of mergers and acquisitions, or the independent evolution of various product lines.

In an agile enterprise, all management hierarchies are responsible for managing services. The leaves of the hierarchy are where the work of services is actually done. The hierarchy, for the most part, brings together service units that have similar capabilities and objectives. The primary objective of the management hierarchy is to optimize the operation of the service units and adapt the service units to changing business requirements.

A blank-slate synthesis of an organization hierarchy would, ideally, be both top down and bottom up. Top down, the service unit types discussed in the previous section, along with general functional groupings, provide a starting point. Bottom up, highly synergistic service units should be brought together at the operating level; then less intense synergy should bring together these clusters into larger organizations. The analysis and aggregation should be repeated, iteratively, to build the detail of a hierarchy.

Aggregation Factors

The following sections describe factors that suggest which service units should be grouped in the same organization. The aggregation factors suggest grouping at a lower level. Separation factors, discussed later, suggest grouping only at a higher level.

Functional Similarity

A basic factor in service unit clustering is still functional similarity—particularly the similarity of skills and knowledge of members of the service units. Similarity of work products suggests functional similarity. This yields flexibility in the allocation of people to service operations, and it yields other economies of scale for management of the clustered service units in terms of improvement of personnel capabilities, process improvement, and possibly sharing of resources and facilities.

The resources may include people, facilities, tools, data, and intellectual property. There are two primary goals: consistency and economies of scale. Consistency leads to improved performance by enabling problems and improvements to be resolved once and monitored for compliance. Economies of scale come from better utilization of resources and potentially the opportunity to develop specialists and acquire specialized tools. Some resources may be shared among multiple services for high utilization, or may be reallocated when workloads shift. Specialized support services may achieve economies of scale across multiple service units that have similar capabilities.

Thus, we tend to bring together service units that perform engineering functions, customer support functions, manufacturing functions, accounting functions, and so on.

Measures of Performance

The services brought together in an organization hierarchy should have compatible measures of performance. Two different service units are not expected to have the same service objectives, but the metrics relating to quality, timeliness, methods, resource management, and responsiveness to users should be compatible, particularly at lower levels in the hierarchy.

Higher-level managers also need consistent measures of performance for the various services under their responsibility, but the measures may be more generalized on service levels than the performance of particular resources. Where possible, metrics should roll up the chain of command so that the performance of different services and departments (groups of services) can be compared. Managers need to be able to define policies and issue directives without the need to significantly tailor the policies and directives to the differences between service units.

For example, a manager might expect all service units to meet certain metrics for employee satisfaction, employee turnover, salary levels, and absenteeism. This allows the managers to employ common performance measures and leverage improvements across multiple service units. At higher levels in the hierarchy, there are broader scope goals and fewer common operational performance measures.

Degree of Coupling

Traditionally, a high degree of coupling between business activities suggested that these activities should be organizationally affiliated. This was at least in part due to delays in communications between organizations, particularly the formal communications required between organizations that share only a high-level manager. With electronic communications and automated business processes, the degree of coupling should be a much less significant factor.

Today there may be relevant couplings whereby there are concerns about setting priorities or using complementary methods that may need to be resolved by a shared manager. For example, a manufacturing machine repair service unit and production operations should be affiliated closely enough to ensure that preventive maintenance, machine repair techniques, and response to failure are appropriate to minimize production downtime. The degree of coupling between production engineering and production operations probably overrides the potential consolidation of engineering capabilities between product engineering and production engineering based on functional similarity.

Outsourcing

The relationship with an outsourcing provider must be “owned” by a manager within the client enterprise so that there is a single point of contact for negotiations and contract enforcement. The management of the contractual relationship might be assigned to the purchasing organization, but it would be more appropriate to assign it to a manager positioned where the associated service units would be positioned if they were internal. The primary responsibility in either case is to ensure that the needs of the internal users are met with appropriate cost, quality, and timeliness.

There will be a need for adaptation and thus some negotiation of service interfaces provided and used by the outsourcing provider. Additional issues may arise in the future as the provider introduces operational improvements or changes for regulatory compliance. These issues should be addressed at an enterprise level, as with other transformation initiatives.

Separation Factors

The following sections describe factors that suggest that service units should be in separate branches of the organization hierarchy.

Independence from Users

As much as possible, all users of a service should be associated with the management of the service unit at the same management level so that all current and future service users have equal influence over the satisfaction of their requests. Close affiliation of some users can be a problem, particularly when a shared service is created from a segment of an existing organization and remains under the same management. Other service units that are expected to use the shared service are likely to believe that they are receiving lesser priority due to personal relationships, even if the joint manager does not exercise such influence.

Separation of Duties

It is appropriate to separate service units that implement critical controls from the service units to be controlled. This ensures that management policies and controls can be quickly, reliably, and uniformly enforced. This separation is evident in the separation of accounting, human resources, and purchasing services from the services that they support. Funding is controlled by the accounting organization, and business units must establish budgets and obtain disbursements through accounting services. Generally, accepted accounting practices define requirements for separation of duties for financial controls. Hiring, along with administration of personnel compensation and benefits, requires the use of human resource services. Purchasing of materials and equipment must be done through purchasing services to ensure objective supplier selection and negotiations.

Similar services might be implemented for such activities as customer quote preparation, application of certain government regulations, or allocation of expensive resources.

Separation of duties may also be needed where there are competing objectives. For example, it is appropriate to separate inspection operations from the manufacturing production organization or testing services from a product development organization. This also applies where critical records must be maintained or valuable assets could be at risk.

Differences in Service Request Life Cycle

A service request life cycle is the time and activities required to respond to a request. A machine repair life cycle usually is completed in hours or days, depending on the level of urgency and complexity, whereas a product development life cycle could take months or years. Service units and service groups should generally avoid combining services that have short request life cycles with services that have significantly longer life cycles because demands for immediate action on short life-cycle services are likely to divert attention from longer life-cycle services. In addition, performance metrics are likely to be significantly different.

Service Delivery Locations

Generally, we think of services as consolidations of similar activities at one location so that the resources can be shared and economies of scale can be realized. This is not always the best solution, and with the Internet and collaboration services, colocation of personnel may be unnecessary. In some cases, it is necessary for the service personnel to have face-to-face contact with customers or others or to work on a customer site for product maintenance and repair. These personnel should be geographically distributed. It may be important to perform the same services in different countries in a way that is more culturally sensitive. Government regulations may be best addressed by providing certain services in specific political jurisdictions. Some services may be distributed to different time zones to utilize daytime work hours while providing around the clock services.

These circumstances can be addressed in three ways: (1) a distinct service is located in each area, (2) service personnel work remotely from a central service unit operation, or (3) a single service unit has operations that are in multiple locations.

In all cases, there should be a consistent service interface. Where there are distinct service units in different areas, the implementations might not be the same in all locations. This might be a function of differences in infrastructure, culture, regulations, or resource availability.

If there are strong differences among the various locations, it is likely that a decentralized organization of separate service units is more appropriate. Some services still may be brought together based on their geographical proximity. At the same time, these services may utilize centralized, shared services that achieve economies of scale and consistency in certain aspects of their operations. This model is typical of retail operations.

Where the activities are primarily individual employee activities, there could be a single service operation that manages and coordinates the field activities, but the field personnel work remotely, interacting with the service applications for support, assignments, and data entry. This is typical of sales operations, where salespeople spend most of their time visiting customers.

Finally, a single service unit may have distributed operations so that the service users make requests of a single service and the service determines where the activities are performed. This could be a model for an engineering service where different specialists are located in different operating sites. For a service that delivers a complex product, various aspects of product development or production might be located in different countries, to optimize the use of expertise and variations in levels of compensation. Some service units may simply operate with employees who participate remotely from home or client sites, thus avoiding the need to relocate new employees and making assignments to employees based on their proximity to clients.

Organization Modeling

In traditional organizations, the organizational hierarchy defines the primary responsibilities and authority of individuals and organizations. Interorganizational communications are formalized at an operating level, and managers collaborate to make interorganizational decisions.

In a modern enterprise, most employees are knowledge workers who must often collaborate across organizational boundaries. This is particularly true of an agile enterprise in which employees must collaborate with both users of their services and providers used by their service. To be effective, individuals must be able to identify the persons in other service units with whom they need to collaborate. The traditional organization chart no longer does the job.

In addition, business processes that require review and approval of certain actions or agreements must be able to identify appropriate reviewers and approvers. These are not identifiable simply by reference to the organizational hierarchy. They may involve roles in workgroups, task forces, projects, and committees.

New organizational modeling tools are needed to complement the design of processes and services and represent the relationships discussed earlier. Extended modeling capabilities could assist in more effective alignment of service units within the organizational hierarchy. Management of a multitude of service units, coordination of changes, management of risks, and optimization of enterprise performance will require that managers have more robust tools for dealing with this complexity. At this writing, initial work on a standard for organization modeling is under way within the Object Management Group (OMG).

The organization model must reflect multiple management chains. In addition to the conventional management chain, individuals will be engaged in projects, task forces, or other initiatives that cut across traditional organizational boundaries, and they will have a leader and associated management chain appropriate to the particular initiative. These alternative management chains may have responsibility for expenses, access authorizations, or other processes where review or approval is required. The organization model must provide the information needed for such processes to direct requests to the appropriate managers.

Organizational Transformation

Development of a service-oriented enterprise seldom starts with a blank slate but must deal with the realities of an existing organization. The approach should change as the enterprise becomes more mature with respect to the SOA Maturity Model discussed in Chapter 1. Organizations at level 1, Explored, and 2, Applied, should focus on the creation of individual shared services that realize business benefit with reasonable return on investment. In most cases this should result in service units that achieve significant economies of scale through consolidation. Alignment of these service units with the organizational hierarchy should give consideration to the design principles and hierarchy design factors discussed in this chapter.

At level 3 the enterprise should have a strategic view of needed service units. This may focus on the product value chain and enterprise governance requirements for creation of service units and development and integration of service capabilities. Planning for transformation of support services may be deferred except that consideration should be given to outsourcing. The plan for services developed at level 3 may not include a comprehensive plan for the organizational hierarchy since that evolves as services are developed, and the evolution depends on business priorities and the order in which service units are established.

At level 4, much of the organization should be transformed, particularly those elements involved in product and production value chains. Service specifications should be formally defined, and the capture and reporting of performance metrics should be supported by the infrastructure, enabling greater empowerment of service unit managers and their people to pursue improvements. The organization structure should be evolving to a strategic design.

At level 5, the organization structure should be optimized based on the design principles and hierarchy design factors discussed earlier in this chapter. The executive support services described in Chapter 9 should be fully implemented to support continuous change and more effective governance.

In the next chapter we will discuss how the organization structure aligns with the management of disruptive events to adapt the enterprise to challenges and opportunities.