Topics and rules for the business architecture

The business architecture has become a fashionable word. Like security, everyone has heard and has their own views, but only a very small number of people know what it really means.

This paper discusses the phenomenon of the business architecture with the consideration of subject and rules at the same time. Without knowing the subject of the business architecture, it is difficult to determine the connotation and extension of the business architecture role, such as rules. Many managers and architects would say, "What's wrong with that?" By identifying stakeholders and collecting their views, you can basically define the business architecture. "Unfortunately, this is a huge mistake, and it can lead to a lot of contradictory views."

Proponents of a business architecture defined by stakeholder perspectives subconsciously focus on "what it is" into "what it can do for me," and refer to iso/iec/IEEE 42010 standard ¹ to deal with ideas and ideas. However, this standard warns that views cannot be defined and can only be used to describe topics. We are here to separate the "description" and "Definition" areas. There may be a collection of thousands of descriptions that are not subject to the definition, because all descriptions or views are subjective, in other words, everyone sees what he or she wants to see.

I've noticed that much of the debate in meetings and online discussions about the business architecture is about what the business architecture is, or what it should be, in fact it's another thing. When we define the idea of driving, can we give a definition of the car? No, because driving only has to do with the control of several operations in the car and how they affect how the car moves. In addition, there are driving rules and regulations that can not be found on the vehicle; the exterior and interior of the car can not be seen in its internal structure. If such a simple example can not be solved in a car, how do we feel that stakeholders are more aware of the business architecture than the business architect?

I have introduced a method in this article that allows me to define an enterprise business architecture that is not related to the business domain of the enterprise. As a result, I find that the business architecture is simpler than most people think, and has a more complex relationship with other businesses in the business. I will clarify the reasoning process of this conclusion, while also listing some of the results.

Business Architecture Definition

Enterprise's architectural business elements

A business architecture can be defined from a business and formalized two perspectives. The first approach is based on business value. The value of money is a well-known business value. Many people believe that this value, including the equivalent of a currency commodity, is the only value that business values. The abstraction of monetary value is very simple and easy to model, measure and manage, however, in a consumer society, money cannot be eaten, nor worn, nor taken away.

In the establishment of a new company, to write out the business model, is the company's "business side." It is usually composed of the core business functions of the enterprise, which is the key to differentiate the enterprise from other enterprises in the market. The business function is the only connection between the enterprise and the "supply and demand" factors in the consumption-oriented society.

This connection is somewhat short-sighted only in terms of monetary value. The value of the currency confuses the demand-fulfillment mechanism, and after a long run, the company may miss the key point of adjusting the mechanism to follow demand as demand changes. If customer satisfaction drops, the company's revenue may not be affected for the time being, but it may be too late to wait until the revenue starts to fall, and the company's reputation with its customers may be broken. In other words, monetary value can be used to measure business results, but should not be the only standard.

At the same time, in a consumer-oriented society, business functions can determine the business value of all companies. If this function can meet the needs of consumers, they can help the company to make money. That means the second way is to measure the business structure in terms of currency and function. If the business architecture is based on business functions, the essence and strategic objectives of the company's business are likely to adapt to market changes.

When discussing the business architecture, I first assume that it is a schema. I chose the definition of architecture in iso/iec/IEEE 42010 ¹ and extended it: a system/structure organization is embodied in the cohesive elements that it is basically self-sufficient in, in relation to each other and to the environment, And the shared principles that can guide their design and evolution. As you can see, this definition is not limited to business or technology.

With this definition, I have examined several notable business elements in the enterprise, including those that will be attributed by other authors to the business architecture. The elements I analyze are enterprise strategy, business capability, financial (revenue/profit) objectives, business functions, customers and vendors, people and business processes, governance structures, business information, organizational structure, and the structure responsible for economic activity.

Of the elements listed above, only business functions and business information have the following characteristics:

Fundamentals--a business cannot exist without them, and they are irreplaceable.

Self-sufficiency-they are not derived from other things and can exist independently

Cohesion--they are consistent and interrelated

Guiding similarity--they have the same guiding principles.

That is to say, these two elements are known to have a structured attribute. As for the characteristics of other enterprise elements, I can briefly introduce: