Introduction 

Dealing with the complexity of a large organization when developing an Enterprise Architecture, or other contexts, can be quite daunting. The differences between a small and large organization lies in the broader spectrum of products and services, often within several totally different business lines or domains. Generally the higher the complexity of the enterprise, the more distributed the organization and the market (both conceptually and physically). This results in a larger number of more complex business activities, involving many more business actors with more specialized tasks, and a diversity of business locations each having quite separate and different business activities.

The techniques proposed here, for dealing with the complexities of architectures, may be applied independently or in combination. They may also be used for other levels of IT architecture, even down to project and system architectures.

Partition the Models

In Concept: Architecture Perspectives and Viewpoints the concepts of perspectives (and layers within them) and aspects (partitions) are described. Partitioning may also be applied to the IT architecture as well. For example, the first step in defining an enterprise architecture could be to partition the enterprise into large business lines or business domains. A list of possible approaches for this partitioning are:

• Business Lines - large organizations may have completely (or mostly) independent business lines (divisions), for example a hardware division and a software division.
• Core vs. Support vs. Management - partitions are defined for the core business activities (e.g. hardware manufacturing), the management activities (e.g. senior management, production management, financial management, HR management) and support activities (e.g. IT support, operations, HR operations, financial operations).
• Location - depending upon the type of organization, partitioning along geographic lines may be an option.
• Other - other approaches to partitioning are possible, the criteria for success being low-cohesion between partitions (i.e. few interactions across partition boundaries).

This technique could be summarized as "horizontal divide and conquer" since the enterprise is being partitioned (divided) into large activity areas (at the same level of abstraction). For example, a large IT company that produces both hardware and software products could be partitioned at the highest level as shown below.

Figure 1 - Combination of Business-line and Organizational Partitioning

In this example, we see the enterprise partitioned into Corporate Management, a Hardware Division, a Software Division and Corporate Services. Each of these partitions could be modeled independently; however there will likely be many dependencies between Executive Management and Corporate Services, therefore one might consider creating a single enterprise architecture for these two partitions. Each of these high-level business activities are viewed as having separate IT architectures. Note also that these IT architectures may also be partitioned and layered to deal with their complexities.

Functional Layering

In software engineering, a technique used to handle the complexity of very large systems is called layering. The idea behind this technique is to separate the application-specific parts from the more general parts of the system, so that the program units and program services can be reused or kept largely independent (with well-defined interfaces). When structuring IT architectures, the same principles are often naturally applied. For example, in the bottom layer you find resources that provide general services; somewhere in the middle layer you often find resources that support business-specific activities; and in the top layer you find business area-specific or product-specific specialists, Research and Development, and sales force activities. Core business activities may use resources from all layers.

Compared to a non-layered Business Model, a layered Business Model should be developed with two recommended restrictions in mind:

• A business activity in a certain layer (of abstraction) never makes contact with a business activity or manipulates a business entity of a higher layer, except on explicit request from someone in the higher layer. Similarly, business events from higher layers should not be propagated to lower layers, but re-defined (in more detail) if needed.
• A business activity has responsibilities only within its layer.

Without these restrictions, a layered structure quickly degenerates. Note that these restrictions apply to the case where the most general parts of the business are found in lower layers (e.g. Call Activities), while the most specific may be found in the upper layers. 

Another complimentary approach is to layer based upon the OSI network model, or more specifically the application, presentation, and network layers. Layering in this context is functional layering — each layer contains a set of like-functions, such as application or network in the OSI approach. A similar approach, more applicable to the Logical and Technical architecture perspectives, can be used to define layers. In this approach detail is hidden or encapsulated, and can be described as conceptual layering, which is described next.

Conceptual Layers

Layering may be done in any perspective and aspect (see: Concept: Architecture Perspectives and Viewpoints). We now describe how to do this in the UAM IT architectures.

In addition to the partitioning approach described above, one may also define layers within partitions, that is, within a particular architectural viewpoint—hierarchical views of the business. High-level layers provide general viewpoints of the enterprise or business domain (the "system") at a high conceptual level, with lower layers adding detail—"vertical divide and conquer". This fits nicely with the audience for these different viewpoints and layers. For example, a company's executive management, as well as its process owners, are interested in their company's business models—management must work with the company's strategic objectives, whereas the process owners and leaders need a more detailed picture of how their process should be performed.

If the enterprise (i.e. the "system" being architected) is large and complex, or if differences between the executives' and the process owners' views of the organization are great, this can be dealt with by developing two (or more yet related) layers. One model, for the executives, would contain a set of high-level business activities that show the intent and purpose of the organization. The other model, for the process owners, would contain a detailed set of activities that help clarify how the organization needs to function internally. For each high-level business activity, you could define one, or several, detailed business activities representing the same thing within the organization. For example, you could start with the primary business actor, detail the results and services he or she is interested in, then develop a separate business activity for each detailed area.

If you want to engineer your organization one business activity at a time, you can apply this technique incrementally. First make a high-level activities model of the entire business and then "drill-down" into one of the activities of interest to provide a more detailed model for the process owner. There is a one-to-one relationship between a high-level business activities and its set of more detailed business activities — with the detail encapsulated within the activity. The figure below illustrates this concept. The "Sales & Marketing" activity (Contained within a Customer Relationship Management (CRM) high-level activity) is drilled-down to expose more details.

Figure 2 - Layering of IT Architectures to deal with complexity

Note the  decorator on the "Sales & Marketing" activity, indicating that the next layer of detail of this "collapsed sub-process" has been defined. 

Focus on Core Business

In many cases, you are interested only in detailed information about one or a few of your business processes, depending upon the objective of the architecture effort. However, to provide context, it is wise to identify the complete set of business activities and briefly describe each of them. This results in a model that includes core business activities, supporting business activities, and executive management business activities for example — in other words the enterprise (or system under study) is partitioned. Once an overall model is constructed, to provide the context for the IT architecture effort, the next layer of modeling focuses on the business activities of interest and develops more detail. 

This is illustrated in Figure 3 that shows an overall model of an enterprise, with the highlighted activities being the ones of interest and that will be developed in further detail — either within this IT architecture, or in their own separate IT architectures.

Figure 3 - The entire organization; the next layer focused on the highlighted areas of interest