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 While not stated in the actual definition, it is implied that business architecture is a domain within Enterprise Architecture.
This approach is very dangerous. Th ere 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.
Methods are techniques that weave through the various contexts using proven methods… 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
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
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.
Comentários