Business Architecture is a burning hot topic these days. I believe it is a key enabler to get us to a more contemporary or new world of Enterprise Architecture (EA). Continuing the shift from an IT centric Enterprise Architecture to a business oriented one. We not only see the evidence by the water cooler but also in the broader community. In the latest Gartner Enterprise Architecture Hype Cycle they classified Business Architecture at nearing the “Peak of Inflated Expectations”. The stated evidenced provided showed:
-
Gartner's Symposium/ITxpo conference (Orlando 2012) saw more than 2,000 people attend Gartner's presentation, "Business Architecture: Uniting Business and IT."
-
A Gartner webinar (April 2013) hosted over 430 attendees.
-
Since early 2012, Gartner's EA research team has taken more than 180 client inquiries from clients pursuing business architecture as part of their overall EA efforts.
This is just Gartner. Other analyst firms such as Forrester has built a flurry of content around Business Architecture as well over the past two years with playbooks, articles and blogs.
I would assert that Business Architecture is the catalyst for the next wave of evolution of Enterprise Architecture. If that’s so, what is it? I will attempt to define it or at least tell you how I’ve been defining it for the past few years.
Business Architecture, An Industry Perspective
Like with most things I go to define, it has often been defined before. Business Architecture is no exception here. I not only did this with how I’ve defined Business Architecture before but also wanted to pull from an updated definitions from around the industry.
While there are quite a few Business Architecture definitions out there, I pulled only the ones that were coming from either influential or credible sources. These few definitions from analyst firms and standards bodies should give you some contrast into what some of these leading organizations define Business Architecture:
- Gartner : "enterprise business architecture" (often called "business architecture") as the EA activities that create deliverables to guide people, process and organizational change in response to disruptive forces and toward desired business outcomes.
- Forrester: An organized and repeatable approach to describe and analyze an organization's business and operating models to support a wide variety of organizational change purposes, from cost reduction and restructuring to process change and transformation.
- TOGAF 9.1: A description of the structure and interaction between the business strategy, organization, functions, business processes, and information needs.
- OMG Business Architecture Working Group: a blueprint of the enterprise that provides a common understanding of the organization and is used to align strategic objectives and tactical demands.
Each one of these definitions have very good qualities and resonate on their own. However, the challenge I have personally is that I don’t think they are inclusive enough for what I see and teach in the market place. The reason I say this is for the following reasons:
- Don't see these definitions being fully representative of what I see from the hundreds of customers I have visited in the past 5 years
- None are comprehensive nor clear enough the I could explain to an executive or a novice
- Some of these definitions predicate that business architecture is a stand alone discipline which I fundamentally disagree with.
- Lastly, the definitions are just all over the map. Some describe it as the output, some as the process while others dictate a certain outcome
A Definition for Business Architecture
For me, I have a very specific Business Architecture frame of reference for what I believe business architecture is based on. This is through my experience working with customers that have leading Business Architecture practices, my personal experience building out Enterprise Architecture practices and the workshops in which I teach EA’s about Business Architecture.
In my post, “Australian And New Zealand Architects Surveyed On Business Architecture”, I talk about how Business Architecture boils down to rationalizing the "Why" part of the question into a set of usable things that we can execute on. For me it’s that simple.
The definition I have been using for some time now with customers is the following:
A formal method and a set of descriptions that distill the business environment and the needs of a business into set of models representing business information, concepts, value and risk that are expressed through an architectural view of a business.
With this definition I wanted to be inclusive of all aspects of business architecture. I found most descriptions or definitions are too narrow or prescribe a particular outcome. I believe that business architecture is a means to an end not the entire solution all unto itself. Business Architecture is a critical part of Enterprise Architecture, ensuring all of the EA oriented in a way to maximize value.
As you may of noticed, I have highlighted certain words. For the rest of this post I will go through the highlighted words in the definition in an attempt to explain each on independently to show how they relate and describe Business Architecture.
So lets start decomposing the the definition.
#1. Operates within Enterprise Architecture [Implied]
While not stated in the actual definition, it is implied that business architecture is a domain within Enterprise Architecture.
Business Architecture on it’s own only provides a small subset of a complete solution. For example, only understanding a business model doesn’t get your stakeholders any closer to defining a solution to a problem or opportunity. It’s when you bring in the macro level EA methods combined with the other domains of architecture where you really see the power behind business architecture.
From an industry perspective, there is a tendency to try to make business architecture an independent framework.
This approach is very dangerous.
There are many motivations for this, some I believe are the right motivations but the implementation in my honest opinion are very wrong. I think so of this stems from a misunderstanding of the intent of Enterprise Architecture. The challenge comes in when we mix the current state environment in which some organization implement EA or lack there of and the definition of EA from the EA standards community.
As an example, I was digging through my personal archives of content and found a TOGAF 7.0 overview deck from the Open Group. I was surprise to see, even then a business outcome focus from the EA community. Note however, there was not a whole lot of guidance around this until 9.0 but the intent and direction was clearly stated from the very early days of the TOGAF standard.
This topic can go on for awhile and most certainly warrants more decomposition of the current state, so keep us on point here I will be writing more about this in another post.
#2. A Formal Method
With most definitions that I harvested over the years, I see business architecture as a thing you produce. If we examine both the Gartner and Forrester definitions, they call it out as a very specific set of approaches to Business Architecture.
IBM also states it really well with this explanation in an IBM whitepaper entitled, “Actionable Business Architecture: An IBM Approach”:
[Business Architecture] Methods are techniques that weave through the various contexts using proven methods… [Business Architecture] Methods should also describe the how-to of execution while enabling further integration into an Enterprise Architecture (EA) context method.
I believe that Business Architecture isn’t a deliverable but rather a discipline within Enterprise Architecture that has a set of methods, roles and artifacts that serve to solve a very specific part of a problem. Arguably the most important aspect, the context into why we are doing an activity along with ensuring what is delivered ultimately provides the most benefit back to the company.
The challenge I have with some interpretations of Business Architecture is that it is either implied or explicitly defined that a specific artifact is the results of Business Architecture. The OMG definition is a good example of this with stating, ”blueprint of the enterprise”.
The problem with this is that this is really meaningless with out some purpose. To what end does this blueprint serve. You could also replace that with business capability model and have the same questions. What I sometimes find and advise against to my clients, EA’s should not pivot there work off a specific artifact or deliverable. Focus on the outcome you wish to achieve and work through a proven method to generate a consistent result solving that problem.
Without a method you will find yourself generating artifacts for artifact sake, while sometimes we get lucky, we know that hasn’t yielded effective results.
#3 Distilling a Business
As mentioned above, a big component of business architecture is to distill and rationalize a business. What does this mean? Simply put, let’s understand what the business wants by putting their needs and wants into a set of constructs that us as architects can understand and facilitate the decision making process.
While this is a simple concept, it is very important tone setting statement. Business Architecture does not create business strategy but rather it serves to understand it. There is a very clear divide in the industry here. I believe it is the case here based on the evidence I see in the industry along with other thought leaders in this space. Here is why I don’t think Business Architecture
Is there a role for Business Architecture in creation of strategy? Yes. But it should be leveraged as a tool to enrich the basis for the corporate or business unit strategy not as the defining method.
So lets take a look at what two primary aspects are distilled.
#3a Business Environment
This aspect is one in which that is easily overlooked because it can be seem that it so far away from solving the actual problem. Sometimes it is but more times than not this aspect is vital to making the right decisions.
Here we are looking at the surrounding business environment of the problem that is to be solved with Business Architecture. Meaning everything around the company which can include an inwards view but mostly an outwardly view.
This can includes but not limited to the analysis of:
- Regulatory Environment
- Competitive Landscape
- Corporation Health, Financials, Market Standing
- Economic Condition (Local, Regional, Country, etc.)
- Geopolitical Conditions
- Pandemic Considerations
- Likelihood of Natural Disaster
The list of areas to include in understanding a business environment are vital to how we as Enterprise Architects build our solutions. You maybe asking why these are so important. Or maybe you are wounding why are things like pandemic or natural disaster included here. Let me give you an example.
Lets rewind to Katrina in 2005 and look at the challenges from the banking industry. When this horrible disaster hit, banking locations were closed for weeks. If you were a small bank you might have your entire business and IT environments in the impacted area. Understanding these conditions are important so that you can plan accordingly. Meaning you architect for these considerations.
This was one small example, but for global organizations operating in many different countries with different considerations we can understand those to provide an optimal solution for our businesses.
#3b Needs of a Business
This one is fairly broad but meant to be. Often times you see Business Architecture defined as taking in strategy and doing something with it. While I think this is certainly one use case but I don’t think it is the only one.
The reason for simply saying “needs of the business” is to be purposefully that broad. It shouldn’t matter what comes into the Enterprise Architecture process, all of it should be understood from a business perspective. Even if that thing is a great new technology trend like wearable technologies. We would still want to understand the business implications and opportunities it presents to a business regardless if it comes through the technology architecture domain.
In this definition “needs of the business” is a way to define what ever the business wants. We don’t want to be prescriptive here as it would lead us down one specific path. These needs are usually through one or more of the following:
- Enabling the business through:
- Strategic planning
- Major business transformation activities
- M&A support
- Value management
- Creating architectures that support initiatives or programs
- Managing the Enterprise Portfolio
- Change Management
#4 Business Information
This is the first type of output defined here in the Business Architecture definition is business information.
Lets take a small step back and understand what we mean by information. I don’t mean data. Data is context-less raw facts about things, while information is much broader and has an important element, meaning. You can see a visual this represented in the visual from Barry Ritholtz’s blog post entitled, “Intelligence Hierarchy: Data, Information, Knowledge, Wisdom”. Keep in mind this post wasn’t from the vantage point of an EA but nevertheless he does a good job articulating the difference between data and information.
A growing trend in today’s economy is that goods and services are starting to serve as an end to the real currency, which is information and/or intellectual property. From a business architecture perspective information is a key element of understanding where the business was and wants to be.
Below is an example of some of the ways information provides a meaningful Business Architecture:
- Identifies the business information entities required to enable a business architecture
- References an enterprise data model for a clear definition of what business terms mean such as customer or product.
- Classifies information into segments for better understanding and usage within a solution
- Provides facts on market place.
- Prescribes a large part of a business process by defining the information in which it is facilitation the flow of.
#5 Business concepts
The term used here is another broad but purposely broad term. It is meant to encompass all the business concepts we want to articulate for our business architecture. There are quite a few of them so the rational for using business concepts rather than naming 20 different business “things” was to not be prescriptive. Also I am sure there would be some left as well.
So here we want to identify a category of business oriented concepts that would involve modeling all the different aspects of a business. This could include but limited to the following:
- Customers
- Products
- Entitlements
- Goods and Services
- Competition
- Drivers, forces or motivations
- External relationships
- Capabilities and processes
By examining these aspects along with their relationships we can understand the needs of a business better along with creating a model for realizing value.
#6 Business Value
Enterprise Architecture is a methodology that is business value driven. Business Architecture as a key domain within it inherits this position as well. An outcome of this and any architectural process should be defined and a model for maximizing value for a business. Business Architecture is square in the middle of taking a business case that was (or wasn’t) defined and ensuring it can be quantified and qualified.
In Business Architecture we identify, define and quantify value that will serve as the basis for all other architectural work.
Through leveraging value and benefits management techniques we can properly. This is much like a traditional financial analysis that would include the valuation of existing investments and the forecasting of new opportunities. Through this process it’s important to use models that either resonate with your business or are common in the financial industry.
Examples of value models include:
- Value Chain
- Benefit Dependency Network
- Value System
- Value Network
Those models will help you understand a broader value picture. Additional models that can be used as inputs into these are:
- Risk Adjusted Value (RAV)
- Net Present Value (NPV)
- Total Cost of Ownership (TCO)
- Return on Investment (ROI)
- Cost Benefit Analysis (CBA)
Business Architecture not only models value but also determines how value can be maximized. This is one of the benefits that Enterprise Architecture can deliver. It can identify new opportunities not seen before by business stakeholders.
#7 Business Risk
We just looked at value and understanding benefits but there was one aspect not covered within it, risk. Understanding value has two facets, benefit and risk. Understanding risk within Business Architecture allows us to do the following:
- Take a business centric approach to understanding threats
- Identify potential harmful risks to the company
- Classify business information in an informed way
- Qualify or disqualify potential solutions
- Understand risk the risk tolerance of the corporation or a specific business unit
- Examine readiness factors such as organizational and technical readiness.
Through the usage of risk management techniques within Business Architecture we will be able to identify, assess, and prioritize business risk to ensure that risk is well understood and managed throughout the architecting process.
Through this quantification we should use standard risk methods such as:
- Risk assessments using a composite risk index
- Risk options matrix
- Risk mitigation plan
#8 An architectural view of the business
This aspect of the definition addresses another key debate in the industry. It is perhaps the most important mental framing concepts of the definition. I often hear Business Architecture described in one of two ways.
- Business Architecture creates business strategy
- Business Architecture is a method in which Enterprise Architects can rationalize the needs of a business so that it can be executed upon.
Based on the rest of this post you can see where we are going here. In my definition of Business Architecture we are looking at a business need through the lens of an architect. This means that we create models that we can use through the architecting process. They are not:
- In 100% business only language
- entirely describing business planning or strategy activities as performed by a business planner or corporate strategy.
With this said, Business Architecture should be presentable to business unit leaders (as with most architecture artifacts) which the artifacts and models created should lend from the business world primarily but not at the expense of architecting.
Conclusion
I hope this definition of Business Architecture has been helpful or enlightening. However, given the wide variety of definitions in the industry I am afraid not everyone will agree. I hope to hear from you on whether this definition of Business Architecture resonates or not.