Guideline: Business Perspective
UAM Home Page
This guideline provides an overview of the Business Perspective and considerations for its development.
Relationships
Main Description

Introduction

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.

Business Perspective

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 Model. 
  • 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.  

Naming Conventions

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.

Business Entities and Business Activities

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.

The Business Perspective and Information Systems

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 possible automation:

  • 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 Perspective.
  • 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 model. 

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 Perspectives. 

Systems as Business Actors

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.

Example:

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 one-on-one interviews.
  • 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. 

Business Decisions

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 decisions.

Characteristics of a Good Business Perspective 

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.