Artifact: Business Architecture Document

	The Business Architecture Document provides a comprehensive overview of the architecturally significant aspects of the business from a number of different perspectives.
Role:	Business-Process Analyst
Optionality/Occurrence:	Can be excluded. The Business Architecture Document should only be used when decisions regarding changes to the business need to be made or when the business needs to be described to other parties.
Templates and Reports:	Template: Business Architecture Document
Examples:
UML Representation:	Not applicable.
More Information:	Concept: Business Architecture Guideline: Business Architecture Document Checklist: Business Architecture Document

Purpose Timing Responsibility Tailoring

Input to Activities:  Define Automation Requirements Find Business Workers and Entities Identify Business Goals Maintain Business Rules

Output from Activities:  Define the Business Architecture

Purpose

The Business Architecture Document provides a comprehensive overview of the structure and purpose of the business. It serves as a communication medium between the stakeholders and project team members. Because it describes the "whats" and "whys" of the business, it thereby forms a basis for making informed decisions regarding changes to the business.

Timing

The representation and objectives of the business architecture usually must be defined before the very first iterations and then be maintained throughout the project. These architectural representation guidelines are documented in initial versions of the Business Architecture Document.

The Business Architecture Document is primarily developed during the Inception phase, because one of the purposes of this phase is to establish a sound architectural foundation that can serve as input for defining the software architecture (see Artifact: Software Architecture Document). Furthermore, architectural decisions will heavily influence any ensuing scoping decisions in the project (s).

Responsibility

A business-process analyst is responsible for producing the Business Architecture Document, based upon the input of many different stakeholders. The business-process analyst should capture the most important business-design decisions and describe their consequences using multiple architectural views of the business. 

The business-process analyst establishes the overall structure for each architectural view: the decomposition of the view, the grouping of elements, and the interfaces between these major groupings. Therefore, in contrast with the other artifacts defining the organization, the Business Architecture Document presents a view of breadth, as opposed to depth.

Tailoring

You must adjust the outline of the Business Architecture Document to suit the nature of your business and the purpose of your effort as shown in this list:

• Some of the architectural views may be irrelevant, or other views may be necessary to describe certain aspects.
• Some specific aspects of the business may require their own sections; for example, aspects related to security, data management, usability issues, or legal and regulatory compliance.
• You may need additional appendices to explain various aspects, such as the rationale of certain critical choices together with the solutions that have been eliminated, or to define acronyms or abbreviations, or to present general business design principles.
• The order of the various sections may vary, depending on the stakeholders in the business and their focus or interest.

Here are the advantages and disadvantages of each architectural view:

• Market View-This view is optional. Use it only if you will be making decisions regarding the business strategy or in cases where the business strategy may be influenced by architectural decisions.
• Business Process View-If you develop this document at all, this view is mandatory.
• Organization View-If you develop this document at all, this view is mandatory.
• Human Resource View-This view is optional. Use it only if the reorganization implies radical changes in how people work and how they relate to one another.
• Domain View-This view is optional. Use it only if information is a significant aspect of the business and if there is a need to clarify concepts that are core to the business domain. This view is very useful for improving communication and understanding between different departments, projects, or external parties.
• Geographic View-This view is optional. Use it only if the effect of the geographic distribution of business operations on business processes needs to be understood.
• Communication View-This view is optional. Use it only if the internal and external paths of communication must be understood.

This content developed or partially developed by Empulsys BV.

Rational Unified Process