BT

The Subject and Discipline of Business Architecture

Posted by Michael Poulin on Dec 02, 2013 |

Business Architecture has become a modern term. It is like a security, everybody has heard about it and has a personal opinion but very few know what it actually means.

This article discusses the phenomena of Business Architecture considering both its subject and discipline. Without knowing the subject of Business Architecture, it is very difficult to justify the scope and extension of the role of a Business Architect, i.e. the discipline. Many Managers and Architects can say – “What’s the problem? By identifying stakeholders and collecting their viewpoints, one could essentially define a Business Architecture”. Unfortunately, this approach is the major fault that leads to many contradicting opinions about this subject.

The proponents of defining Business Architecture via opinions of stakeholders subconsciously change focus from “what it is” to “what can it do for me” and usually refer to the ISO/IEC/IEEE 42010 standard 1 addressing viewpoints and views. However, this standard warns that views cannot define a subject but can only describe it. We deal here with a difference between ‘description’ and ‘definition’. One can collect thousands of descriptions and still would not have a definition of the subject because every description or view is subjective, in other words everyone sees what she or he wants to see.

I have noticed that in numerous discussions about Business Architecture at conferences and on the Web , the debate mostly shifts into what Business Architects do or should do, which is a different matter. When we are defining a view on car driving, does it define the car? No, it does not because the process of driving relates to only a few operational controls in the car and their effect on the movement. Additionally, there are special driving rules and regulations that cannot be found by observing a car; just reviewing the outside-in views on a car we cannot find what is under the hood. If we cannot resolve this simple case with a car, then why should we assume that stakeholders know more about Business Architecture via their observations than the Business Architects do?

In this article, I describe a method that has led me to the definition of an Enterprise Business Architecture irrespective of the business domain of the enterprise. As a result, Business Architecture appears simpler than many think and, simultaneously, has more complex relationships with the rest of the business in an enterprise. I will articulate the reasoning for this conclusion and list some outcomes of it.

Business Architecture Definition

Architectural Business Elements of an Enterprise

The two approaches of defining Business Architecture can be used from the business and formalization perspective. The first approach is based on business value. A commonly known business value is a monetary one. Many believe that this value, including the monetary equivalent of goods, is the only one valued by businesses. Monetary abstraction is very simple and convenient for modeling, measuring and managing; however, in a consumer society we cannot eat bank notes, we cannot wear them, we cannot move on them.

When a new enterprise is established, an Enterprise Business Model – the “business face” of the company – is written. It usually comprises the core business functionality that distinguishes this enterprise from others in the market. Business functionality is the only category that links an enterprise to the 'demand and supply’ factors of a consumer society.

Measuring this link in monetary values only is good for a short-term. Monetary values obfuscate the mechanism of the demand satisfaction and in the long run a company can miss the point where this mechanism should be adjusted to the changed demand. If consumer satisfaction decreases, the company might not lose its revenue yet but it may be too late when the revenue starts dropping – the company’s reputation with the customers may be already damaged some time ago. That is, monetary values are good for measuring but this is not the only one criterion for the business effectiveness.

At the same time, business functionality addresses the core business value of any company in a consumer society. If this functionality satisfies the needs of the consumers, they will bring money to the company. That is, the second approach combines monetary and functionality aspects as the criteria for Business Architecture. If Business Architecture is based on business functionality, it is much more likely that the essence of the corporate business and its strategic goals will fit with the changes in the market.

Talking about Business Architecture I assume that it is an architecture, first of all. I have chosen a definition of architecture formulated in the ISO/IEC/IEEE 42010 1 and extended it as the following: an organization of a system/structure embodied in its fundamental self-sufficient cohesive elements, their relationships to each other and to the environment, and shared principles guiding its design and evolution. As one can see, this definition is free from specifics of business or technology.

With this definition, I challenged several significant business elements of an enterprise including those that are the most frequently attributed to Business Architecture by other authors. The elements analyzed were business strategy, capabilities, financial (revenue/profit) targets, functionality, clients and suppliers, people and business processes, governance structure, business information, organizational structure, and structure of responsibility over economic activities.

Out of the above enumeration, only business functionality and business information have appeared to be

  • Fundamental – an enterprise cannot exist without them and they are irreplaceable
  • Self- sufficient – they are not derived from something else and can exist on their own
  • Cohesive – they are consistent and interrelated
  • Similarly guided – they share the same guiding principles.

That is, those two elements have architectural attributes. Characterizing other enterprise elements, I can briefly say that:

  • Business strategy – is not self- sufficient and may have its own guiding principles different from the principles of other enterprise elements. Business strategy, together with the Enterprise Business Model, constitutes an input and objectives of the Business Architecture. The business strategy is defined and guarded by C-level executives. Business Architecture only contributes into the strategy definition and validates its final version via implementation
  • Business capability – is an implementation of a particular business function or a combination of functions. Business capability is one of the primary outcomes from the Business Architecture realization while the architecture itself addresses only the functionality part of capabilities
  • Financial targets – comprise a structure, not an architecture, because they are not self- sufficient and may be non-cohesive. In essence, the financial structure of an enterprise is derived from several factors that include business functionality, operational and organizational structures, implementation methodologies and technology, and the state of the market
  • Clients and suppliers – are external elements while Business Architecture addresses internal elements of an enterprise; relationships with particular clients and suppliers are inputs in and outcomes from the Business Architecture models. Only types of clients and suppliers are included in architectural models
  • People – are not self-sufficient, may be non-cohesive, replaceable and externalized (outsourced). Business Architecture (models) can exist without people while a realization of the Business Architecture cannot; all implementations of architecture are done by people
  • Business processes – are a form of implementation of business functionality, more accurately – a form of implementation of business services. That is, business processes cannot be architectural elements while functions/services can
  • Governance structure, organization structure, and structure of responsibilities over economic activities – are the major outcomes of Business Architecture implementation; some of them are inputs into Business Architecture as well. If they are out of sync with the Business Architecture decisions and directions, an enterprise has to adjust/modify these implementation elements to avoid troubles in the on-going activities.

Thus, all elements listed above are not architectural while very important to the enterprise. They form an environment where the Business Architecture exists and Business Architects operate. Business Architecture is not everything that is important for the enterprise (not everything in a car is its engine); Business Architecture is a compact entity but impacts everything in the enterprise. 

Subject of Business Architecture

The subject of Business Architecture is defined by the answers to the questions WHY, WHAT, WHO, WHERE and WHEN the enterprise conducts its business. That is, Business Architecture elaborates on the Enterprise Business Model and Business Strategic Plans, transforms them into a functional landscape of the business while the rest of the company works on how this functionality is or should be implemented.

Enterprise Business Architecture is the architecture that comprises business functionality and business informational models, positions itself across the business administrative and organizational enterprise structures, and that transforms goals and objectives described in the Business Enterprise Model and refined in the Strategic Business Plans into the functional and informational definition of the corporate business. This definition of Business Architecture is based on the definition of architecture presented earlier.

The idea of functional architecture is not absolutely new; the modeling language ArchiMate refers to “Business Function Architecture”(BFA) though it is not clear enough. This definition does not distinguish between the architecture and its implementation when saying “The BFA describes the context in which processes are executed, and can be an aid to model and visualise the most important objectives of the organization2. Also, a business “model of organization …describes business processes, data and information, business objectives, critical success factors, organizational structure, information areas, and relations between these parts 2.” In this line of logic, almost everything in the enterprise is a “Business Architecture”.

In contrast, I argue that Business Architecture defines, not describes, only a functional context regardless its implementation while “the most important objectives of the organization” are visualised in the corporate Business Strategic Plan. Moreover, as we discussed already, Business Architecture does not describe “business processes, data and information, business objectives, critical success factors, organizational structure”. All these are the factors of an architecture implementation. Business objectives and critical success factors cannot be a part of an architecture because they are external criteria that the architecture should adhere.

There is M:M ratio between Business Architectures and their implementations. Particular Business Architecture may have several alternative implementations; the opposite is also true. An implementation cannot be used for defining the architecture. An architecture should offer models of functionality, information and operation qualities (such as accessibility, scalability, robustness, security and alike) detailed enough for the implementation. The latter, therefore, starts with the potential solutions in both business and technology domains while treating Business Architecture as a source of requirements.

Business Architecture deals with current and planned functional architectural models. Existing functionality is frequently articulated as business competencies while planned functionality is depicted via business capabilities (i.e. potential abilities to realise certain business function/feature in particular business circumstances). A business competency may include motivational values and current behaviour while a business capability defines what the business could do if specific conditions occur.

A capability is a combination of a business function and its possible (reserved) implementation as shown in Figure 1. Business Architecture defines the combinations of business functions/features for each capability while corporate management defines/reserves implementation details. Nonetheless, business capabilities are just a part of what Business Architects do and what the Business Architecture discipline defines. An enumeration of business functions/features without defined/reserved implementation is valueless. One can define/plan a holiday trip to Seychelles Islands but if all tickets are sold already, the plan is worthless.

Figure 1. Parts of a Business Capability

Described Business Architecture differs from the concept that is utterly based on capabilities, value streams and organization as it is promoted by the Business Architecture Guild (BAG)5. In contrast to BAG, this architecture states that a vision and strategies are inputs into architecture while tactics are implementation means, business capabilities are shared with meanagement and organization is a primary implementing mechanism that does not necessary match the architecture (unfortunately), value streams are results of implementation that also can appear differently from the architectural directions, architectural design projects are separate from the implementation projects, and policies-rules-regulations-metrics-measures are a contribution of architecture into the Governance for others and for itself, i.e. outside of the architecture. Business Architects may be and are involved in all these activities but as a part of the discipline, not as the subject of architecture. That is, BAG is not a new approach and just supports existing practice of mixing architectural models-plans with implementation, i.e. mixing intents with reality. It is well known that depending on business circumstances, value streams and capabilities may or may not materialise, i.e. building the architecture of phantoms is probably not the best way to spend resources.

Moreover, I have found that several BAG principles are contradictive. For example, if “Business architectur’s scope is the scope of the business”, how one can provide for ”Business architecture is reusable” – this totally depends on the “scope of the business”, which may be not reusable at all. Or, if ”Business architecture is not prescriptive”, everyone in an enterprise can do whatever she or he is pleased and Business Architecture simply becomes excessive. The paradigm of Business Architecture presented in this article is prescriptive in a sense it defines the business functionality and an information model that other elements of the enterprise should realise to the best of their abilities.

Every enterprise has its Business Architecture though it may be not formally documented or even perceived. Only business functionality and business informational model jointly form any particular Business Architecture. Other business elements of an enterprise make the architectural solutions happen. These elements influence Business Architecture or are influenced by it but do not construct it.

Consequences of functional Business Architecture

A Business Architecture, which is based on functionality and information, is, in essence, an architecture of services that realize business functionality and provide access to business capabilities. In other words, this Business Architecture leads to the type of a Service-Oriented Enterprise 3, which comprises structures of business services. Such an architecture is capable of linking together the strategic business goals/objectives, revenue, consumer demand and corporate culture4. It also needs certain organisational and operational structures of the company. This architecture transforms an enterprise into a form optimal for the businesses conducted in a highly dynamic external environment.

Service Orientation provides a rapid adoption of changes via business flexibility based on re-composition of business services. Flexibility of business solutions6 cannot be accomplished without the changes in the management and organizational structure of a company demanding them to become flexible as well. A service-oriented nature of Business Architecture appears as the major consolidating factor in an enterprise that is capable to be compliant with social structure, corporate culture, cooperative work of internal business units and external activities in the market.

Business Architecture oriented on services works for enterprises of all types and sizes. Service Orientation delivers the market competitive advantages based on business innovations, business solution integrity, business flexibility and extensibility, and all of these in convergence with the technological scalability, security and manageability.

Business services, which form Business Architecture, are organizational and operational entities that realize certain business functionality via manual and automated means. These entities usually cross from business to IT areas of the company 4. An Information Technology, as one of the forms of implementation of business functionality, plays an important role in optimization of business services. The proper granularity of business services makes their compositions a powerful instrument for addressing the majority of new business tasks and existing problems.

Business services provide the level of abstraction that permits the most comprehensive tactical and strategic business management. They also allow multiple competent and competitive implementations of the Business Architecture. As a result, an effectiveness of cost/value and improvement of Customer Value may be gained via re-arranging the structures of cooperating business services. 

A Few Notes about Business Architecture Discipline

A discipline of Business Architecture bridges between business needs and business capabilities as a means of transforming WHAT into HOW. Since Business Architecture is the resource of requirements for defining business organizational, management and operational structures, Business Architecture discipline requires Business Architects to work in two basic dimensions. First, they define business functional models for the current state of the enterprise and plan functional capabilities for the transition to the strategic state. Second, they assist corporate management in developing business transformations via changes in products, services, organizational and operational structures. Both dimensions contribute in reaching the corporate financial targets. A relationship between the subject and discipline of Business Architecture is shown in Figure 2.

Figure 2. The subject and discipline of Business Architecture

Not everything that Business Architects deal with is Business Architecture. That is, an influence of Business Architecture penetrates many enterprise elements via Business Architecture discipline but these elements are not owned or managed by the Architecture. Business Architects consolidate directives from the C-level Executives with the directions of a Business Strategy Plan and Market Analysis, and transform the directives into business functional components – functions, features, services and products.

Business Architects contribute a great deal to business performance, but they do not define performance or revenue, or any other financial indicators – this is the job of management at all corporate levels. Business Architects design solutions that target certain performance or revenue, but I would not call it performance or revenue modeling. Business performance and revenue may be considered as the leading drivers to such Business Architecture’s qualities as scalability, flexibility, and robustness.

Business Architects define what business solutions and/or tasks the business units should take up to be compliant with a Business Strategy Plan and corporate goals and objectives. These decisions affect or should affect business operational structure, business and technology management structure, business deployment, product strategy and related technology delivery, though which unit does what is defined by the related management.

A Business Architecture discipline requires that certain decision making, which is currently an exclusive privilege of management, would be shared with or delegated to Business Architects. This is why Business Architects ought to be in the high business ranks, like Director or higher, because they have to influence business management of senior and mid-levels.

The work of Business Architects aims to the middle-to-long term gains and benefits. Short-term solutions, which may be characterized as “revenue today regardless of the cost tomorrow” or “tomorrow will be new business”, apparently is more costly and much more risky with the potential that “tomorrow” does not happen for such business. While architectural errors should not be withheld, the violation of architectural solutions attributed to short-term thinking during implementation is a much more frequent situation.

Altogether, a discipline of Business Architecture is a description of primary and secondary duties of the role of Business Architect. A separation between the subject and discipline of Business Architecture allows to distinguish between the architectural model level and its implementation throughout an enterprise 4. This also helps to clarify a separation of responsibilities between Business Architects and the corporate management.

Conclusions

This article discusses the definition of the subject and discipline of Business Architecture, its reasoning and options. The key methods applied are the separation between the architecture subject and discipline and the separation between the architecture and its implementation. Business Architects are those who develop the models of the architecture subject and assist the rest of the company in the models implementation.

In contrast with other approaches to the definition of Business Archtiecture, the article identifies that only business functionality and business information may be considered architectural entities and together form the subject of Business Architecture. The discipline of Business Architecture is a description of what the role of Business Architect has to work on as primary and secondary tasks.

Such definition of Business Architecture places business functionality and realizing it business services – the means of access to business capabilities – into the frontline. Business Architecture based on business services appears as the best model for carrying out the business enterprise model and strategic business goals. It's also capable of integrating the strategic business goals/objectives, revenue, consumer demand and corporate culture. This architecture is suitable for companies of any size in any business domain; it transforms a company into a Service-Oriented Enterprise that is optimal for the businesses conducted in a highly dynamic external environment.

Resources


1Recommended Practice for Architectural Description for Software-Intensive Systems”.  ISO/IEC/IEEE 42010:2011, Systems and software engineering — Architecture description.

2 “Pocket Guide: Enterprise Architecture Management”. BiZZdesign Academy, ISBN: 979-90-809722-4-7. 2011

3 Michael Poulin. “Ladder to SOE”. Trobador Publishing, ISBN 978-1848761-629, 2009.

4 Michael Poulin. “Architects Know What Managers Don’t”. BuTechCon, ISBN 978-0-9575199-0-9, 2013.

5 The Business Architecture Guild’s Web Site may be found here but the majority of its content is accessible to the members only.

6 The method of estimating solution flexibility is described in 4

About the Author

Michael Poulin is Head of Business and Technology Architecture at BuTechCon, a consulting firm based in the UK. He has built up a wealth of experience architecture in both the UK and United States. His work focuses on bridging the gap between business architecture and modern technology. 
Michael provides professional coaching and knowledge exchange and is a member of BCS and IASA.  Michael is actively engaged in the Enterprise Architecture realm having actively contributed in OASIS SOA standards. Michael has also authored various publications including ”Ladder to SOE” and “Architects Know What Managers Don’t”, written multiple articles and blogs and presented at conferences. He can be contacted via michael.poulin@mpoulin.com.

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2013 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT