Business Architecture View

Developing a Business Architecture View

Stakeholder and Concerns Modeling the View Key Issues

Stakeholder and Concerns

This view should be developed for the users. It focuses on the functional aspects of the system from the perspective of the users of the system.

Addressing the concerns of the users includes consideration of the following:

People - the human resource aspects of the system. It examines the human actors involved in the system.
Process - deals with the user processes involved in the system.
Function - deals with the functions required to support the processes.
Business Information - deals with the information required to flow in support of the processes.
Usability - considers the usability aspects of the system and its environment.
Performance - considers the performance aspects of the system and its environment.

Modeling the View

The general business architecture can be modeled with ADML (components, ports, connectors, and roles).

Additionally business scenarios are an important technique that may be used prior to, and as a key input to, the development of the Business Architecture View, to help identify and understand business needs, and thereby to derive the business requirements and constraints that the architecture development has to address. Business scenarios are an extremely useful way to depict what should happen when planned and unplanned events occur. It is highly recommended that business scenarios be created for planned change, and for unplanned change.

The following paragraphs describe some of the key issues that the architect might consider when constructing business scenarios.

Key Issues

The Business Architecture View considers the functional aspects of the system - that is, what the new system is intended to do. This can be built up from an analysis of the existing environment and of the requirements and constraints affecting the new system.

Part II, Architecture Development Method, outlines the process of analysing and describing the existing environment in its own terms (Phase B), and then restating it in TOGAF terms to obtain information about what exists already (Phase C, Step 1). The new requirements and constraints will appear from a number of sources, possibly including:

Existing internal specifications and lists of approved products
Business goals and objectives
Business Process Re-engineering activities
Changes in technology

What should emerge from the Business Architecture View is a clear understanding of the functional requirements for the new architecture, with statements like "Improvements in handling customer inquiries are required through wider use of Computer/Telephony Integration".

The Business Architecture View considers the usability aspects of the system and its environment. It should also consider impacts on the user such as skill levels required, the need for specialized training, and migration from current practice. When considering usability the architect should take into account:

the ease-of-use of the user interface, and how intuitive it is
whether or not there is transparent access to data and applications, irrespective of location
ease of management of the user environment by the user
application interoperability through means such as drag and drop
on-line help facilities
clarity of documentation
security and password aspects, such as avoiding the requirement for multiple sign-on and password dialogues
access to productivity applications such as mail or a spreadsheet

Note that, although security and management are thought about here, it is from a usability and functionality point of view. The technical aspects of security and management are considered in the Security View and the Operations View.