This workshop focuses on finding business actors,  business functions, business locations and business entities involved in the system to be architected, thus defining the Artifact: Context and Objectives of the IT architecture. Extra detail is gathered regarding the business activities, useful in the next step of defining the Artifact: Business Perspective, such as process details, entities involved, actors involved and related business locations.

Organization of the Workshop

The business scope workshop is an organized brain-storming meeting, focused on finding and defining various aspects of the system under study using business language. A wide range of knowledge needs to be represented, depending upon the focus of the architecture effort; but the focus is on the business—business knowledge is of paramount importance. This means that the group will contain people with different backgrounds, knowledge and experience, but with the emphasis on business people that are experts on the system. The group  is kept small (less than ten). At this point a large portion of the team is composed of business representatives. In the middle of this is the facilitator. The facilitator should play the role of a moderator, with no judgments made—all the information is simply captured.

Tools

In addition to a comfortable room, the moderator should have:

• White boards and easels (the more the better);
• Masking tape;
• Multiple colors of self-stick notes pads; 
• White-board / easel pens (multiple colors);
• Plenty of wall space.

Defining Actors 

Try to identify who or what interacts with the system. Start initially with actual people who interact with the system; focus on the concrete. As actors are identified, try to identify the activities that each one interacts with—this is usually a good starting point for naming the Term Definition: Business Actor and also helps in finding the activities.

Write and agree to a short description for each actor; usually a few bullet-points capturing the activities they interact with.

When defining actors, do not forget about external interactions with the system. Also, don't forget that an Actor may also represent an automated system. Find the 'human' actors first, then consider the more esoteric.

The structure or relationships between actors is not important at this point—focus on their relationships with the system and the capturing of the business activities that the actors interact with. Capture, name and define these activities as well.

Define Business Activities, Business Entities and Business Locations 

Start to identify (in the context of IT architecture) Business Activitys. Focus on concrete business activities (avoid discussions about structuring or reuse of activities). Use a square for the Artifact: Business Activity and write the name for every suggestion. Use arrows to the associated Artifact: Business Actor.

Have the participants describe what the business is supposed to do, in context of the system under study. Ask a lot of questions about the business, its activities and entities. When the participants provide you with explanations many business aspects will be defined: entities, processes/activities, locations and actors.

Some people can understand the concept of business activities right away, and some people cannot. A more physical view of the activity is helpful (i.e. the current situation). For example, describe a number of specific clients and their interactions with the system with a number of specific business departments and their special tasks defined. This more concrete view will help to make the business functions extend from one end of the business to the other, and may point at a number of different business (activity) states. Ask questions about these states, and some more business functions will appear. Optionally explore what will happen when different interactions or functions break—this can help you identify alternative flows in the business functions .

A diagram describing the business processes may be useful. The diagram may describe how a business entity is moved from one person to another and what they are supposed to do with it. This diagram may also get very physical, specific physical office or departments may be included if helpful. 

Allow the business activities to have long names. A recently identified activity may have a name as long as a sentence—this will be a good start on the brief description of the activity; the name will be shortened later on.

There will always be a number of business activities that appear to have parts in common. This is acceptable for now; do not attempt to structure activities, since we don't know enough about the business activities. Wait until after the the complete workflow has been defined and properly modeled (i.e. during an architectural review later on).

The definitions are complete when the group agrees that all the business actors, processes and activities defined cover the functionality of the system.

Write a Brief Description for each Business Activity

Work with the business activities one by one, and create a graphical representation. Ask the group to help you write a brief description of the business activity. It should be about 1 to 3 sentences. Sometimes it is useful to draw the Actor associated with the business activity, the same may be done with business entities, but do not clutter the diagram, which may confuse participants. 

Do not be surprised if you discover that there are some things that everybody thought were clear that are not actually clear at all. Also, note any non-functional and other requirements or constraints that the business experts mention.

New business activities may be added as the discussion proceeds, and perhaps some will disappear. Put these business activity descriptions on the walls. If you can't solve questions immediately, write them down on a self-stick note and place them at the appropriate business activity description. Use one color for questions.

When all business activities are described along with associated entities, actors and locations then the scope has been defined. It is often wise to take some time discuss if all the business activities are indeed found.

After the meeting the all business level elements are properly documented in a Artifact: Context and Objectives.

Capture Non-functional Requirements

Capturing non-functional requirements is optional during the definition of Scope and Context. During the meeting, there will be several requirements on the system that you may not be able to readily capture in an activity. Typically, these statements have to do with usability, reliability, performance, and supportability of the system. Keep a separate chart where these are noted. 

Define the Context

The context of the system defines the environment in which the system operates. This step essentially defines the domain specific language used (e.g. the industry, such as Banking or Aerospace). This also relates to the scope of the system since the domain specific language also depends upon the scope. 

Final Review 

• Ask if there is anything missing;
• Present the results in your own words—the business experts will correct any errors or omissions;
• Review definitions of activities and other items;
• The collation, de-duping, analysis and documentation (i.e. creation of the Artifact: Context and Objectives) is done after the workshop.

Brainstorming  the Business Scope should takes between 3 and 6 hours: a single days session.