Organizing your business architectures with Business Architecture

A business of any size will have invested in creating models of business structure (e.g. organization charts, application portfolios) and behavior (e.g. process definitions, policies). Typically these architecture models were created to support specific initiatives and may no longer be current and are likely to be scoped to the needs of the initiative. They still contain valuable information about the business, and can be reused in other initiatives, assuming that they can be found and made current. However, they are likely to have been archived along with other information (e.g. project plans, scrum objectives, budgets) that are less likely to be reused. Archiving is a necessary step to support reuse, but architecture documents that cannot be found will inevitably be re-created, wasting time and money. In 2001, IDC started to gather data about what not finding information might cost a company. Some results from that study and others are summarized in this article. If your business is exceptionally mature and manages your portfolio of architectural models in an architecture repository, you can stop reading right now. If not, this blog post will suggest a strategy for creating and managing a repository of business architecture models.

Before we get to the strategy, let’s be clear about what we mean by architecture models. A process model defined in BPMN would be a good example of an architecture model. Business analysts often create these models as a way to analyze a process and to document potential changes to the process. An organization chart is another example; however there is no commonly accepted standard for modeling organization structure, so the organization chart may be defined in a presentation, in a spreadsheet, in a database, or in a business directory. Ideally, an architect would want to be able to use a stable reference to a file, dataset or document containing the model and to associate with that reference, some description about what the model is about (e.g. it is a process model for order fulfillment) and to manage these references and associated descriptions in a dataset. Fortunately, almost any information artifact can be given a URL to serve as a stable reference. The description could be in prose text (as in the example above) but prose text is difficult to search. A better solution would be to have a stable set of categories for business structures and behaviors.

The descriptive categories should be fairly high level to facilitate architects and analysts using them to find models and examine them for potential relevance to an analysis project or planned initiative. For example, if the business is contemplating a new technology to support the marketing function, it would be useful to examine existing marketing process definitions and organization structures to understand the impact of the new technology. If the descriptive categories are too specific, the analyst may miss some relevant categories in the inquiry and get an incomplete set of models.

These categories can be derived from your business architecture model, but what would be the benefit of using the business architecture and how would the categories be excerpted from the business architecture. If you are unfamiliar with business architecture, you can find out more about it at the Business Architecture Guild® website. Business architecture views a business from several perspectives; in this case, we are interested in the capability perspective. Capabilities describe what a business does but do not describe the structure of a particular business; consequently, when businesses reorganize themselves or decide to in-source or out-source, the capability structure of the business does not change. This perspective is useful when comparing two businesses in the same market segment, but for our purposes, the stability of the capability model is what makes it useful as a source of categories, as these are unlikely to change as a result of reorganization or strategic business transformation.

The following table shows a tree of capabilities that are commonly found in businesses (they are taken from the common reference model of the Business Architecture Guild – this model and other industry specific models are available to members of the Business Architecture Guild). The second column in this table indicates the level of detail in the capability tree; so the level 3 capabilities are part of the level 2 capability above them in the table.

Our experience is that level 2 capabilities provide sufficient differentiation of categories for most businesses. However, the architect may find it necessary to also use some level 3 (or deeper) capabilities. The level 2 capabilities provide category tags that can be applied to parts of an organization chart. Sometimes several departments in an organization chart would have the same category tag. This could result from geographical duplication of a capability (e.g. market definition in Asia and market definition in Europe). But it can also result from using an overly broad capability (e.g. one department is responsible for market segment identification and another department is responsible for market segment prioritization). In this case, the architect may elect to use level 3 capabilities. Sometimes a department may have multiple category tags. This is typically the result of insufficient detail in the organization model (e.g. teams within the department that are missing from the model). When an architect sees this situation in the course of analysis, it will often be necessary to investigate the department structure that is not recorded in the organization model

Business process definitions occur at many levels of detail. Some high level business processes simply represent major stages in the accomplishment of an objective (e.g. order to cash). Other business process definitions are very detailed and define activities to be carried out by people and technology. Consequently, when categorizing a business process definition model, the architect may choose a capability level 3 (or deeper) capability if the process definition is detailed. This has been done in practice using the XML representation of BPMN models. A BPMN activity that would be categorized by a level 3 capability can be identified in the XML document using an XPath expression. A fully qualified reference can be constructed by appending the XPath expression as the query part of a URL that references the XML document.

To operationalize this technique, one would need to collect the category/reference pairs in a data set that supports a query function. This data set would need to be updated whenever an architecture model is created, changed or deleted. Creating the initial dataset will be labor intensive because of the need to find candidate architecture models, review them for currency, select elements of the model for categorization, and create the category/reference pairs. In practice, this would be done as an adjunct activity in an ongoing initiative that needed to create new models and/or reuse existing ones.

If you’ve found this post interesting and want to know more or to begin implementing this idea, please contact us at Thematix. We are Certified Business Architects® and are primary contributors to the Business Architecture Guild’s intellectual property. We have deep backgrounds in both executive and technical consulting. We can help you achieve your goals and save you time and money on the way.