The Business Perspective defines the business level view of the system. The various viewpoints defined show how
people (actors) interact with processes at various locations within the business, and the things they handle and
use (business entities). The models also show how these different aspects and things must relate to one another, both
statically and dynamically, to produce the desired business results. It places emphasis on the identification of
entities, actors, the business locations and processes, and their active responsibilities. The viewpoints show all
collaborations (relationships) needed to support business activities, and all classes (the static view of
entities) from which objects (operational instances) will be instantiated to obtain the desired business results for
the various business roles.
The key elements of the Business Perspective, summarized in the figure above, are:
Business Entities represent deliverables, resources, and significant pieces
of information that are used or produced.
Business Activities show how business processes, tasks, business
entities and business events and rules work together to perform a business activity. Events and Rules are captured
in the Business Process Model.
Business Event represent important occurrences in the daily
operation of the business that potentially trigger business processes.
Business Rules are declarations of policies or conditions that must
be satisfied during the execution of business activities.
Business Locations partition the system into inter-dependent areas of
responsibilities based upon a conceptual view of the system's conceptual geography. They encapsulate their
resources, and provide services through well-defined interfaces, to other parts of the system.
Business Roles are the active units of a business, they represent an abstraction
of a human interface (GUI) or software interface.
The Business Perspective is documented in four viewpoints, see Guideline: Business Perspective Views. Each Perspective, and Viewpoint within, has a
modeling language defined, integrated into the Perspective Viewpoint Language, see: Supporting Material: BPL Summary and Supporting Material: BPL Defined.
The following are some characteristics of the Business Perspective:
It is a bridging artifact that articulates business concerns and requirements, using business language and
concepts, but in a way that is useful to IT architects. It is a reflection back to business managers, using formal
constructs, of the area of business of interest.
It explores the essence of the system (or enterprise or business domains) in a way that provides a transition from
thinking about business issues to thinking about information technology. Model concepts and
constructs provide the formalisms necessary for architects to do this translation, but in a way that is
consumable by business managers. Computational aspects (such as storage) are absent from the Business
It is a way of firming up business concepts, requirements and strategies to be enabled or supported by information
technologies. Understanding the implications of these strategies, plans or goals on the IT architecture is a
major goal for IT architects.
A very important aspect of doing IT architecture is agreeing business object definitions, relationships between
objects, and the names for the objects. This permits business knowledge to be represented in a precise manner that
can be understood and validated by business domain experts, but in a way that is very useful to architects. Also
see: Practice: Define a Robust Glossary .
Note: Since UAM looks at the complete system (or enterprise or business domain),
the level of detail to be included in this model is a judgment call of the architect, based upon:
The objective of the architecture effort;
The size of the system, enterprise or business line;
Time and resource constraints.
In general, Business Entities, Business Activities, Business Locations, and Business Actors/Roles should have short,
descriptive names that are unique and recognizable. Multiple word names are acceptable for clarity, but multiple
names for the same thing (an entity, location, activity or actor) is a major problem—therefore, if there is
some contention regarding a name/definition, work through it until a single name and definition is agreed, or multiple
things are identified and defined.
Business Entities are named to reflect the information they represent. As mentioned they must be defined in the
Business Glossary (along with the activities, locations and roles), since there are always differences of opinion
regarding definitions, and relationships as well. The state, or other properties of a Business Entity, should not be
included in its name. Business Entity names should be singular nouns. See Guideline: Business Entity and Guideline: Business Entity Model for more information.
Business Activities, at the enterprise architecture level, encompass a number of processes and tasks; the names should
reflect these processes and tasks, Human Resources Management for example. It is better to be more specific
and explicit in early iterations that trying to attempt to develop generalized models from the start. One can
always return to a model and adjust as necessary to add generalizations, or likewise specializations.
Generally, the active form of a verb is useful (such as Shipping, Invoicing, or
Selling) as is a reference to the purpose of the Business Activity. See Guideline: Business Activity and Guideline: Business Process Model for more information.
Business Locations are named to reflect the generic / conceptual location that they represent. Business Location
names should be singular nouns, such as Factory, Warehouse, ATM, for example. See: Guideline: Business Location and Guideline: Business Locations Model for more information.
Business Actor names reflect the primary activities that they interact with. Note that at the business level it
should not be assumed that a actor/role will equate to a human, even if that is the current situation. The name
should reflect the role played by the business actor with the business activity. For example, imagine a
business activity in which an entity is submitted to and checked by one actor and then eventually processed and
finalized by a second business actor (such as purchase order eventually being filled). The business actor who
checks the order (against inventory etc.) could be named Order Reception, whereas the second business actor could
be named Order Fulfillment. Having the actor sounding human is pre-supposing the eventual solution. These decisions
should be deferred until later in the architecture process. See Guideline: Users, Actors and Roles and Guideline: Business Roles Model for more information.
Business Events and Rules are optional, but very useful when defining an enterprise architecture. Events
should be named in a way that indicates the occurrence or state change that it represents—in other words, they
generally have a business entity part and a business action part, for example OrderArrival. Do not
describe the reaction to the event in the name. The specification of the event is also independent of its
triggers. See Guideline: Business Event for more information.
As you study the business actors and business entities that participate in business activities, you may find several
that are so similar that they are really one. Even when different business activities do not have identical demands,
they may be similar enough to be considered one and the same phenomenon. If this is the case, merge the similar
activities into one. This results in a business actor or business entity that has the relationships, attributes, and
operations to meet the demands of the different business activities.
Several business activities may, therefore, have quite different demands on the same entity or actor. In the case
of business actors/roles, if you have employees capable of acting in the extended role(s), you will need to have
flexible employees who can work in several capacities. This gives you a more flexible business, if this extension to
their responsibilities is possible and desirable. This should be documented in an architectural decision.
In the Business Perspective, Business Actors describe the external interactions, whereas Business Entities represent
those things that are produced and consumed by the activities. The Business Perspective defines how the Business
Activities and Business Entities need to interact to produce the desired results for the Business Role and Actor. A
Business Actor/Role may represent an abstraction of an automated system interaction; this automation (or not) is
defined at the Logical and Technical Perspective levels.
The Business Perspective and Logical Perspective address the same problem domain at two different abstraction
levels. Therefore, these different views need to remain consistent, for example logical modeling details and concepts
(like storage) should not appear in the business level models.
When you examine the interactions and characteristics of business roles in the 'as-is' model (particularly those roles
played by human workers), the occurrence and consumption of business events, and the operations performed on business
entities, certain relationship heuristics between the Business and Logical Perspective modeling contexts may be useful,
as you look for automation opportunities. Links, associations and attributes in the Business Perspective may suggest
When the business activities are large, long-lived, or combine work from several independent areas (as is the case
for many enterprise architecture business activities) then the System Model view of the activity will likely have
many Logical Processes / Tasks in its model.
The things the business activities manipulated—modeled as business entities—have representations in the Logical
Business events are often implemented as messages between Tasks in process at the Logical Perspective level.
Associations between business entities often give rise to corresponding associations between entity classes in the
Logical Entity Model, but perhaps in a more specific way (i.e. as generalizations, aggregations, etc.).
The Logical Activities that manipulate Logical Entity classes in the Logical Perspective are
represented by Business Entities accessed by Business Activities in the Business Perspective .
A business actor/role that directly uses a business activity also becomes a logical actor of the logical
activity in the Logical Perspective context.
These relationships are useful when identifying requirements for the logical systems to support the business
As you model manipulations of business entities by business roles, it is evident that many of the operations on the
business entities would be performed with the assistance of some tool—perhaps computer-based. This is not
explicitly modeled as a type of information technology within the business model since it is conceptually
out-of-scope. As mentioned above, notion of computing and technology (technology solutions) do not belong in the
business level models. These automation and technology decisions are made when modeling the Logical and Technical
Sometimes the employees of one business contact the employees of another business through the use of an information
system in the first business, from the perspective of the modeled business (receiving the request), that information
system is a business actor.
A software developer tries to understand a problem in the product for which he is responsible. To understand if the
problem originates from the programming tool he is using, he contacts the programming tool supplier's World Wide Web
server and studies the list of known problems in the current release of the tool. In this way, the business actor
Software Developer interacts with the business actor Supplier WWW Server.
Understanding the Business
The following assumes that there is no pre-existing architecture work or models completed. If you want to effect
change in a business you have to know it well. Knowledge will assist the architecture team in making sound
decisions when defining the architecture, and help to establish a relationship of trust with business
people. The inclusion of business people on the architecture team is a valid approach (a must) but is not
enough. Specific business participants may have a limited or a skewed view of the business. The architecture
team must have a reasonable understanding themselves, and the domain architect must have an excellent understanding of
the business. How can this knowledge be acquired?
Start with a top-down approach to analyzing the business. Kick off the architecture effort by meeting with key
sponsors and stakeholders. It is necessary to understand the background and the objectives of the architecture
effort. If the business has gone through a strategic planning exercise or has a Business Motivation Model
then review these documents. The architecture team must have a solid understanding of the business vision
including the motivation for the architecture effort and a general idea of scope boundaries at the outset. To
further refine scope, analyze the organization chart. Understand the principle job descriptions and attempt to
put a boundary around the parts of the organization that apply to the effort. Compile a list of services
and products delivered by the business and place a boundary around this list. Understand the clients of
the business and those that apply to the architecture effort.
Take a first cut at defining the scope with a context diagram and bounded organization chart in order to try to
contain the exploratory and interview effort. Review this and the next steps in the exploratory process
with the sponsors and stakeholders.
From this analysis, you should now be able to compile a list of job titles of people within the business that
you would want to meet with either as a group session or individually. If time permits, individual
interviews are much more effective for exploration. There are several reasons for this, the most important
is that groups can be dominated by a single person’s or a few people’s opinions.
Before meeting with people within the organization obtain permission from senior managers. Explain the time
needed, the purpose of the meeting(s), the characteristics of a good participant and obtain the names of
potential interview candidates. The ideal participant will know their job function well, will have preferably
worked in other parts of the business, learns quickly, has a positive attitude and can think outside the box.
Throughout the whole exploration process, find the champions and the decision makers as well as good candidates
for inclusion on the architecture team (i.e., business representatives). Having good decision makers will
ensure the stability and quality of the decisions made and of the architecture.
Review any policy / procedure manuals prior to the interviews. You must understand the business language before
Prepare interview questions.
Now the bottom-up analysis begins with preferably individual interviews. You can use group sessions if you
must due to time considerations. Be flexible during the interview process. Remember that the purpose
is to understand the end-to-end process for the delivery of a service, to understand why things are done a
certain way and to drive out the ‘true’ business rules and key practices. Note that there are likely many
rules and practices that are a function of the present environment.
Job shadowing is another excellent technique for understanding what is being done first hand. Often seeing
a task performed is more realistic than interviews or group sessions.
Gather some input and service time measurements from existing reports. If none exist, then it may be necessary
to do some data mining. You will need the assistance of the current IT staff to help gather the necessary
information. Architectural decisions cannot be made without an understanding of the volumes of input
requests and the volumes going through each task performed.
Once the business models are prepared from the exploratory work, the same people that were involved in
the exploratory sessions should be involved in a group review.
Many business decisions need to be made while defining an IT architecture. These decision, made by business people,
shape the resulting architecture. Advice regarding these decisions:
Make sure the right people are in the room. Choose representatives from the business that are empowered to
make decisions. On projects that change the business substantially this will generally require senior managers;
Track all decisions carefully: who was present, discussion points and dates, final decision and dates, attach
research and background material, the final record of decision (containing description of the problem, options
analysis, recommendation, sign-off);
Remind representatives of decisions taken at the previous meeting and obtain sign-off;
Record decisions in a database that is indexed, can be searched easily by keyword / date. This is needed down
the road when newcomers are trying to understand why certain decisions were made.
Discourage decision makers from changing their minds all the time—the occasional change in opinion is typical but
if decisions aren’t stable a project cannot move forward since many decisions build on other fundamental
The business events (and rules), business actors/roles, business entities, business activities and business locations
collectively completely describe the system, no more and no less. The Business Perspective viewpoints provide a
good, comprehensive picture of the system at an appropriate level of abstraction, appropriate for the objective of the
modeling, and the size of the organization being modeled.
Transition to the Logical Perspective
The Logical Perspective is the evolution of the Business Perspective with choices (and associated rationale) for the
transformation/realization. Some refactoring, of Business Entities, Activities, Locations and Processes may be done,
adding more detail (as needed) to describe the system at the logical level. Computational aspects are also added.