Explaining

Archived Posts from this Category

December 22, 2008

Business Architecture

Posted by Zahavi under Explaining | Tags: |
Leave a Comment 

What is business architecture? Given recent discussions at the OMG business architecture working group it seems there isn’t quite a consensus on the definition as yet. Some think there is overlap between business architecture and enterprise architecture. A business architecture can be part of an enterprise architecture, but many enterprise architectures focus on technology and only recently organizations have begun to look at enterprise level and cross business-unit business architectures.

Some think that a business architecture is about how the business is performed, its business model and structure. For example, whether a chain of restaurants is company owned or franchise owned.

Some think it is a description of how the various specific business models relate to each other. They believe the various models, such as business process models and business motivation models comprise components or layers of an overall business architecture. Some think it is a list of the specific standards themselves. Standards such as the Business Motivation Model (BMM) and Business Process Modeling Notation (BPMN.)

We named our book business modeling instead of business architecture specifically because of this confusion. The word architecture itself is often perceived to be technical by business people and does not resonate with them. But the term will be used by others so it is important to understand how it fits.

I think the purpose of a business architecture is somewhat analogous to a technical architecture. A technical architecture describes how a solution or system behaves and how it is structured. Specific architectural frameworks (such as TOGAF) describe how to organize an architecture (such as its layers and views) and which standards are applicable.

Similarly, a business architecture should capture how the business behaves and how it is structured. This information is captured using various business models but a set of business architectural frameworks should be the ones that define how particular models relate to each other, what their touch points are, and what standards might be used as part of the architecture. The OMG could produce such an architectural framework to support the creation of business architectures.

For example, the OMG has tried several times in the past to define an organizational structure or organization modeling standard. Such a model seems to be a basic model that is needed in business modeling and we describe it in our book as a separate modeling discipline. Yet, OMG has not been able to standardize an organization modeling standard on its own. Several other OMG business standards reference or require some form of an organization model. Should the definition of an organization be defined as part of those standards? If we do that how will we ensure that there is consistency and alignment between all of those definitions of an organization? This should be the purpose of the business architecture framework, to ensure such alignment occurs.

In the March 2009 OMG meeting in Washington D.C., the business architecture working group will attempt to reach a consensus on the definition of a business architecture and on its components. The group decided to start by identifying the overall categories that make up a business architecture and then drill down into the specific sub-components and standards that support them.

This is exactly the approach that we took in describing, what we called, the modeling disciplines. We named four: the business motivation models, the business process models, the business organization models, and the business rule models. With these as a starting point, it is much easier to identify the relationship between the various models and the applicable standards that support them. Once an architecture framework is created that identifies the components and modeling standards that support them, it will be possible to create business architectures based on the framework.

 

November 28, 2008

Golf and frisbee: a common misconception

Posted by bridgeland under Explaining
Leave a Comment 

Most business people do not create business models. They design software or they manage sales accounts or they are responsible for regulatory compliance, but they do not create business models. Fewerthan 1% of business people create business models of the sorts we describe in the book. Even if you expand the definition of business model to include financial models and accounting models, even then fewer than 5% of all business professionals are modelers. As a business modeler, I work with a few other modelers and many nonmodelers. Most of my business interactions are with nonmodelers.

Nonmodelers share a common misconception about business modeling. They think some situations are amenable to modeling and other situations are not. They think business models apply to a small and limited domain and that most of the problems they encounter are outside of that domain. They say “Of course you cannot model that human behavior of people undercutting their colleagues as they compete for scarce internal investment.”  Or they ask whether colleague competition for internal investment is modelable. Or worst of all, they simply assume that it is not modelable, that models apply elsewhere perhaps but not to what they are doing.  They see business modeling as like golf, only to be played in special designated courses, and not playable elsewhere.

They are wrong. Business modeling is like Frisbee, playable everywhere, on greens, on a sidewalk, on a street, or in the snow. You can model any business situation. There are no domains of modelable and not modelable. Everything is modelable. The answer is always yes.

Why does this common misconception exist? Why do nonmodelers assume that business modeling is like golf and not like Frisbee? One reason for the golf assumption is perhaps lack of knowledge. Nonmodelers do not understand business modeling (of course) and so do not know the extent that can be modeled.

Perhaps the golf assumption is also due to the human tendency to exaggerate the importance of one’s own knowledge. “Those domains over there may be amenable to modeling, but my own specialization is far too complex.” When working with subject matter experts, I often see this peculiar combination of arrogance and fear. They are both arrogant in their assumptions about the complexity of their own field, and fearful that what they know can in fact be reduced to some digital models.

Of course some situations are not amenable to business process modeling. They don’t involve business processes, or at least they do not involve business processes in any important way. Last year, Ron and I worked with a third modeler, Varun Panchapakesan to analyze an existing IT desktop support operation. Our job was to take costs out, to determine how the same quality of service could be provided to customers at a lower cost. Our initial plan was to model the business process of desktop support, and then redesign it, implementing a cheaper process that accomplishes the same result. But as we dug into the problem, we discovered that the business process was very simple. Someone calls the service desk with an issue with their desktop computer, an “incident”. The incident is either solved on the first call or it is escalated to tier 2. They either solve the incident on the phone, dispatch someone to solve it in person, or it is escalated to a tier 3 specialist. And tier 3 solves the vast majority of the incidents that reach them.

We could model the business processes of this desktop support operation, but modeling the processes would not help us remove costs. Instead we modeled the mix of incidents, what kinds of problems the users actually see, and how the mix of incidents would change with different interventions. We built a motivation model, creating causal loop diagrams and a simple system dynamics simulation.

The issue is never whether a business situation can be modeled. It can always be modeled. The answer is always yes.

You can always play Frisbee, even in the snow.