Business Ecology Initiative & Service-Oriented Solution

For last few days, I participated in several 'hot' discussions on LinkedIn about Business Architecture, Business Architect role and Business Services. Among others, the questions included:

• What are the business imperatives for doing Business Architecture?
• How would you describe business architecture in less than 140 characters?
• What is an appropriate salary range for a Business Architect?

About a dozen different experts participated in the discussions and more than 130 messages were exchanged. While it is impossible to reflect all opinions expressed in this BLOG, let me outline the most common positions:

1) Business Architecture is about strategic business initiatives and business process design
2) Business Architect is a high-ranked business role concentrated mostly on providing strategic plans into reality
3) Business architecture includes almost everything Business does (planning, roles, responsibilities, change management, process re-engineering, etc.)

I have an impression that people try to 'legalise' all existing business activities by naming them a popular word 'Architecture'. Is this just a hype? Is there anything wrong with what Business is doing?

I dare to disagree with mentioned opinions and show you my concerns and conclusions.

I think that Business Architecture is, first of all, the architecture; otherwise why we call it this way? As we known, an architecture is a collection of entities and their relationships dedicated to the shared set of goals and organised based on common principles. The question is what these entities are.

According to Colin Rice, Business Architect and Analyst, "Business architecture is the discipline and practice of designing and planning business structures and processes. To elaborate, the structures and functions include, but are not limited to, business capabilities, business processes, value chains, target operating models, jobs, roles and responsibilities, data, organization, channels, locations, products, relationships with external business partners, legal requirements and the use and exploitation of technology." This is typical enumeration, it is about what the architect deals with but daily 'things' do not justify the statement that all of them belong to Architecture, do they?

In my opinion, Business Architecture occupies very concrete niche of a structure of business functionality that the organisation has today and will have tomorrow (strategic aspect) as well as the transitional steps from 'today' to 'tomorrow' that must be done in consistent and in integral manner across the organisation. Business Architects have a lot of things to do for day-by-day maintenance of current architecture and for transitional steps into the future state. All business decisions about business services, functions, features and core high-level processes as well as anything that affects Organisation Business Model must be either discussed with Business Architects or delegated to Business Architects for proposals and estimates of impact on the other architectural elements.

If assume that Business Architecture and Business Architects have to deal exclusively with the strategic things while "shorter term tactical activities and investments" may go in a vacuum, without the Business Architecture for 'today', the result is known already - those who do this usually pay very high price of business inefficiency and a lot of extra money thrown onto the fixing 'tactical' mistakes.

So, I see Business Architecture situating between a) Organisation Business Model with defined business capabilities accompanied by strategic business planning (both attributed to the C-level corporate executives), on one side, and b) "business processes, value chains, target operating models, jobs, roles and responsibilities, organization, ... locations, products, relationships with external business partners, legal requirements and the use and exploitation of technology", on another side. That is, I separate reasons for architecture existence (WHY) from the architecture implementation and derivatives (HOW); the architecture itself is about WHAT, WHO, and for WHOM. The all three areas - WHY,WHAT and HOW - influence each other but exist separately and address different business concerns. Isn't this a clear and sensible classification? Does it make sense?

Geoffrey Balmes, Sr. Business Architect and Change Management Specialist, had pointed to the definition of the Business Architecture formulated as a draft by the OMG Business Architecture Working Group (BAWG): "A blueprint of the enterprise that provides a common understanding of the organization and is used to align strategic objectives and tactical demands". So, if we describe all "business processes, ...target operating models, jobs, roles and responsibilities, organization, ... locations, products, relationships with external business partners, legal requirements and the use and exploitation of technology", we will know how the enterprise works but will we understand what the enterprise does, what the enterprise is about? My answer is 'NO', all listed artefacts may belong to quite different organisations.

In another discussion about Business Services, Patricia Oliver, Director of Business Services, had said: "IMHO, Business Services can be identified via Business Architecture models, but Business Architecture includes process as a primary element. ... The WHAT, WHY and WHO should be identified in the early stages of Business Architecture, in the high level structure. When interviewing, we begin with the goal, the strategy and then drill down to the sub goals that support the higher level goals, to the responsibilities that enable those goals to be met, and finally the processes that are required in order to satisfy the responsibilities. When we get to that level, I often ask people to describe their process regardless of technology, e.g. if their work was all done manually. I do this to identify what needs to be done, what is required to support the goals of the enterprise, as opposed to the way it is done today with their current technology." I am quoting Patricia so much because she had expressed the collision between WHAT and HOW in the Business Architect work very well.

As you can see, Patricia admits that "WHAT, WHY and WHO should be identified in the early stages of Business Architecture". Answering all these questions, we cannot proof that we are talking about processes but this information is sufficient for defining services. Consumers are interested only in business functionality and Real World Effect of business activities, i.e. in the business service results. The C-level executives operate with business services as well do we like it or not. Even when drilling down (according to Patricia), the business entity structure stays the same - it is about goals and sub-goals, i.e. services that hide their internals. But when we switch on "the responsibilities that enable those goals to be met", we obviously cross the boarder from WHAT into HOW, i.e. we are leaving the service domain and enter into the process domain. Also, it is an unusual put to me: "finally the processes that are required in order to satisfy the responsibilities"; I used to think that business objectives even expressed in the form of business process (with its goals and in/outs) define/require/dictate responsibilities of the people, not other way around...

Actually, the last sentence of the Patricia post explains why she insisted on "Business Architecture includes process as a primary element". It appears that Patricia 'discovers' or extracts "what needs to be done" from existing business activities. That is, the discovery runs bottom-up, from 'what we have' to 'what we might need'. I believe that Business Architecture should work only top-down: define what we need and how we get there from what we have, and only then construct business services and implement them via business processes, if we suggest so. In this way, the primary element of the Business Architecture is 'service', secondary element is 'process' and combination of both is the Business Product. The latter can be easily adjusted to the market changes by recombining services into new service orchestration. I try to avoid saying 'into new process' instead of orchestration because service orchestration results in new service, which can be exposed to the customers while it is too risky and not recommended to expose your internal process.

Nevertheless, at this early stage of formal adoption of the Business Architect role, I certainly agree with Patricia and others who associate business process design with this role even if the role might be ranked close to the executive level. One of the reasons for this is that there is nobody else for this job. In comparison, Technology Architecture is supported by a structure specialised Architects (infrastructure, application, information, etc. architects), Designers, Technical Leads and so on. In Business such hierarchical structure of roles with narrowed responsibilities does not exist yet; it would be nice having a Business Process Designer, wouldn't it? With emerging of this structure in Business, we will have special Business Architects at the Enterprise, LOB, BU, Programme and even Project levels. The structure will be in line with the structure of existing business services (and processes) of different scope. Let's give it some time.