Business Architecture
An architecture narrowed to IT fails to reveal the structure or operation of the Enterprise i.e. the Enterprise Architecture.
What would a picture with an ERP, CRM, Portal, DW and an e-commerce application... tell you? Little. Most companies have that. You wouldn't know your company from another. We'd all end up with the same picture.
You would not be able to align IT to business, because there is no business picture, never mind the organization and other technologies.
Your company is better described by its products, the company structure and business processes, the flow of your transactions.
How would we build a real business picture?
1. describe the products, stakeholders and environment
I use UML.
2. Map the business structure
I break the Enterprise in four business functions areas called collectively GODS: Governance (e.g. Board, CEO office...), Operations (e.g. Sourcing, Production, Sales), Development (R&D, Product Development) and Support (e.g. HR, IT...). Any Enterprise has this complete set of functions. Then I use Value Chains. In fact I produced a template business reference map to get anyone started. This is the business process map.
3. Depict processes
Use a business process framework (some call them Value Streams). I put together a simple generic one that will get the process documentation started. It is clearly describing key processes you have to model. It's not the same as the business reference map. This work can stretch over years and it is not in the IT scope. But EA is about coordination and collaboration.
4. Map Strategy and sketch future EA state, agree roadmap
I describe a strategy design and mapping process. That applies also to the IT architecture layers. Objectives are here cascaded to EA components, processes...
5. Then map the organization to business; need your CEO backing or back off; an organization design template is given with its alignment to architecture.
But there is more to that: what is the difference between a function and a process? In fact I use the term flow instead of process to eliminate confusion. This small issue may stop a good architecture in its tracks.
How do function, process and information link together? An EA framework shows the EA layers and views. A metamodel explains all EA entities and their relationships. The metamodel does not make you loose sleep by requiring modelling of services and contracts, as some do, because simply they don't really exist at this stage in most companies.
There always is an architecture design method recommending artefacts, design sequence... based on the old structured and OO SW design methodologies. Only DODAF has it. But key artefacts need to be standardised. When do we do activity or state diagrams? It is simpler than DODAF though.
Zachman and TOGAF would not help you with business architecture. Zachman asks the questions at the business layer but goes no further. You have to come with all the answers. TOGAF mostly lists business artefacts.
You would also see the difference between business modelling, business model and operating model in one place, one book and how to use them.
The most important EA artefact is the Single Page Architecture, or the business architecture on a page with entities, links and legend illustrated in the book.
The whole framework enables stakeholders to navigate the graphical EA framework representation from business entities to technology and organization, to trace processes, discover resources and impacts, analyse performance and eventually unearth faults.
This is cutting edge material for Business Architecture. BA materials are few since neither Business is trained in architecture nor IT in business theory. The book URL can be found in the footer of the blog. It is available on Amazon and other sites.
...
The problem with Enterprise Architecture and existing frameworks is that they are IT oriented, designed by IT, for IT ignoring the business views and architecture. That is why in most cases Enterprise Architects are selected from the ranks of IT Solution and Java Architects... While existing EA architects are eminent IT people there is no guarantee they understand or are even interested in the business methods and theory since they generally find employment on IT skills. In its current technology only approach, EA does not help much the Enterprise except for IT standardization purposes.
Business Architecture is often mentioned in the EA context. Fact is that reference business architectures and development methodologies barely exist, with exceptions. In fact they are called Value or/and Supply Chains (they are not the same) in business theory. Examples are VRM (Value Reference Model), SCOR (Supply Chain Organization Model), APQC,NGOSS(eTOM) in telecommunications... A warning: they all have slightly different approaches, not dissimilar to the EA frameworks situation.
The architecture discipline does not exist in the business domain that deals with practical issues rather than organization design, value chains analysis, business models... Hence, the Enterprise Business Architect, while sometimes mentioned, does not really exist or the role is often allocated to a business analyst, not adequately equipped for the job.
The EA business architect should design the business architecture, the model on which you can base your IT architecture, and be knowledgeable of business operation, value chain analysis, supply chains, business models, BPM, business process design, Six/Lean Sigma, strategy, and eventually governance, organization design, business cases, management financials... and have an understanding of IT as well. This job description is not that of a business analyst that is most often found playing this role.
Many of these business architecture related topics are taught in an MBA program and as such it could be a route for an IT Architect to rise to an Enterprise Business Architect position. On the other hand, a business consultant skilled in IT might be a candidate for the role.
Architectural skills, typically acquired during a long career, are so important since structuring systems is the main activity of an Enterprise Architect. Business people and consultancies are not very much into Enterprise Architecture because, in the first place, they seldom cover the whole spectrum of business issues and they are not cultivating architectural skills that are more typically grown in a technology environment.
In the computer technology domain there is a long tradition of designing architecture represented in diagrams of electronic components and connections, systems and networks. The architecture was adopted afterwards in IT, at applications level, to depict integration, control and data flows. But applications alone hardly paint a picture of how the business works. To truly do Enterprise Architecture one needs to elevate the architecture discipline in the business domain, taking into account the already existing business concepts.
...
Business architects, when they exist, usually occupy business analyst roles, mostly belonging to the "business" community, not the IT; they have the task to look into requirements and model the business processes but typically out of the Enterprise Architecture context.
Still the business architecture is the key to the whole Enterprise Architecture. One cannot understand what applications do without a picture of what business wants to do and how it does it. In fact I would go so far to say that, without a business architecture, the EA (or SOA for that matter) means little: loose diagrams of a patchy collection of systems without the unifying picture of the business delivery flows.
The lack of a proper business architecture may be the ground for failure of Enterprise Architecture developments (and SOA - which is based on it -) to deliver the touted benefits and the subsequent management skepticism.
The problem with Enterprise Architects is that they do not cover business architecture since it is not part of their curriculum. Similarly, business people and analysts do not cover technology or even architecture as a discipline. The division between business and IT does the rest of the damage to the EA.
Hence, while there are "Enterprise Architects" in place doing IT integration, inventories... more often than not there is no one to do the business architecture i.e. business functional decomposition, process documentation...
...