A role of Business Architect appears more frequently in out conversations nowadays. There are several discussions running on LinkedIn about definition, business value, positioning and even appropriate remuneration of this role.
To answer these questions, I believe we have to articulate what a Business Architecture is first of all. I do not hope to reach an agreement on this subject because too many orthogonal interests are involved in this area. Nonetheless, I count on common sense and language semantics, in particular, on people understanding that if somebody says 'white' it is white and not black in any sense, though even 'white' may have some grades...
I think that we agree that Business Architecture is the Architecture of Business. The word 'architecture' means a collection of artefacts and relationships/dependencies between them. Full stop. In other words, Business Architecture is not a procedure, not a process, not a forecast. Unfortunately, I was not able to find a definition of Business Architecture in business area while technical TOGAF has this term in its vocabulary. TOGAF defines Business Architecture as follows:
"The business strategy, governance, organization, and key business processes information, as well as the interaction between these concepts".
In the contrast, the Object Management Group's Business Architecture Working Group efines Business Architecture differently:
"A blueprint of the enterprise that provides a common understanding of the organization and is used to align strategic objectives and tactical demands."
While I agree with OMG despite very high level of abstraction they use in this definition, I have a problem with the TOGAF's statement. I have to admit I was a critic of TOGAF 9.0 in the past. It is not because I am a TOGAF 8.1 Certified Practitioner but because of the real weak positions of TOGAF 9.0 in several areas of not-that-best architectural practice. So, let's look at the TOGAF's Business Architecture.
First, 'business strategy' is a concept and the document about business directions and intentions. It can talk about a set of transitions, from one architecture to another, with all reasons and conditions but it defines none of mentioned architectures to the appropriate level of details. Business governance is a set of rules, policies and procedures that can be applied to different businesses and do not necessary identify the essence of particular business; it is an instrument to deal with the subject rather then the subject itself. Then, Business organisation in this context, IMO, is an administrative organisation that also may be not specific enough to the business of the firm. To me, it looks like another business instrument related to management in this case. Finally, what does mean a "key business processes information"? Different observers or stakeholders will have different keys for this information. Is "business processes information" about structure of existing processes (in/out/result)? Is "business processes information" about internal elements of each process? Is "business processes information" about only crucial processes for the company? Business process information is too generic term to be a comprehensive part of an architecture. Thus, given definition is not concerning information architecture because "business processes information" is not the full business information used by Business, also it is not concerning business functionality, i.e. the thing the company is about, it is not concerning company stuff and company customers. Well, this definitions is certainly concerning business instruments, but I have not heard about an architecture of instruments before...
I think that Business Architecture may be defines as
a set of artefacts such as business functionality (services, functions, features and crucial processes), people, resources (including instruments and tools), and products as well as inter-dependencies and interactions between them within particular business execution contexts.
In this case, strategic planning is a means of reaching strategic business goals by transforming Business Architecture from current state to the target state(s) through a potential sequence of tactical transformations. Business organisation structure is a derivative of the Business Architecture used to manage transformations and states between them. Business governance is the internal regulations that constraint and direct activities related to the architecture transformations and states between them. Governance assists business management in its work. Lastly, the key business process information is the information about crucial, key business processes visible only at the level of organization's business model [discussed in the book Ladder to SOE]. All other 'business processes' are only particular realisation of business services, functions and features. Those processes are supposed to be very flexible and replaceable, i.e. they cannot be addressed in the stable architecture but rather in the architecture implementations.
A few CIO told me that they were doing Business Architecture work when writing Business Plans (or participating in such writing). I am not sure that Business Plan is the right form for capturing the scope of Business Architecture. Instead, we, probably, have to move into more architectural forms like Business Architecture Blueprint that answers the questions WHAT, WHY, WHO and WHOM for the corporate business is doing.
A Business Architecture Blueprint has to be the basic source for developing a variety of business views that may be used for different business tasks but together constitute one unique appearance of the business enterprise. These views include strategic and tactical prospects, landscape of business capabilities, business knowledge aspects, products and product resources/dependencies, rational for this or that organisational structure and others.
Thus, Business Architecture is about the essence of the business. But very few businesses can effectively operate without automated business tools. The latter are the products of corporate IT. In Technology, we have a function and an organisational unit called 'Enterprise Architecture'. This function is repeatedly misinterpreted considering the word 'Enterprise' as a synonym to Information Technology department. I believe, it is the time to understand that Enterprise Architecture is about Enterprise, i.e. about both Business and Technology. The Enterprise Architecture in the company should belong to the cross-departmental and cross-functional programme and management. The good news is that TOGAF defines Enterprise Architecture as a composition of Business Architecture and Technology Architecture, together. The bad news is that Business is not very much aware about this definition.
Such positioning, more accurately - re-positioning, of the Enterprise Architecture gives us a justifiable ability to define and position the role of Business Architect.
Michael,
Enjoyed your post. The case you are making about business architecture being about the architecture of the business however has already been covered by business plan, business strategy and other standard business documents and has for many many years. We have a wealth of business consultants, business strategy sessions, etc.
The use of the term architecture does not add meaning to those activities but simply confuses them as you can see in this post http://bradwray.blogspot.com/2009/08/couple-of-thoughts-on-enterprise.html. The use of the term architecture in non-building and non-naval environments has been used to relate to technology. And with software infrastructure information and business technology related architecture on the rise, a definition that confuses an architect with a non-technologist will not help us as a profession but hinder our growth and the understanding of what we do.
Paul
Thank you, Paul, the second part is on the way (due tomorrow) Let me answer to your notes by paragraphs.
No.1 Sure, I am aware of "business plan, business strategy and other standard business documents". Also, I agree that those documents contain information about some aspects of Business Architecture... without presence of architecture. For example, when you create a Business Strategy Plan, do you always know exactly what business services, functions and features are realised across organisation and what implications a strategic change will have on the rest of the business environment?
Business Architecture plays the same role for Business as Technical Architecture plays for Technology. At the enterprise level, there is one type of the architecture, at the LOB or Project level the architecture appears differently. Also, Business Plan in any case is not an architecture because it is about transformation from A to B, but A and B states are not accurately defined and understood in too many situations.
No. 2. I read the post you pointed to. I do not see a ‘confusion’ in business plan, business strategy and other standard business documents but a ‘threat’ that now all of them have to be viewed and analysed together from one shared platform – Business Architecture. This brings more accurate and strict control over inter- and cross-dependencies in business solutions which cannot be achieved without new cross-functional authority. This is the problem.
I am not that afraid of confusion of word ‘architecture’ in Business – some people will get it right away, others will struggle. It is similar to changing meaning of SOA now – from technology to methodology. It is painful sometimes but not deadly.
I am curious what “ business technology related architecture� means; what is “ business technology�?
Hi Michael, me again. I must say that our disagreements are probably healthy ones, but of course as you say, don't help with consensus.
'a set of artefacts such as business functionality (services, functions, features and crucial processes), people, resources (including instruments and tools), and products as well as inter-dependencies and interactions between them within particular business execution contexts.'
This makes sense to me, although I'd like an example of your last sentence '..within particular business execution contexts'.
Anyway, I think we need to stick with something like this and avoid referring to everything as 'architecture'. We should be far more judicious in using the term. For example a lot of what we do is detailed design work within an architecture and there is nothing wrong with this. I worry that 'architecture' has become another jargon word like 'governance', so that nobody is doing plain, simple, ordinary design or management anymore. So, where your CIO's claim to be doing Business Architecture work by writing business plans, we surely need to be refuting this (in a diplomatic way).
By the way I agree 100% with your last couple of paras that effectively describe the hijacking of the term 'enterprise architect' to mean IT. Although I baulk at 'enterprise architecture' as 'business' and 'technology' architectures. For example where does 'finance architecture' fit, even though the term isn't used for historical reasons?
Hi Ron,
I am glad we have some agreement :-)
In the definition, I would like to stress on 1) services, functions, features and crucial processes; 2) related resources (at large). Products in this case is an oxymoron here because I think they are just a compositions of 1) and 2) (or should be just compositions).
Now about '..within particular business execution contexts'. Architecture is a highest level of solution of the business tasks identified in the business model. As such, Architecture is influences by local political and economy laws, i.e. rules, policies and regulations. These three constitute particular business execution contexts.
If we step a level lower, to the products, we will see the same effect but, probably, clearer: products have to behave differently in different locale because of the local laws.
To my understanding, even if services, functions, features and crucial processes in the Business Architecture may be the same irrespectfylly to the business execution context, the latter will modify the relationships between the business entities.
For example, a pension providing company in the UK must verify personal contributions limit if the contributions made via ISA; in the US, the 401K plan is not limited in such a way. That is, even if the same business services and functions are implemented in two companies residing in to countries, there is an additional business function (contributions limit control) in the UK.
I will answer about 'finance architecture' in another comment.
THere is no such thing as a business Architect. Computer Architect.. To say that one who implements business plans is an architect is like saying someone that fixes your car is an automotive doctor. It is absurd
Indeed, 'automotive doctor' is absurd.
Hi FJmarch,
As of Business Architect, let me point to several Groups on LinkedIn and numerous discussion topics about what Business Architecture is, who is needed it, how it may be governed and how it may be performed.
Real absurd is not having a Business Architect role in the organisation. In some companies, this role is played by executive management until they have an enough bandwidth. If this limit is exceeded and the role is not clearly defined for a full-time job, the company risks quite bad business performance in the future.
Mike: I might suggest small changes to your definition:
The description of the set of artefacts such as business functionality (services, functions, features and crucial processes), people, resources (including instruments and tools), and products as well as inter-dependencies and interactions between them within particular business execution contexts.
An architecture is not a 'thing', per-se. it is a set of workds and graphiucal representations and other constructs that explain the environment, such as 'business'. Hope you will agree.
John, currently I am working on the article where I challenge the statement that Business Architecture includes people, resources, and products. In this case, resources are not instruments and tools but actual resources - human and technical.
I believe that architecture is a combination of things, their inter-relationships and overall principles. Moreover, the things that may be considered the architecture elements must be self-contained. To select the things, I use 'informational attribute' concept known from mathematical Cluster Analysis: if the attribute is informative, its change leads to the change of the whole thing; otherwise, the attribute may be irrelevant to the thing.
Please, watch for my blog for next few days for that article.
business architecture describes a modern and perhaps better way of requirements gathering for IT in a world where growing standardisation permits descriptive terms like 'architecture'
Jeremy, in one of LinkedIn discussion we talk about exact same topic: business architecture (BA) and requirements for IT.
I am not sure why do you mention >; to me, architecture is descriptive AND prescriptive.
As of BA, it may be used to form business requirements for IT but BA does NOT describe any ways for requirements gathering for IT; IT is immaterial for BA. Nonetheless, I agree with you that formal existence of BA and related documentation makes business requirements gathering much easier for both Business and IT.
I'm interested in simplifying the discussions - not necessarily for the rest of the world :-) more for my own viewpoint - 10 years ago difficult to find the standards to architect nowadays easier so BArch exists to define requirements and synch with IT - thats all no great mystery..
Thanks for your defintions - appreciate them.
IMO, "BArch exists to define requirements" to the Business Architecture based on Business Strategic Plans and market analysis (irrespective to IT at all).
I see another BuzArch duty in reviewing the BR and business needs inside Business before they are passed to IT. But it is not the same thing as defining these BR This is the BuzAnalyst and Management areas). Also, a BuzArch could participate in the discussion with IT Architects if they have questions or cannot meed the BR.