PurposeThis guide illustrates different ways to model complex organizational structures in Ardoq and the relationship between capabilities, organizational structure and applications within large enterprises.
Large enterprise modeling patterns are intended to assist organizations in addressing the best way to model the relationship between complex multi-operating model companies and their independent, shared, variant business capabilities; and the IT landscape that realizes them. As an example, consider companies that run commercial operations in different operating countries and require duplicated capabilities, such as revenue management, that are realized with small variations to handle local regulations.
This guide will walk you through the following decisions and explore the key considerations and recommendations for modeling Large Enterprise Structures, Capabilities and Application Portfolios to get the maximum value out of Ardoq:
| Before you beginArdoq strongly recommends reading the Organizational Modeling Guide and Organizational Modeling Metamodel.
In addition, familiarize yourself with the Business Capability Realization and Application Lifecycle Management guides. They provide additional information to assist you in modeling enterprise patterns.
|
The collection of patterns presented here are ‘best practices’ collected from interviews and conversations with many experienced practitioners. Each pattern, when used correctly in the right context, has the potential to bring huge benefits to your work and to the enterprise as a result.
How a Large Enterprise should model their Organization
***
Large scale enterprise organizations present significant challenges when modeling their complex structures.
In this Context
Conglomerate Organizations or Enterprise Organizations can be made up of multiple lines of companies broken down by a number of factors such as verticals, business lines or divisions. This creates a dilemma for architects. On one hand they can represent the organization when modeling through the use of singular workspaces. However, this approach is limited in its ability to truly reflect the organizational model. This is largely because large organizations often reflect autonomy, organizational structures based on verticals, business lines, products, value streams ,divisions and many other factors. This requires a greater degree of control and flexibility when effectively modeling the organization as well as the composite capabilities and application portfolios.
Therefore
The architectural model must support analysis of different parts of the organization in a more granular way than a single workspace can provide. This means representing the parent or holding company and each subsidiary in individual workspaces.
Modeling the top level (parent / holding company) and each subsidiary in individual workspaces.
Populate the individual workspaces with the organizational units relevant to that part of the organization.
Connect the parent organization to its subsidiaries or child orgs by utilizing the “owns” reference type.
Where cross organization organizational units exist, place those components in the organizational workspace where they are directly managed.
These principles are detailed in our guidance for modeling organizational structure. Modeling this way allows you to leverage workspace level permissions for each organization, meaning each organization can be responsible for ensuring their organizational data is current and accurate. This also allows enterprises flexibility in how they choose to model capabilities, applications and other components. This also allows more granularity in creating visualizations for each part of the organization.
CONSEQUENTLY
Modeling organizations in this way means each logical area broken down into workspaces can be analyzed in terms of its own related cost, size, capabilities, applications portfolios and create opportunities for standardization, simplification and rationalization throughout the organization. Rather than whether or not the organization is based on hierarchy, bureaucratic, flat, matrix or other organizational design considerations.
Separating each part of the organization into individual workspaces allows for greater autonomy and control for administrators and the creation of relevant components and references.
This pattern can also be used as a temporary modeling step, for example,, with the objective of identifying a set of consolidation initiatives as part of an organization merger or acquisition.
SEE ALSO
Organizational modeling patterns for simple, stand-alone organizations are detailed in the Organizational Modeling Patterns guidance.
Overview of Modeling Business & Technical Capabilities in Complex Organizations
Organizations can be manifested in a wide array of operating models which can require a greater level of flexibility when modeling capabilities. Ardoq has four patterns to assist architects with their efforts to model capabilities in complex organizations. The following table connects an Organization’s operating model context to the most appropriate pattern to use.
Criteria | Recommendation |
Organizations where there is no replication of capabilities or where the replication has minimal variation ) | Utilize a single workspace for all capabilities in the enterprise which is the standard approach as demonstrated in Business Capability Modeling. |
In organizations where different implementations of the same capability may occur and where parts of an organization have a high degree of autonomy. These may, for example, be similar operations in different geographies or overlapping businesses that have come together in a merger or acquisition | See the Atomic and Instance Capabilities pattern. |
Organizations that have adopted standardized approaches to the utilization of their business and technical capabilities. Specialized business units will have ownership of the capabilities that are unique to their business domains, while other, more generic, capabilities that are consumed by many parts of the organization | See the Shared Capability Pattern below. |
Organizations where specialized business units offer capabilities that differ dramatically from the rest of the mainstream business lines (and often operate with a high level of autonomy), | Considering utilizing the Hybrid Capability Pattern |
These are recommendations however, you will need to decide the best fit for your organization and needs. Where capability instances are utilized, Ardoq strongly recommends using a standard naming convention to identify instances vs the root/atomic capability. This could be as simple as naming the Capability Recruitment and the instance Instance-Recruitment where Recruitment is the atomic capability.
Please note: If you are modeling Capability Deltas as part of the Strategy to Execution Use Case then the capability delta should be in the same folder in the workspace as the capability that it is connected to.
Atomic and Instance Capabilities
**
Analyzing organizations where the same capabilities have been implemented independently in different parts of the organization
IN THIS CONTEXT
Different implementations of the same capability may occur where parts of an organization have a high degree of autonomy that sustain these different implementations. These implementations may be as a result of essential variation or accidental and may be a result of operations in different geographies or overlapping businesses that have come together in a merger or acquisition.
Essential: Different regulatory and legislative compliance regimes in each country require the realization of the same capability in different ways.
Accidental: An acquired company that does the same thing in a different country however an effort to consolidate the capabilities through rationalization has not occurred yet.
Companies use capability maps as a way to overlay information about their quality, their gaps, criticality, market differentiation, etc. In Ardoq this is often automatically derived from the information that is connected to the capability components in the architecture model. Therefore it is necessary to unambiguously distinguish between how a capability is realized for different parts of a complex organization.
THEREFORE
The architecture model must support analysis of different implementations of the same capability. This requires modeling atomic capabilities with a set of components that are connected to components that represent each capability implementation or instance.
Model a complete representation of all business capabilities across the whole organization in a single workspace. These are your atomic capabilities, representing the abstract concept of each capability, not their implementation.
Have a separate (fully replicated) copy of each capability to represent each implementation instance of the capability. It will be connected from its corresponding atomic twin with an Is Realized By reference.
If different business units implement different iterations of the same capability, each will have its own instance component of that capability, all with Is Realized By references from their atomic twin.
Each Instance capability component will have its own Is Realized By references to the organizational units, applications and processes that combine to form their implementation, resulting in its own level of cost, maturity and complexity. These may be organized in separate workspaces for each organizational unit, with another workspace for capability instances that are centrally provided for consumption by multiple organizational units.
CONSEQUENTLY
Instance capabilities that realize the same Atomic capability can be analyzed separately in terms of cost, maturity and value for money, resulting in options for standardization, simplification and rationalization or justification to maintain multiple implementations.
Separating representation of Atomic capabilities from each deployed Instance necessarily involves a proliferation of similar components and references. Only with this additional information can differences be articulated and analyzed.
Adoption of this pattern may be a temporary measure, with the objective of identifying a set of consolidation initiatives that will result in adoption of the Shared Capabilities Pattern. This might be the situation when planning the merger or acquisition of multiple organizations.
SEE ALSO
If an organization only has a single implementation of each capability, or analysis of differences between implementations is of no interest, consider adopting the simpler Shared Capabilities Pattern.
If an organization has just a small number of duplicated capabilities, consider analyzing just those that are different in separate workspaces using the Hybrid Capabilities Pattern.
Shared Capabilities
***
Analyzing organizations where each capability has a single implementation (or where analysis of duplicated implementations is of no interest) this is consistent with the pattern described in the Business Capability Realization use case.
IN THIS CONTEXT
Many organizations have adopted standardized approaches to the utilization of their business and technical capabilities. Specialized business units will have ownership of the capabilities that are unique to their business domains, while other, more generic, capabilities that are consumed by many parts of the organization may be delivered by centralized, shared services functions, or be implemented across the organization with standardized specifications, using the same technologies, processes and skilled people. Most small and medium enterprises will fall into this category, but many mature large or global organizations recognize the efficiencies that come with high levels of standardization.
THEREFORE
With a single instance for each corresponding atomic capability (or minimal variation of implemented instances), information that describes the atomic concept of a capability, and that which describes its implementation (its maturity, complexity and cost) can be stored in a single capability component.
As we have just one implementation of each business capability there is no need to have atomic and instance information in separate components. Represent all business capabilities across the whole organization in a single workspace, with each component defining a distinct capability and containing information about its implementation.
Each capability component will have its own Is Realized By references to the organizational units, applications and processes that combine to form their implementation, resulting in its own level of cost, maturity and complexity.
CONSEQUENTLY
The model supports capability analysis, such as comparing the cost, maturity and value for money across different business capabilities and relating these, for example, to business criticality.
The merging of atomic and instance capabilities into one composite component brings simplicity, but also limitations. Different implementations of the same capability, which may utilize different people, processes or technologies, cannot be clearly modeled without introducing ambiguity and loss of independent analysis. For example, two technology components linked to one capability can rightly represent the contribution of both technologies in delivering the capability. But they might wrongly be intended to represent duplicate functionality delivered in different implementations of that capability by different parts of the organization. If the latter is the case, one capability component is being used to represent multiple instance capabilities, and it will not be possible to separate the cost, maturity and composition of each instance with this pattern. The two forms of representation will be indistinguishable, rendering effective analysis impossible.
SEE ALSO
If you need to analyze and understand different deployed instances of the same capabilities you should consider adoption of a different pattern.
Where many capabilities have different or competing instances, consider adopting the Atomic and Instance Capabilities Pattern. This might occur where a large organization has given business units with similar capabilities a high degree of autonomy (e.g. by geography), or where two largely overlapping organizations are involved in a merger or acquisition.
Where a small number of capabilities have different implementations, and you need to conduct an analysis of these (perhaps to explore consolidation and standardization), consider analyzing just those that are different in separate workspaces using the Hybrid Capabilities Pattern.
Hybrid Capabilities
***
Organizations where specialized business units offer capabilities that differ dramatically from the rest of the mainstream business lines (and often operate with a high level of autonomy) like a typical bricks and mortar organization that spins up or acquires a business unit to offer digital services to an adjacent market.
IN THIS CONTEXT
Specialized business units/divisions/subsidiaries that operate with a high level of autonomy within an organization and have ownership of the capabilities that are unique to their business domains. These capabilities are only consumed within that part of the organization or by its direct customers and delivered by specialized technologies, processes, and people.
This is typically observed in conglomerate style organizations where a corporation of several different, sometimes unrelated, businesses operate. In a conglomerate, one company owns a controlling stake in several different companies which operate in different industry verticals. This may not be limited to conglomerates but can also manifest itself in medium, large and global organizations where a high degree of standardization is required in shared or common capabilities but there exists a high level of autonomy and specialization in a particular business unit(s).
However, the same organization may also have generic, shared capabilities that are consumed by many parts of the organization.These may be delivered by centralized, shared services functions, or be implemented across the organization with standardized specifications, using the same technologies, processes and skilled people. For example, a multi-operating model organization may have shared HR or Finance functions.
THEREFORE
Each autonomous part of the organization which is responsible for its own capabilities will populate its own capability workspace with the specific capabilities to that business unit. This allows for direct control and management of those capabilities for specialized business functions.
The organization which delivers specialized services would model its own capabilities in a dedicated workspace.
Specialized capabilities could be both the atomic concept of each capability and/or, where required, contain information about their implementation instance if required.
For more generic capabilities linking to the shared Atomic or Instance capabilities would be consistent with the shared capability pattern.
Each capability component will have its own Is Realized By references to the organizational units, applications and processes that combine to form their implementation, resulting in its own level of cost, maturity and complexity.
(The diagram shows where there are Specific Capabilities which differ significantly from the mainline business capabilities and subsequently illustrates where the capability instance [Instance - Recruitment] is implemented in the specific capability workspace.)
CONSEQUENTLY
The model supports organizations where business units have a high degree of specialization and autonomy is required. The Hybrid Pattern still allows for capability analysis, such as cost, maturity and value for money across business capabilities and relating these, for example, to business criticality.
This allows architects to more efficiently model those specialized business units and the utilization of different people, processes or technologies, which are specific to that business unit.
An example of this could be where a conglomerate organization operates in a number of different verticals. While generally speaking common capabilities like Finance, HR, Sales, and Marketing may all be common across the verticals, each vertical may deliver specialized capabilities which are dedicated to that vertical like Energy, Technology, Property Development, etc.
SEE ALSO
If you need to analyze and understand different deployed instances of the same capabilities you should consider adoption of a different pattern.
Where many capabilities have different or competing instances, consider adopting the Atomic and Instance Capabilities Pattern. This might occur where a large organization has given business units with similar capabilities a high degree of autonomy (e.g. by geography), or where two largely overlapping organizations are involved in a merger or acquisition.
Many organizations have adopted standardized approaches to the utilization of their business and technical capabilities. If you need to conduct an analysis of these capabilities consider using the Shared Capabilities Pattern.
Deep Dive into Business and Technology Capabilities
An enterprise is an endeavor of people with a shared ambition. An organization is a business with a distinct legal entity. An organization may have a group structure, with a parent organization and multiple subsidiary organizations. An organization may contain multiple organizational units, which in turn may be composed of additional organizational units.
An enterprise may be composed of one or more organizations. They need not necessarily belong to a common parent organization (they might be collaborating partners in a virtual enterprise, or complementary public services).
A business capability is a logical activity or group of activities performed by the enterprise to achieve a specific outcome. It contains the abstract concept of the activity, e.g. “financial management” (which we will call an atomic capability), and a representation of its realization which is achieved with some combination of people, organizational units, processes (or value stream) and applications (which we will call a capability instance1). In a large enterprise, some business capabilities are unique to some parts of the enterprise, while others may be required by more than one part of the enterprise. It is worth noting that In simple organizations the atomic and instance capabilities are the same component. There is no requirement to differentiate between the atomic and instance capabilities in these types of organizations.
Where a business capability is required by more than one part of an enterprise, different models of realization may apply:
Each part (organization, subsidiary organization or organizational unit) may realize the capability independently (with its own people, processes and applications). With this model, the atomic capability is shared, but the capability instance is distinct.
Each part may realize the capability in the same way, but separately (i.e. using the same processes and applications, but with its own people, and separate instances). With this model, the atomic capability is shared, and some aspects of the capability instances are also shared, while others are distinct.
Each part may consume a realization of the capability delivered by a single organization or organizational unit (a shared services approach). With this model, both the atomic capability and capability instance are shared.
(1 - This is similar to the way Capability Instances are defined in BizBok, https://cdn.ymaws.com/www.businessarchitectureguild.org/resource/resmgr/whitepapers/business_architecture_metamo.pdf)
A large enterprise may use any or all three of the above models to deliver different shared atomic capabilities. The organizations that make up the enterprise might serve different geographies with similar products and services (thus requiring the same set of atomic capabilities), or provide different products and services to distinct markets (requiring distinct capabilities). A mix of the two is not uncommon.
As highlighted in the article Getting Started with Business Capability Modeling, an enterprise’s business capabilities is foundational to understand the business, facilitating the connection between the strategic “what” with the tactical “how”. The variety in enterprise size, structure and maturity and their different approaches to deploying and utilizing capability will influence the most suitable way to model them. As will the range of different questions an architect is seeking to answer with the aid of their model.
The result is a set of design possibilities, each representing different compromises between competing quality characteristics. This set of trade-offs will be familiar to architects! Simplicity can be improved at the cost of reduced functionality. Adaptability at the cost of increased complexity and reduced maintainability. Improved analyzability at the cost of reduced longevity, with the consequence of more frequent refactoring.
To aid the architects’ design decisions, we’ve defined a number of design patterns, representing three different approaches to modeling business and technical capabilities, each of which favors a different context. They are not the only three possible approaches, but we suggest that one of these will represent the best starting point for you to deliver business value from your effort to model your particular enterprise’s capabilities.
The Ardoq approach to modeling is extremely practical. We use it to produce business value. Capability maps provide a base layer to overlay information, for example, cost, quality, criticality, gaps, etc. They serve a purpose not just to represent what the business does and how it does it. Capability maps have this utilitarian nature, which drives the way we identify patterns.
Modeling Applications in Complex Organizations
Enterprise Organizations require a greater level of flexibility than simple organization when modeling applications. To that end there are three main ways to group applications into workspaces:
Criteria | Recommendation |
| Utilize a single workspace for all applications in the enterprise which is the standard approach as demonstrated in Application Lifecycle Management. |
| Utilize a workspace for shared applications and dedicated workspaces for applications specific to each organization / business line / division where appropriate. |
| Utilize an Application Workspace Per Organization. |
Components
Application - An application is the configuration of lower-level software or technology to provide specific business capability or technology capability, perform a defined task or analyze specific information. An application represents the automation of human tasks and is designed to be directly used by humans. Applications are distinct from other classes of technology in that they are aligned to the requirements of humans and not to the technical requirements or dependencies of other software.
Business Capability Ardoq defines a business capability as a logical activity or group of activities performed by the organization. Unlike a business process, a business capability is defined by grouping activities that access or utilize a common resource (like customer information) rather than in response to a particular trigger or event.
Technical Capability - Is a logical set of functions to be performed by a technology, technology service, database or application. Technical capabilities broadly align to the technology categories defined by the market (e.g. by Gartner / Forrester). Technical capabilities represent lower-level function than business capabilities. They can be composed or configured to provide multiple business capabilities or even other technical capabilities but are not natively aligned to any particular one.
*Capability Instance (Business Capability Variant) - Can apply to both Business and Technical Capabilities. This is not a new component type rather utilizes the Capability component type (business or technical) with a field to indicate Atomic or Instance, a succinct naming convention and instance workspace to indicate that the component is an instance.
Organization An organization is the top-level component representing an organization. This component type is used to represent the main organization as well as other organizations that form part of its wider ecosystem, such as partners.
Organization Unit An organizational unit is an internal subdivision of an organization. Organizational units decompose into business units, departments, sub-organizations, committees, teams and groups to enable the creation of organizational hierarchies.
The aforementioned patterns can be extended to things like Process or Value Streams
Enterprise Patterns References
Enterprise Patterns relies on three main reference types:
Reference | Description |
Is Realized By | Represents that a component implements the logical requirements, behaviors, or characteristics defined by another component. As an example: a Business Capability is realized by an Application. |
Owns | Owns represents that a component has overall responsibility for another component or components.
As an example: an Organization is broken down into organizational units. |
Consumes | Represents that a component consumes or potentially consumes or gains value from another component.
|
Additional Considerations
Naming Conventions for Capability Instance components
It is important to clearly differentiate atomic components from their respective implementations. Use a clearly defined naming convention to indicate instances which should include an organizational unit identifier. In the example below, we demonstrate this through the use of a prefix “instance -” for recruitment.