This tutorial is adapted from Web Age course Business Architecture Foundation Workshop
1.1 Defining Business Architecture
A Business Architecture is an essential function of the Business that describes what it does and how it does it to support organizational goals and objectives. Business Architecture is a composite of business capabilities and business processes expressed in the form of formalized artifacts. It is a part of the Enterprise Architecture.
Notes:
While Business Architecture is a relatively new discipline it has been recognized by industry standards bodies such as the Open Group and OMG. In practice, there is no general consensus as to what Business Architecture exactly is. Even to the extent that mature architecture frameworks such as TOGAF or FEAF agree (and they largely do), there is still a gap in the perception of many business and IT professionals regarding the scope and content of the Business Architecture discipline.
IBM Global Business Services promote their own understanding of what a Business Architecture may be, which they call the Actionable Business Architecture (http://www-935.ibm.com/services/us/gbs/strategy/actionable_business_architecture). According to IBM GBS, an Actionable Business Architecture is the product of “the confluence of three often disparate models in strategy, operations and IT” which accelerates time-to-value in business / IT projects. IBM GBS define models as “reusable assets, industry leading practices and industry standards or guidelines that capture knowledge about the industry and the enterprise.”
1.2 Layers of the Enterprise Architecture
Enterprise Architecture regards the Organization as a large and complex system of interconnected sub-systems. One way of reducing system complexities is to separate them into layers with their own problem (architecture) domains.
Source: Wikipedia.org
1.3 The Business Architecture Domain
Within the Business Architecture Domain fall the following core components and activities which reflect and help with the realization of the Organization’s strategy and vision:
◊ Business Process design and modeling
◊ Business Requirements
◊ Business Rules
◊ Critical success factors
◊ Organization structure
1.4 The Values of Business Architecture
The Value of Insight
◊ If you found 10% more funds to invest, where would be the optimum place to invest?
◊ If you needed to trim 5% from your operating costs, where would you look first?
◊ Without a model for how business gets done and an understanding of how your business is structured (which are all artifacts of Business Architecture), these types of decisions are very challenging
The Value of Managed Change
Process changes, organization changes, requirements changes, and comprehensive strategy changes are a fact of business. Business Architecture provides a baseline model to support and enable enterprise changes without the usual chaos and confusion that is typically associated with significant change.
1.5 Relationship with Other Types of Architecture
There are four domains of architecture recognized by most prominent architecture frameworks. Business Architecture is positioned at the top of the enterprise architecture stack driving project activities downstream in support of the strategic and
tactical business decision.
Business Architecture project activities must occur early in the life cycle of enterprise projects in other architecture domains. Other types of architecture must align with the Business Architecture. Underlying Architectures provide upstream feedback helping fine-tuning standards, business models and requirements.
TOGAF and FEAF both recognize these 4 domains of architecture.
NIH (National Institutes of Health) condenses their framework down into three domains:
• Business Architecture
• Information Architecture (including Data, Integration, and Application)
• Technology Architecture
1.6 Other Pillars of Business Architecture
In addition to the Technology supporting pillar, Business Architecture also depends on the Human Resources and Business Processes of the Organization. Company’s Human Capital and Business Processes are accounted for in Business Architecture and must be coherently aligned for realizing Enterprise Strategy and Vision.
1.7 Formal Business Architecture
Characteristics of ineffective Business Architectures
Difficult to interpret artifacts – Explanatory information is often incomplete. Also, artifacts representing similar or even the same parts may use different characteristics or visual notations, further confusing readers.
Difficult to retrieve related artifacts – Stored in multiple repositories, individual machines or buried in documents.
Difficult to maintain artifact consistency – If something about a part changes, a name for example, and the part is depicted in multiple artifacts, than all artifacts need to be updated.
Part relationships not maintained –The fabric of your business is encompassed by the relationships among it’s parts: To be of value, your business architecture needs to precisely express these relationships.
Characteristics of Formal Business Architectures
No ambiguity – Each unique part in the model has a single precise representation (formal grammars) and is maintained only once in the database.
Formal relationships – Relationships between parts are themselves parts, and as such have formal grammars and are maintained only once.
Easy to make changes – Parts and relationship representations are used by all model artifacts. Thus, when the model representation changes, all the artifacts using that part are updated automatically.
Easy to find – Model parts, relationships and all artifacts are stored in a single computer database.
1.8 Ownership vs Stewardship
Business Architecture (BA) should be OWNED by the Business, even if it is actively managed, or STEWARDED, by the technology team. IT often serve as stewards (executors, servers) of business rules engines, process modeling tools, databases, etc. which gives the illusion of ownership, while, ultimately, those are paid for, created in support of and owned by the Business. ◊ It may help to view BA as a joint effort between Business (owners) and IT (stewards).
1.9 Business Architecture Frameworks
Business Architecture must be documented in and realized through some sort of an Enterprise Framework which must:
◊ Capture the “essence” of the Business
◊ Be suitable for identifying technology needs
◊ Establish consistent vocabulary and notation
◊ Be product and technology agnostic
◊ Reflect multiple views of the enterprise
◊ Be comprehensive
◊ Provide for agile and cost-effective change
1.10 Enterprise Architecture Frameworks
Enterprise Architecture (EA) Frameworks help deal with complexity and change. We will review two popular EA frameworks as they apply to Business Architecture:
◊ Zachman
◊ The Open Group Architecture Framework (TOGAF)
1.11 Business Architect vs Business Analyst – 1/3
To help further define Business Architecture, it may be useful to review the differences in roles of a Business Architect and Business Analyst
Noted Enterprise Architect Nick Malik (Enterprise Architect with Microsoft), provides the following comparison between Business Architects and Business Analysts
| Business Architect | Business Analyst | |
| Why | To uncover the gaps between strategic needs of a business unit, and their abilities to meet those needs, and to charter initiatives to fill those gaps. | To develop and document the detailed knowledge of a business problem that an initiative has been chartered to address. |
| How | Analysis of future-looking strategies, capturing of capabilities, and modeling of inter- and intra- business relationships needed to discover the key capability gaps that a business must be prepared to face, along with the development of cross-functional roadmaps to address them. System requirements are NOT captured. |
Interviews with existing business stakeholders and SMEs to elicit business rules, understand processes, information, and systems in use, and detailing the consequences (intentional or not) of making a business change to address a specific issue. The primary result of this activity is the document of System Requirements. |
| When | On-going process that is triggered by periodic strategy cycles within a business. | As-needed activity that is triggered .AFTER a problem has been identified and requirements for a solution are needed. |
| Who | Business or IT Generalists with a strong understanding of business functional issues, interdependencies, and business structural concerns. Must be excellent at capability analysis. Must leverage modeling and rigorous analysis skills. |
Business or IT Generalists with a strong understanding of information and application interdependencies, requirements analysis, and system development methodologies. Must be excellent at IT requirements elicitation. Must leverage modeling and rigorous analysis skills. |
| What | Business motivational models, Value Streams, Scenarios, Capability models, Heat Maps, Funding Maps, Risk maps | Business Requirements, Business Rules, Use Cases, and Detailed Business Process descriptions |
| Scope | Enterprise continuum / cross-domain | Project / process |
| Focus | Strategy / tactical / solution-neutral / holistic | Solution and/or operation specific |
| Skills / Personality |
Architecture methodologies / human relation | Applied process engineering / task-oriented |
Source: Nick Malik’s blog
1.12 Going Beyond the Process
It is quite common to confuse Business Architecture with Business Process Modeling (BPM) or business process management. The important thing to realize is that Business Architecture will typically INCLUDE and even direct process improvement activities and high-level end-to-end business process modeling, but will typically refrain from detailed process modeling and management activities . For many organizations, BPM is considered a subset of Business Architecture. No formally recognized architecture framework or architecture discipline treats Business Architecture and BPM as being synonymous .
Key Elements of Business Architecture (beyond process)
• Model-driven
• Integrated artifacts
• Formal semantics and grammar
• Consistent and unambiguous descriptions of capability
• Business / IT alignment
1.13 Summary
There is a lot of confusion surrounding the role of Business Architecture.
A few universal aspects are broadly agreed upon with respect to business architecture:
◊ It is essential
◊ It is a joint effort between Business and IT
◊ It occurs early in the architecture life cycle and drives and informs other downstream architecture activities
◊ Business Architecture is not the same as Business Analysis
