To find candidate business entities, consider what information each business actor handles. The information that must be queried, validated, created, or communicated is a good starting point. Only significant, persistent information should be considered as a business entity.

At this stage, no relationships are identified, nor required. The prime objective is to find the entities and develop clear, non–overlapping definitions for them.

For more information on business entities, see . Guideline: Business Entity and Guideline: Business Entity Model.

To find the primary business activities, consider what value each business actor receives from the business. Ask yourself what services the business actor expects to receive from the business. It might help to start with the core business activities — those that serve the customer, or the equivalent of the customer in cases in which there is no commercial interaction. For more information on business activities, see Guideline: Business Activity.

It is helpful to study the business actor's lifecycle to determine the answers to questions such as:

• What was the business actor's first contact with the business? 
• What stages or states does the business actor go through in relation to the business?
• What does the business actor regard as a meaningful interaction with the business?
• When is the business actor satisfied?
• What events does the business actor expect to be notified of?

Ask yourself what is required in order to deliver products and services to customers. Of course, the scope of "system" and the defined IT architecture objectives will determine the granularity of supporting business activities, if you are going to consider them at all. Look for the following kinds of processes:

• Development and maintenance of the staff;
• Development and maintenance of the IT within the business;
• Development and maintenance of the office and facilities;
• Security;
• Legal advice;
• Partner and contract management;
• Accounting;
• Logistics;
• Purchasing;
• Marketing analysis and research;
• Product development.

To identify management processes, look for activities associated with managing the system as a whole, as well as ones that normally interact with the owner roles. Consider what the owner roles receive from the business. Search for activities that:

• Develop and provide information about the business to owners and investors;
• Set up long-term goals;
• Coordinate and prioritize between the other business activities in the business;
• Create new processes in the business;
• Plan and execute improvements;
• Monitor the processes in the business.

Another way to identify business activities is to have domain experts describe every activity in the existing business. These activities are then grouped into business processes, which are named and briefly described.

You also must consider any defined business goals and events. Investigating business goals and events often discloses a business activity that otherwise would have remained undiscovered.

Processes can be represented as one or more business activities. Both business activities and processes are performed through the execution (by the system and business role) of business activities, usually in a specific sequence. These activities are the things that need to be identified and defined. Note they are high–level at this stage, and very much business oriented (as opposed to low–level logical activities such as reformat or persist).

The primary objective is to identify and develop clear definitions for the business activities involved in the "system" being architected.

See Guideline: Business Activity and Checklist: Business Perspective for additional information.

A business actor candidate is any individual, group, organization, company, or machine that interacts with the "system" such as:

• Customers;
• Partners;
• Suppliers;
• Authorities (legal, regulatory, and so forth);
• Subsidiaries;
• Owners and investors (Decide whether the board of directors should be part of the business or modeled as roles.);
• Information systems outside of the system.

If the system being modeled is part of a large company, these categories may also contain business actors such as:

• Other parts of the company;
• Individual actors within other departments.

It is very important to consider the scope and context of the system being architected. If it is only a portion of the enterprise, then the other parts of the same company also will be business roles.

Name each business actor in such a way that its name denotes its interaction with the system. Define each business actor by writing a brief description that takes into account its responsibility and why it interacts with the system, including the types of added value that the business actor wants from the business. See: Guideline: Users, Actors and Roles.

Finding actors is one of the first steps in defining the system use. An role represents each type of external phenomenon with which the system must interact. To find the roles, ask the following questions:

• Which user groups require help from the system to perform their tasks?
• Which user groups are needed to execute the system's most obvious main functions?
• Which user groups are required to perform secondary functions, such as system maintenance and administration?
• Will the system interact with any external hardware or software system?

Any individual, group or phenomenon that fits one or more of these categories is a candidate for an actor. Note that human actors (i.e. "users") may participate with the system in different roles (e.g. Researcher, Analyst, Writer are different roles of a newspaper reporter (human)). It is very important to try and identify these actors and ensure that they are well understood and well defined, since they greatly influence the design of the system.

To determine whether you have the right actors, you can try to name two or three people who can perform as actors, and then see if your set is sufficient for their needs. For more on what constitutes an actor, see: Term Definition: Business Actor and Guideline: Users, Actors and Roles. 

It may be difficult at first to find the most suitable actors, and you are not likely to find all of them immediately because you have not found all the business activities. Understanding business activities is the only thing that gives you a deeper understanding of the context and the interactions with the system. When you have progressed the model, you may want to revise your original model, because there is a tendency at first to model too many actors. Be careful when you change actors; changes that you introduce can affect the business activities as well. But remember that any modification to the actors may be a major alteration in the system's interfaces and behavior.

Name and Briefly Describe the Actors You Have Found

The actor's name must clearly denote the activity. Make sure there will be little risk at a future stage of confusing one actor's name with another.

Define each actor by writing a brief description that includes the its area of responsibility, and what the actor needs from the system. Because actors represent things outside the system, you need not describe them in detail, but they must be clearly defined.

A business location is any location that the "system" has a presence at and that interacts with the system such as:

• Customers;
• Partners;
• Suppliers;
• Authorities (legal, regulatory, and so forth);
• Subsidiaries.

If the business you are going to model is part of a large company, these categories may also contain business locations such as:

• Other parts of the company;
• Individuals or units located at customer sites.

It is important to note that locations are only of interest if there is some sort of interaction back to the "system's" primary (or other) location. In other words, there is some service or support interaction that needs to be modeled and implemented.

Locations are important in that the infrastructure and services supporting them needs to be understood. There may also be security aspects as well, such as those required for a bank to establish a set of ATM machines at various locations.

Locations, like the other aspects of the scope, are defined at a conceptual level. An "ATM" is a conceptual location, as opposed to a specific instance of an ATM at a specific location. The definition of locations should reflect the services and interactions involved.

Also see: Guideline: Business Location.

Determine what your sources are for the rules that govern the system. Some business rules are imposed on you from laws and regulations others might be company standards. Other business rules express the objectives of what the business modeling effort is to achieve. During the early parts of the project, it should be sufficient to identify these sources and determine the applicable types of business rules.

Business rules at this point are expressed in document form. Ensure that your selected notation, formality and style match the intended audience so that business rules can be effectively communicated, understood and agreed. For more on categories and styles for business rules, see Guideline: Business Rule. Check your results to verify that you have followed a consistent style when defining the rules and that they are not inconsistent in what they state. For help with this step, see Checklist: Business Rule.

Inspect the interactions between business actors, business entities, and business activities. Business actors may initiate a business activity by sending a business event. Business actors may send business events to business activities or to each other. If a message between two business actors has one of the following characteristics, it might be a business event:

• The sender of the message does not need to wait for the receiver to process the message;
• There is a significant lapse of time between when the message is sent and when it is received;
• There is a significant physical distance between sender and receiver;
• The receiver is in another business system. In this case, the business event must be sent to the business system and not directly to the business worker within it. 
• Business events may also be used to send signals between business systems and business use cases.

For more information on business events, see Guideline: Business Event.

See Guideline: Business Scope Workshop.