Business Architecture: The tool for strategic decision making

Featured
15069 Views
6 Comments
39 Likes

As budgets tighten and organizations continue trying to achieve return on investment faster, cheaper and with better results, they are trying to create and evolve their overall enterprise architecture. There are several components of enterprise architecture which are as follows:

  • Business Architecture
  • Information Architecture
  • Application Architecture
  • Technology Architecture
  • Security Architecture

What is the Business Architecture?

The purpose of the business architecture is to provide a unified structure and context from which to do further analysis to understand the high level functions of an organization, and to ultimately guide decision making. The business architecture provides the ability to make decisions around what the priorities of the organization are, how the project portfolio should be aligned and even the ability to do an application assessment by functional area.

The benefits organizations can achieve through the creation and evolution of their business architecture are:

  • Common frame of reference of the organization and its core functions.
  • Documents fundamentally what the business does.
  • Provides a roadmap (i.e. provides a high level view of the organization from which to create and/or evolve a plan). The plan can be around how to grow the business, what functional areas to focus on, where to invest technology dollars, etc.
  • Provides a view of the business independent of organizational structure, project teams, systems and data. This view allows unbiased analysis and evaluation.


Creating the Business Architecture

The first step in creating your business architecture is to conduct highly structured facilitated sessions with members of the senior leadership team and subject matter experts. It is critically important to have multiple viewpoints and perspectives involved.

It is also important to have a highly skilled facilitator lead the session and for everyone to have an understanding of what the final deliverable is.

The final deliverable should be a visual representation of what the business does independent of organizational charts, project teams, and systems. Everyone should have the ability to look at the visual representation and see themselves in it.

The visual representation can take many forms, but the critical point is it accurately represents what the business does.

Evolving the Business Architecture

Once the initial version of the business architecture is completed, you can begin to use it for a variety of purposes. Most organizations utilize it to do further decompositions of specific functions, to gain a depth of understanding of the business, and to identify potential redundancies/overlaps.
You can learn a tremendous amount about the organization by going through the process of functional decomposition.

What is functional decomposition?

  • Breaking down the high level function into sub-functions
  • Understanding all the sub-processes that support the high level process / function
  • Documenting functions independent of sequence

The reason it is important to go through the process of decomposition is to get people to focus on the essential business processes performed within a high level function irrespective of organizational structures, project teams and applications.

This is a purposeful effort to get individuals away from terms like “my department”, “my team” and “my system”. The primary purpose of this activity is allow for analysis and evaluation regarding what the organization should be doing, where the organization should be making investments, and evaluating where there is possible redundancy of both process and data. Many times when people are focused on “their area”, “their department” and “their system”, they are not thinking outside of the box or creatively in the context of what is best for the organization.

What are the outputs?

Once you have created the functional decomposition, there are many paths you can take depending on what you are trying to achieve.

If you want to do further analysis of the process, you can create high level process flows for specific functions.

If you want to begin to understand the information flow, you can identify the inputs and outputs of a specific function.

If you want to understand the high level business processes for a specific business area, you can create high level business use case diagrams.

If you want to analyze your applications, you can overlap the business architecture with the applications.

It is important to note, no matter what you are looking to understand there is a significant piece of analysis at every step in the process. The analysis is the part that will equip you with the knowledge you are looking for to empower strategic decision making.

Who can accomplish this activity within your organization?

Some may be asking why an expert in business analysis is writing a white paper about business architecture; don’t the architects do that?

The answer is: sometimes. In many organizations, architects still struggle with the business architecture piece. They are adept at the information and application architecture but they have been IT solution focused for so long, it’s hard to focus solely on the business. Particularly, creating a visual representation of what the business does fundamentally. This is a level of abstraction most architects are not accustomed to.

Business analysts are uniquely positioned to help create and evolve the Business Architecture because they are simply repurposing a skill set they already have.

One of the guiding principles of any business analyst is – understand the business need / business problem first. It has always been our role to keep the developers from jumping right to the solution without first understanding the problem. The same is true with creating a business architecture; You have to understand and document the business first.

As the title implies, we know how to analyze. This is a very helpful skill when going through the exercise of creating a business architecture. Business analysts will ask probing questions and won’t stop asking why until they truly understand. It is fundamental to what we do. You need a resource with the ability to push past the “because we’ve always done it that way”. At a strategic level, it is amazing what you will learn.

We have the ability to bring together multiple groups of people and help them reach consensus. We have a knack for making sure everyone feels heard and then making a recommendation for compromise.

To create perfect harmony, the business analyst and architect should collaborate to create and evolve a robust picture of the enterprise architecture.

Author: Kimberly Terribile is a CBAP® recipient with extensive expertise in business analysis education and mentoring. She currently serves as the Director of Product Development for B2T Training.

Like this article:
  39 members liked this article
Featured
15069 Views
6 Comments
39 Likes

COMMENTS

harris.lloydlevy posted on Thursday, March 5, 2009 4:18 PM
Great Article!

When you take all of these business functions you've created you can start populating them with the Elementary Business Processes that are contained within them. This makes the Bus. Arch. a great tool for defining Scope, Traceability, and Impact.

By putting a well-defined concrete action that be be linked back to a particular group, and/or system you make sure that your project are well grounded in your business architecture and you can perform some great tracing.

If you put the responsibility for defining and updating EBPs with projects, and Functions with Architecture it also keeps you aligned, and keeps your Architecture updated as project evolve.

It's your EBPs rather than functions that give you a concrete well-defined thing that both Business and IT can talk to.

Because your so very very right that the "Architects" in most organisations consider the Business Architecture as an after thought if they consider it at all.

Harris Lloyd-Levy
Senior BA - Oakton
http://consultnik.blogspot.com/
jfrano posted on Monday, March 9, 2009 9:02 AM
A terrific article--a lot of good information in a 'small amount' of space.

Jack Frano, PMP
Principal--Adaptive Growth, Inc
www.adaptivegrowth.com
Anonymous posted on Monday, March 9, 2009 7:17 PM
You need a resource with the ability to push past the “because we’ve always done it that way”.

Yes, yes, yes .. couldn't agree more. This one of the toughest skills to learn as an analyst. It is so difficult to get a SME to admit that they don't actually know why it is done this way. They will come up with any number of excuses not to give you the real answer.

Les.
Firerat posted on Monday, March 9, 2009 9:09 PM

First of all let me admit that I am a very biased person. A number of my bias are the result of many years of wandering through the business wilderness.

To me the terms Business Architecture, Information Architecture, Application architecture, Technology Architecture and Security Architecture are so general in nature that they convey almost no meaning. It’s like saying I’m an Engineer. Well what kind, there are many different kinds. Probably the only common bond between them is mathematics. Moreover, if one says they are a Business Architect. What kind of business? It seems to me that the skills to architect an accounting firm are much different than that an oil company.

The above suggests to me that one skill does not fit all. Accordingly, I would assert the same problem exists for an analyst. It seems to me that to architect or analyze a business many different types of skills are required and the practitioner of these skills should reside in the area that utilizes these skills. What ever the skills, clearly there is a limit to understanding not only ones own skill set but the skills of others.

Business also resides in a dynamic environment. This brings up another problem. This is sometimes known as the three part lag. A problem occurs, how long before the problem is noticed, how do we fix the problem, did the fix work? Remind you of any of our current economic problems? I would also note that predicting the future appears to be problematic at best.

There are three over used terms that I hate; Architect/Architecture, Analyst and Optimal. Oh, I forgot Engineer, (may states prohibit using the title of engineer unless you are a registered professional Engineer licensed by the state) Engineering and thinking outside the box (the old 9 dot problem.)

Perhaps the following will help explain some of my biases. Many years ago I worked as an electrical engineer specializing missile guidance and flight control systems. Later I picked up and MBA as well as the required number of hours for a BS in accounting. This led to a position as CFO of several Architectural and Engineering firms.

firerat
JohnIMM posted on Saturday, March 14, 2009 9:33 PM
Good business analysts can operate successfully in almost any business environment. To do so however, they must have the proper analysis and modeling skills and must use effective modeling techniques.

A good architect, using high quality methods and techniques, can plan a skyscraper, a house, an hotel, a factory or anything else he/she can envisage.

They do not pretend to be structural engineers, or production engineers. They are architects.

Likewise, with analysts, they should never be business experts. This is a mistake many of them make. They see themselves as the business expert and do their analysis based on this. Good analysts may know a lot about a business but they ALWAYS elicit from the business experts the information they need to model that business.

Over the years I have developed a set of modeling techniques and brought them together in the Integrated Modeling Method. I have used this to model oil companies, finance institutes, railway companies, cider makers and lots lots more.

I have always achieved high quality results. Because I have brought my analysis expertise and combined it with the existing business expertise.

JohnIMM posted on Saturday, March 14, 2009 9:35 PM
Forgot to say you can read more on then Integrated Modeling Method at http://www.integrated-modeling-method.com

John Owens
Only registered users may post comments.




Latest Articles


Featured Digital Library Resources 
Copyright 2006-2015 by Modern Analyst Media LLC