Business architecture

From Wikipedia, the free encyclopedia

“The grouping of business functions and related business objects into clusters (“business domains”) over which meaningful accountability can be taken as depicted in the high level description of the related business processes”.[citation needed]

“Business Architecture” is an architecture that structures the accountability over business activities prior to any further effort to structure individual aspects (processes, data, functions, organization, systems, applications, etc.). A Business Architecture arranges the accountabilities around the most important business activities (for instance production, distribution, marketing, etc.) and/or the economic activities (for instance manufacturing, assembly, transport, wholesale, etc.) into domains.[citation needed]

Main elements of the Business Architecture are “business domains”. They can best be looked at as “areas of accountability”. Within the business architecture a high level description is provided of how the business processes are dealt with by these domains and which domain is responsible for specified business functions or objects. Thus: the main elements of a business architecture are “business domains”, which are clusters of coherent business functions and objects (concepts), over which meaningful responsibility can be taken in business processes. Note that these domains are consciously decoupled from the organizational graph itself and therefore decoupled from current managerial position and interests. Assigning the business domains to specific directors and business units is a subsequent activity (after the creation and acceptance of the business architecture, that is). A Business Architecture contains: 1) the lay-out of business domains (including their occurrences on various levels) and their assigned business activities and added value (“business case”). 2) The business functions and business concepts (high-level data descriptions) that these business domains need (and are responsible for) to perform their assigned business activity. 3) The high level business processes, which shows how these domains work together (interface) to achieve the organizational goals and strategies. Such a business architecture shows higher level management how their strategy will be implemented in their corporation.

Approaches that are focusing on the more or less formal organizational structure as such are, compared to “Business Architecture”, more limited in scope. They generally do not describe items like: business processes, interfacing between organizational domains and business objects. They are therefore of limited use in understanding the consequences of projected strategic change. More often organizational diagrams are a derivative of a target Business Architecture, where the pre-determined areas of accountability (business domains) are subsequently linked to actual departments and managerial key-players.

Contents

[edit] eTOM

The eTOM (tmforum.org) has been applied in a variety of industries, like Telecommunications, Banking, Insurance Industry and Franchise Industry. The same basic structure holds, barring the use of industry specific terminology, e.g. core banking system vs. billing system. eTOM together with NGOSS, has taken the best of TOGAF and Zachman and applied that into a flexible business architecture environment adaptable to a wide range of industries.
The core of the eTOM business architecture framework revolves around the SIP (Strategy, Infrastructure & Product), Operations (fulfillment, Assurance and Billing), Enterprise Management (Strategic Enterprise Planning processes, Financial & Asset Management processes, Enterprise Risk Management processes, Stakeholder and External Relationships Management processes, Enterprise Effectiveness Management processes, Human Resource Management processes, Knowledge & Research Management processes). The "raw" business processes are "overlayed" with the Enterprise Management Processes. Balance Score Card or House of Quality, KPI's and RACI's are added as control and measurement elements to the processes, from which the instructional processes are developed. The ideal is to combine common processes and re-map all processes and process-flows accordingly. Such processes are usable as a basis for SOA implementation, in areas of process automation.[citation needed]

These are followed by an Integration Architecture (SOA-Service Oriented Architecture), Application Architecture and Infrastructure Architecture at an IT/Technical level.

[edit] The TOGAF framework

The TOGAF-framework is a useful starting point to get a grip on how to position “Business Architecture” amongst the plethora of other types of “Architectures”. The TOGAF does not classify the distinct dimensions into pre-defined types, like the Zachman framework does. According to TOGAF (The Open Group Architecture Framework, 2003) four dimensions are relevant in determining the position of an architecture: - Domain: the architecture domains (aspects, viewpoints) such as: business, data, application and technology; - Scope: the enterprise scope: what part of the organization (department, business unit, firm) or even across traditional boundaries (virtual enterprise); - Granularity: the level of detail or level of granularity; - Time: the time horizon: the factual situation, the desired or target architecture or any intermediate situations.

Although the Open group adheres to the IEEE-definition (IEEE 1471, 2000) of “Architecture” (“the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution”), they limit the use of this term to the development of Information Systems: “An architecture framework is a tool which can be used for developing a broad range of different architectures. It should describe a method for designing an information system in terms of a set of building blocks, and for showing how the building blocks fit together”. The Open Group as so many others do, limit the concept of “System” to “Information system” and in doing so limit “Architecture” to the realm of Information Systems. This common myopia might well be one of the reasons why the business oriented disciplines, like Business Administration and Organizational Design, shy away from using “Architectures” in their practice, depicting it as an IT pastime. This is unfortunate, because they also miss the advantages of using Architecture to gain understanding in the ever increasing complexity of current, often networked organizations.

Although the Open Group limits their framework to be used to develop Information Systems only, their framework includes a “Business Architecture”. This is described as: “a business (or business process) architecture - this defines the business strategy, governance, organization, and key business processes”. It is distinguished next to Application Architecture, Data Architecture and Technology Architecture. This classification refers to the domain-dimension of the TOGAF. Architectures for the business domain are less common than architectures of any of the other domains. Business Architectures give structure to aspects that are in the business domain instead of the IT domain. As stated earlier, architecture (aside from physical building architecture) has always mainly been an IT-prerogative. The concept of architecture is scarcely used in the realm of organizational theorists. An exception can be made for process architectures that are getting more and more attention. However in common practice, these process architectures are still initiated mainly by the IT discipline based on the need for the enhanced specification of requirements and to better tune IT architectures to their use in business processes. The other three dimensions of the TOGAF are all considered to be relevant to the concept “Business Architecture”.

Looking at “scope”, Business Architectures can be used for supply chains, networked organizations, individual enterprises, business units, departments, etc. One of the more recently trendy scopes is the Enterprise Architecture. As with all architectures, these enterprise-scoped architectures are mainly IT-oriented. They usually focus on Enterprise Application Integration issues, addressing the diversified state of IT solutions in many, often merged organizations. One could refer to a Business Architecture with an enterprise-wide scope as an “Enterprise Business Architecture” as opposed to, for instance, an Enterprise Information Architecture.

Regarding the dimension “level of detail”, Business Architectures can appear in various levels of detail. The level of detail is mainly tied to the scope of the architecture, the smaller the scope the more detailed the Business Architecture usually is. An Enterprise Business Architecture generally contains less detail than the Business Architecture of one its departments. A set of business architectures for a certain organization can contain a top-level Business Architecture completed with more detailed sub Business Architectures for its Business Units and so forth. In today’s practice however, Business Architectures are usually very high level structures with little detail.

The “time”-dimension, is also recognized in Business Architecture, where “as-is” Business Architectures represent the current state of affairs and “to-be” architectures represent a targeted state of affairs for a time frame of three to five years (or at least consistent with the time frame of the underlying formulated business strategy). Usually Business Architectures are used to describe and clarify necessary changes to the current business, mainly to be able to understand where to go.[citation needed] Architectures of the current state are usually drawn to better understand the scope of projected changes or to be to analyze the gap between the targeted situation and the current status-quo. Based on this gap it is common practice to setup a migration approach to be able to reach the targeted situation. Gap analysis and subsequent migration scenarios are used in all of the types of architectures.

In short, measured by the TOGAF-dimensions, Business Architecture focuses on a specific domain (business), while keeping the full breadth of the other dimensions (scope, time and level of detail).

[edit] Business Strategy

Business Architecture is directly based on business strategy. It is the foundation for subsequent architectures (strategy embedding), where it is detailed into various aspects and disciplines. The business strategy can consist of elements like strategy statements, organizational goals and objectives, generic and/or applied business models, etc. The strategic statements are analyzed and arranged hierarchically, through techniques like qualitative hierarchical cluster analysis. Based on this hierarchy the initial business architecture is further developed, using general organizational structuring methods and business administration theory, like theories on assets and resources and theories on structuring economic activity. Based on the business architecture the construction of the organization takes shape (figure 1: strategy embedding). During the strategy formulation phase and as a result of the design of the business architecture, the business strategy gets better formulated and understood as well as made more internally consistent.

The business architecture forms a significantly better basis for subsequent architectures than the separate statements themselves. The business architecture gives direction to organizational aspects, such as the organizational structuring (in which the responsibilities of the business domains are assigned to individuals/business units in the organization chart or where a new organization chart is drawn) and the administrative organization (describing for instance the financial reconciliation mechanisms between business domains). Assigning the various business domains to their owners (managers) also helps the further development of other architectures, because now the managers of these domains can be involved with a specific assigned responsibility. This led to increased involvement of top-level management, being domain-owners and well aware of their role. Detailed portions of business domains can be developed based on the effort and support of the domain-owners involved. Business architecture therefore is a very helpful pre-structuring device for the development, acceptance and implementation of subsequent architectures.

The perspectives for subsequent design next to organization are more common: information architecture, technical architecture, process architecture. The various parts (functions, concepts and processes) of the business architecture act as a compulsory starting point for the different subsequent architectures. It pre-structures other architectures. Business architecture models shed light on the scantly elaborated relationships between business strategy and business design. We will illustrate the value of business architecture in a case study

[edit] Business Architecture Perspectives Introduced by SOMF - An Integration Framework

The Service-Oriented Modeling Framework (SOMF) expands on the business architecture paradigm. It introduces two major business architecture perspective groups, each of which equally contributes to the integration of business imperatives with enterprise software entities. The SOMF accentuates the value of alignment of business and IT organizations, and offers a common vocabulary and a business architecture modeling language that business and IT practitioners can employ to model an enterprise business architecture.[citation needed]

So what are the two major SOMF business architecture artifacts that enable software entities, naming services to integrate with the business?

  • Business Architecture Structural Perspectives: introduce a physical platform for integrating services with business structures and enterprise formations, such as business domains (business tiers and layers) and even geographical locations
  • Business Architecture Contextual Perspectives – these are business model and business strategy views of an organization that enable software assets business integration and alignment. Contextual Perspectives are rudimentary pillars of an organization's existence, such as Core Products Perspective, Cultural Perspective, and even Market Segmentation Perspective etc.

[edit] References

Languages