What is Business Architecture? Part 2

By Allen Brown, President and CEO, The Open Group

I recently wrote that I had heard and read the opinions of a number of people about what is Business Architecture, as I am sure many of us have but I wanted to understand it from the perspective of people who actually had Business Architect in their job title.  So I wrote to 183 people in Australia and New Zealand and asked them.

The initial summary (blog) of the responses I received was focused on the feedback from Business Architects who were employed by organizations I think of as consumers; this one is focused on the feedback from consultants, ranging from those who are working on their own to others who are working with some of the largest consulting firms that we know.

Why I chose the countries I did and the questions I asked are contained in that earlier blog.

Again the responses have been amazing and thank you to everyone who took the time to do so.  They included some wonderful insights into their role and into their beliefs with respect to Business Architecture.

Summarizing the feedback from the consultants is even more difficult than that of the consumers.  Understandably, each of them has their own approach.  I have found it very difficult to decide what to leave out in order to get this down to a reasonable length for a blog.

It is important to repeat that I am still in the process of seeking to understand, so I would be really pleased to hear from anyone who has such a role, to correct any misunderstandings I might have or erroneous conclusions I may have drawn.

The first point of note from the responses is that Business Architecture is still evolving and finding its place in the enterprise.  While the consumers saw it as somewhere between immature and missing in action, the consultants tended to look at the how and why of its evolution.  In one case the view was that Business Architecture is evolving in response to a demand for greater business oriented control over transformation, while another reported, disappointedly, that business architecture is often seen as Business Process Review/Improvement on steroids.  Other comments included:

• Generally Business Architecture is seen as business process review and/or business process improvement. There is not much real Business Architecture going on at the moment.
• It is not widely understood at this point in time.  This first initiative will be conducted in a lightweight manner to gain the business buy in and get some projects onto the roadmap.  Delivery time will be a key factor in prioritization as we will be looking for some projects with shorter duration and lower complexity so some tangible benefits can be realized
• It is not formally recognized.  Last year I was in the supply chain team (who also deal with Lean and other operational improvement skills).  We have Business Analysts, and a People and Change Team.  We have several areas than do Operating Models.  To me various elements of these would be included under the Business Architecture banner.

In common with the consumer viewpoint, the focus of Business Architecture is on the “What”.  Some of the comments included:

• The Business Architecture will exist with or without technology, but as soon as technology is involved, the technology exists to service the business architecture, and the business architecture should be the input to the technology and application architecture.
• Make recommendations of what projects the business should perform, in addition to relevant and timely corrections to the governance structure, business processes, and the structure of business information
• The business architecture I am referring to is not the traditional element of the IT based Enterprise Architecture, but a framework that is totally business oriented and in which the whole business, including IT, can commit to in order to truly understand their problems and most of all the potential to genuinely improve the business.
• “Business Architecture is not about telling people how to do their job at a detail level. Its function is to help us all to understand how together we can achieve the business goals and objectives
• The primary focus of the Business Architect includes the analysis of business motivations and business operations, through the use of business analysis frameworks and related networks that link these aspects of the enterprise together. The Business Architect works to develop an integrated view of the business unit, in the context of the enterprise, using a repeatable approach, cohesive framework, and available industry standard techniques.

In some cases the focus of activity was the entire enterprise: the CEO view.  In others it was at the line of business or business unit level.  In all cases the focus was very much on the business issues:

• Strategy
• Business goals, objectives and drivers
• Business operating model
• Organization structure
• Functions, roles, actors
• Business processes
• Key data elements

Being able to see the big picture and have the ability to communicate with key stakeholders was emphasized time and again.

• Make it relevant and “makes sense” to senior management, operations and IT groups.  Visualize problems; have a way to communicate with the business team
• Be able to relate – what big decision we need to make and to package it up so that execs can make a decision
• The only person who cares about the whole picture is the CEO.  BA provides the CEO with a one page picture of the whole enterprise in a logical fashion
• Show the CEO where impact is on a page – give confidence – control.  Help him make decisions around priorities.
• The secret of good architecture is taking all the complexity and presenting it in a simplistic way that anyone can understand on a ‘need to know’ basis and quickly find the right answer to the current and/or planned state of business components.
• BA facilitates strategic consistency with the business.  Where do we need to differentiate more than others?  How do we build in once or move to one instance?
• Drive prioritization of when to invest based on the businesses strategic goals
• Distil, communicate and relate to a business person
• A key purpose of this new business driven architecture is to provide the means for communicating and controlling the strategic and operational intentions of the business in a way that is easy to understand for everyone in the organization

A common feature in the feedback is that underneath the models the information is rich – enables drill down – traceability to underlying requirements linked to the requirements.

Two areas of activity stood out the most: Capabilities and Value Streams.  Both of these are focused on WHAT a company needs to be able to do to execute its business strategy and to bring a product or service to a consumer.  Comments included:

• Capabilities – combination of people, process and technology to deliver product features
• Logical building blocks – gather information and compare the level of maturity in each capability, compare with others, understand where could we go to
• Define/ champion 1 common reference model / capability model / logical building blocks of the enterprise.
• Establish Capability, Information maps, Value Streams, stages and business processes.
• Have intimate knowledge of the Business Capability (As Is/To Be), Business Component Structure, Business Processes, Value Streams and Conceptual Business Models.
• Have the capability picture
• … not only the capability of each component but also the relationship between components from every appropriate perspective (purpose, technical, compliance, risk, acceptability, etc.)
• The Business Architecture is the first stage in a broader EA initiative.  Subsequent phases will align capabilities to applications and look at the major data flows between those applications

Since value stream mapping is a lean manufacturing technique, lean techniques are also called out as being relevant to business architecture because they identify areas of waste, which often change work processes or procedures, which may or may not impact applications and technology.  Feedback included:

• Each value steam has Inputs (that triggers the value stream) and Outputs (the value based result of completing the business activities).
• Each value stream is designed against Critical Success Factors, founded on the strategic intentions and priorities of the business, that represent the required business performance with Time, Cost, Quality, Risk and Compliance.
  • Time – How long the process should take from a Customer Perspective
  • Cost – How much the process should cost, measured using for example TDABC (Time Driven Activity Based Costing)
  • Quality – A statement clearly describing the (fit for) purpose of the activity
  • Risk – The protected acceptable residual risk involved due to effective control within the proposed design
  • Compliance – The specific interpreted requirements placed on the activity by interpreting the obligations of associated legislation and regulations.
  • Value streams are directed or informed by policies, plans, procedures, governance, regulations, business rules and other guidance, and are enabled by roles, IT Systems and other resources that will directly or indirectly support their completion.
  • The As-Is Architecture consists of the related value streams, indicating how the business is currently performing.   Under the facilitation of the business architect, design teams investigate how these can be improved to produce the Target State version of the Value Stream.

It was argued that displaying the relationship between the guidance, the enablers and the value streams, opens up the potential to discuss many things related to the business performance; that this alignment is critical for ensuring the business functions operate as expected; and that this is the major feature of business architecture and provides answers to so many previously unanswered questions for business managers.

Incidentally, since value stream maps are often drawn by hand in pencil (to keep the mapping process real-time, simple and iterative by allowing for simple correction) this tends to reinforce the comment by one of the consumer respondents that his most useful tools are pencil and paper.

The role and relationship of Business Architects, Business Analysts and other folk that might come under the general heading of Enterprise Architecture, varied from one organization to another, often seemingly dependent upon the size of the consulting firm.  At different ends of the spectrum were:

• To a greater or lesser extent, Business Architects are supported by Business Analysts (“the knowledge processing factory) and by people with deep skills in design and process, Lean, 6 Sigma, HR, organization design and training.  The Business Architects ensure that all of the pieces fit together in a logical manor and that the impact can be shown in dollar terms
• The Enterprise Architect is a person who can perform as both Solution Architect (SA) and a Business Architect (as needed) and has some ability as an Information Architect. In addition, an EA can perform at an enterprise level, something that is NOT required of either an SA or BA

The feedback on the title of Enterprise Architect was as varied as the number of responses.  The comments included:

• Enterprise Architecture seen as a bad word
• With hindsight, referring to it as architecture was a mistake
• Enterprise Architecture is an IT version of technical specifications and drawings and not architecture, as such, and Enterprise Architects are mainly focused on the Application and Technology areas.
• I think the technology story wave is coming to an end.  The focus will be more on the BusArch and InfoArch as that is where, in my view, the business IP sits. In the future more Bus/Info architects will become Enterprise WIDE architects, not so much enterprise architects

In most cases but not all, there is no such job as an Enterprise Architect.  It is in instead the overall term for Business Architects, Solution Architects, Information Architects, Value architects, Journey architects and so on.

The key differences that were highlighted between the roles of Business Architect and Enterprise Architect was a matter of depth and potentially also of education:

• Enterprise Architects will tend to have more depth in technology; Business Architects will tend to have more depth in business techniques
• Enterprise Architects will tend to have a Computer Science degree, or similar; Business Architects will tend to have a business degree or experience.

It was also stated that Business Architecture is a logical growth path for an experienced Business Analyst provided they get an Enterprise level understanding of the Business and Architecture.

When I actually look at the background of the respondents, I can see experience in:

• IT consulting
• Operations management
• Product management
• Project management
• Business Analyst
• Aeronautical Engineering
• Logistics
• … and much more besides

and education backgrounds are similarly varied.

The common theme is a deep interest in the business issues and what makes organizations work.

The evolution of Business Architecture clearly has a long way to go and depends upon the ability of the practitioners to relate to the business leaders.  One respondent predicted a shift and a segmentation in these comments:

• For business that serve the “mum and dads”. I believe you will see a grouping of the different architectures based upon the business objectives and capabilities.
• I think the technology story wave is coming to an end.  The focus will be more on the BusArch and InfoArch as that is where, in my view, the business IP sits. Applications and Technologies are all COTS nowadays (unless you are developing them). I think in the future more Bus/Info architects will become Enterprise WIDE Architects, not so much Enterprise Architects

The last word goes to the feedback that one Business Architect reported:

“In my time with this amazing new methodology I have had two separate reactions that stand out:

The first from an Acting CEO that was one of the biggest sceptics when I started the initiative and in admitting he had been, said that he owed me a big apology that he found the Business Architecture to be both highly useful and quite remarkable.

The second was in relation to a BPO initiative for a long standing traditional finance industry organization, when the chairman of the board said it [Business Architecture] had made a major decision relatively easy, that would have otherwise been one of the most difficult in the company‘s history.”

Allen Brown is President and CEO, The Open Group – a global consortium that enables the achievement of business objectives through IT standards.  For over 14 years Allen has been responsible for driving The Open Group’s strategic plan and day-to-day operations, including extending its reach into new global markets, such as China, the Middle East, South Africa and India. In addition, he was instrumental in the creation of the AEA, which was formed to increase job opportunities for all of its members and elevate their market value by advancing professional excellence.