"All businesses have a business design. A business design describes how that business works—>the processes that it performs. A service is a repeatable task within a business process. So, if you can identify your business processes, and within that the set of tasks that you perform within the process, then you can claim that the tasks are services, and the business process is a composition of services."
This excerpt is from the article, "IBM's SOA Foundation—An Architectural Introduction and Overview" (see Resources). The article makes clear that the IBM vision of Service-Oriented Architecture (SOA) is not only about technology, but it is also about a business design that is founded on the composition of services to be provided by distinct and pluggable software components. This vision is the basis behind the need to integrate multiple products into a single solution where each product strictly collaborates with the others, providing superior customer benefit and value. While some architecture teams start their work on data models and technologies used among those products, this article starts from the customer benefit and value, trying to answer questions, such as:
- What are the customer values that those products can provide together?
- What are the customer problems and issues those products are trying to solve all together?
- Why should customers use the solution instead of each individual product?
The work described in this article was carried out in the context of the IBM Tivoli® Asset Management (IT AM) solution, which was developed to meet the need to respond to the customer demand to implement efficient processes for managing both hardware and software assets. Before that, IBM Tivoli was more focused on the Software License Management part of IT AM with the IBM Tivoli License Compliance Manager point-product, whose scope was mainly the management of the compliance of software licenses in the distributed environment. After acquisition of Isogon Corporation and MRO, IBM Tivoli portfolio was enriched with the IBM Tivoli License Compliance Manager for z/OS® and IBM Tivoli Maximo Asset Manager for IT products in the IT asset management space, making Tivoli a primary player in the arena of software for managing IT assets. Integration of those individual products, originally developed by different manufacturers, into one single product family could only be driven by the customer values and benefits, which is driven by the business perspective.
Understanding the design inputs
Business modeling and process analysis are well-established disciplines. Many books and articles are available (see Resources). There are organizations, such as the Workflow Management Coalition and Oasis, that take care of its standards. While modeling and analyzing business processes has been well-studied, there is no practical methodology for eliciting the processes themselves. Furthermore, business modeling does not help you understand how to link automated processes with user interaction, which is always required, at least to some extent. One approach is to look to the interaction design discipline for both business process elicitation and for a way to research the user interface definition.
Interaction design (IaD) is a goal-directed design methodology by Alan Cooper that aims to describe "how things behave and then, as necessary, to describe the most effective form to communicate those behaviors." Its perspective is from "an understanding of how and why people desire to use products." It is based on the following:
- The creation of personas, which are archetypal users of products with their goals, backgrounds, and mental models.
- The description of scenarios involving actions the personas want to perform and for which a product must be designed.
- The creation of storyboards of the product interface derived from persona scenarios and mental models, which then drive the rest of the product design.
Start your IaD work drafting persona hypotheses, which are a first cut at defining the different types of users to be used as a starting point for user interviews and observation. You can identify your persona hypotheses from personas already created, identifying similarities and differences, and looking at the collected interview transcripts from previous product releases in order to come out with a single set of personas.
In order to fill missing gaps, you can also leverage Information Technology Infrastructure Library (ITIL) roles and even try searching on Wikipedia. In order to express the entire set of design artifacts combined together in a single language, this article models persona hypotheses in UML. In particular, the article uses UML stereotyped classes to represent persona hypotheses, their roles, and their goals. This is basically the same semantic used to represent personas described in Modeling IaD personas.
The main difference between an enterprise product (such as a tool for scheduling jobs on a mainframe) and a consumer product (such as a cell phone) is that the former aims to automate business processes, while the latter aims to satisfy the needs of a user who is not within any process, but just wants to perform a task in the context of his or her personal life. For this reason, the design of a consumer product must encompass the tasks that the user wants to perform with the product (IaD context scenarios), while the design of an enterprise product must encompass both the business scenarios required to support the company's business and the concrete tasks that the final users have to perform with the product in their daily work in support of the business. Of course, there is a direct relationship between context scenarios and business scenarios for an enterprise: the former can be considered the implementation of the latter in the real life. Context scenarios bring to the business scenarios information about how workers actually complete the tasks required to reach the goals they have been assigned in the context of their businesses.
This article uses IaD context scenarios to elicit business processes. If effective context scenarios are the implementation of business scenarios, business processes can, in turn, be considered the abstraction of context scenarios coming from the user research. Therefore, after defining personas, you can develop complete and detailed context, arranging and describing them in such a way that you can easily transform them into business processes.
Understanding business design
This section describes the business process modeling tool, business processes, and some modeling tool tips.
Using a modeling tool
Business process modeling is not strictly computer aided, but doing so is highly recommended. This article uses IBM Rational Software Architect in order to achieve a full, consistent UML representation of the design. Using UML to model business processes can help in discovering missing parts or unclear relationships between activities and, more importantly, between different participants (business actors and customer stakeholders). But the most important benefits are that it aids thinking and collaboration between designers and that it allows a deeper analysis than can be achieved by simply writing text documents. While IaD means are irreplaceable for capturing and synthesizing user information that supports the optimal design of the user interface, you might find UML modeling to be essential in capturing information and visualizing the business processes that enterprise products must support.
Handling business processes and their actors
Write IaD context scenarios in the form of work flows with an appropriate level of detail and include variations in order to provide the most complete business implementation picture possible. If you chose to elicit business processes from IaD context scenarios, translate IaD personas into actors of the processes, such as business actors.
Start with the definition of customer stakeholders and their business goals. The inclusion of customer stakeholders is fundamental when designing a solution for an enterprise product, because their interests and priorities represent the business goals that the individual tasks performed by the primary personas aim to achieve. Identifying the aims of the customer stakeholders is the first step towards designing a solution that is not only usable but is also effective in supporting the business goals. Customer stakeholders do not exist for consumer products, and Alan Cooper quickly and simply suggests treating them as secondary personas.
Next, build the map of business processes, representing the flow of processes required to meet the business goals. Assign each process to an enterprise department in which it is executed. Drilling down from the map, create UML activity diagrams whose actions represent tasks to be possibly automated by the solution. This activity also leads to the first draft of a business data model, which is the collection of all the objects exchanged between business actors in order to complete business processes, such as reports, documents, and requests. These objects are called business entities. Business entities are discussed later in the article.
Finally, elicit business use-cases from activities within business processes, and associate them to both the business goals they aim to support and to the business actors responsible for them.
Figure 1 shows an example of the result of the activities just described, where the Software Asset Manager executes the Reallocate software licenses task in order to Optimize expenses for software, which is one of the goals for the IT Finance Manager.
Figure 1. Example of relationships between customer stakeholders, business goals, business actors, and business use-cases
Exploring some IBM Rational Software Architect tool tips
- Use colors to distinguish between actions that will not be automated by the solution (such as the negotiation of a contract) and actions that will be automated by the solution (such as the retrieval of a report of software installations). This facilitates subsequent business analysis and the sharing and reviewing of the models.
- Determine where you can decompose actions and generate sub-processes that can be reused within multiple processes. These are referred to as activity states, while other actions are referred to as action states. Early identification of these activities saves a lot of time.
- When you are sure an action is to be automated by the solution, do not create it as a call behavior action (an action that can be further decomposed and can lead to a drill-down diagram), because the tool adds the corresponding sequence diagram in the same package. You might want to keep the business design and the business analysis separate in the two different models. Later, after developing a sequence diagram, you can replace the simple actions with call behavior actions, linked to the sequence diagram.
Modeling from business processes to system design
This section describes business process details, business analysis, and system modeling. It also offers some use-cases for examples.
Defining business actors, business workers, and business entities
After modeling the business processes and identifying process activities that are eligible for automation in your solution (and so require further analysis), pin them down in more detail. This article does not go into a complete and formal description of this step, because it is already described in detail in the developerWorks article, "A proposal for a Unified Scenario Based Design Method" (see Resources). This article just highlights some crucial aspects.
Identify the person who is responsible for or initiates each automated activity and the person who carries out the real work. The former is a business actor while the latter is a business worker. For example, an Inventory Administrator initiates a wall-to-wall inventory, and he is responsible for its completion and accuracy. But, the physical verification of hardware locations is delegated to someone else, who goes around with a piece of paper and reads computer serial numbers, types, and models.
In order to understand how to partially or completely automate a process, an analysis of which business workers can be replaced by computer systems is required. In other words, only business workers whose tasks could be automatically executed by computer systems can be tagged as automated workers and called systems. Business actors who interact with a system become system actors and users of the system interface.
In order to complete the activity, business actors and business workers interact and exchange information, data, and artifacts that are called business entities. As explained later, business entities play a crucial role both in the user-to-computer system interface and in the interface among different computer systems. During the business process design activity, you identified most of the business entities as objects, which are the outputs of an action and the inputs for another or the same action. Nevertheless, during the business analysis phase, you refine them and find new ones. This should not be considered a sign of poor business design work. Analysis leads to a deeper understanding of what happens at the higher layer. Iterating across different, contiguous abstraction layers cannot be avoided to reach a complete and accurate design.
Completing business analysis
The business analysis work consists of defining sequence diagrams where business actors and business workers collaborate to complete the activity. This collaboration is realized exchanging messages and business entities.
Following are some suggestions for performing a good business analysis:
- Messages should have the appropriate level of detail. If they are too specific, the result is that you have described how systems work to respond to requests from business actors, while you only have to describe what they are required to do.
- Messages received by a business worker should be carried out by the worker in order to respond to the request in the message, such as Prepare software license compliance report. Messages received by business entities should be actions performed on the entity, such as Review content.
The sequence diagrams that describe how actions in the business processes are realized are called business use-case realizations. A business use-case realization can have multiple alternative flows, each of them being mapped to an activity within a business process. Each business use-case realization is then mapped to a business use-case, and each business use-case is linked to one or more business goals that it supports.
The whole picture is that customer stakeholders set business goals, and business actors perform activities in the context of business processes, which define business use-cases, which in turn support business goals. Systems (automated business workers) and human business workers do the dirty part of the job in support of business actors.
Figure 2. The big picture of business modeling
Going from business analysis to system modeling
So far you have been working on business actors, workers, entities, relationships, and collaborations. The next step is to move from the business domain to the system domain. In other words, you need to define how one or more computer systems can support the business by fully or partially automating the business workers.
Analyzing and modeling a system with UML through system use-cases, actors, and use-case diagrams is a well-established discipline. There is a wealth of published information on this subject, such as "Applying Use Cases - A practical guide" (see Resources). This article only highlights some key concepts.
As stated, automated business workers become systems. Those who interact with them are system actors. Because you might define multiple systems and find that some of them interact with others, some systems can also be system actors for other systems. Ultimately, each system can have both human and computer-automated system actors. For example, the Software License Management System has the Software Asset Manager (human) and the Inventory Management System (computer) as its own system actors. The former uses the Software License Management System, while the latter provides software inventory information.
Use the following procedure to derive use-cases from the business analysis:
- Create a use-case for each message a system receives. You probably have a lot of use-cases.
- Look for similarities, overlaps, and generalizations, and go back and update the business analysis work if necessary. If you do not need to, you are either the perfect business analyst, or you are going the wrong way.
- Refine and group use-cases using generalization, extension, and inclusion relationships.
At the end of this activity, the result is the drafting of use-cases that are organized into groups (a group being generally represented by a parent use-case generalized from others and, in turn, extended by or including others). Such results are very valuable at the next step—storyboarding time.
Creating user interaction use-cases and system use-cases
At this point, the models are ready to be worked out by the System Analysts and the extended design team, who follow up with all the tasks required to implement the systems.
After the initial review, the entire use-case model required to design the systems is not complete: all the use-case modeling of the internal behavior of systems was neglected. But, this is not surprising, because the work came out of interaction design research, which specifically models the business and the users. The missing use-cases can only be elicited from the system architecture that establishes technology and data model boundaries.
In this article, the use-cases derived from business processes are referred to as user interaction use-cases in order to differentiate them from the use-cases derived exclusively from the internal architecture of the systems.
Exploring more tool tips for IBM Rational Software Architect
When you start analyzing messages exchanged between business actors and business workers in order to create use-cases, the work can seem difficult because of the quantity of messages and their tangled relationships. It may help initially to create a use-case for each operation associated with a system. The tool automatically adds an operation to a business worker each time you create a new message whose target is the business worker. Then drag and drop the entire group of archetypal use-cases defined for the system into a use-case diagram for that system. This comprehensive view helps a lot with further analysis.
Continuing with user and user-interface modeling
As stated previously, business actors who interact with automated business workers, that is with systems, are actors for such systems, and therefore they are system actors in the system modeling layer. This means that they initiate use-cases. They are users of the interface of the same systems, and therefore they are users in the user interface modeling layer. This means that they initiate storyboards.
Modeling IaD personas
IaD personas can be modeled in UML using a specific, stereotyped class that provides attributes to model skills and goals. It is also possible to link them to system actors in the system modeling layer. End goals are UML classes stereotyped as user goals, linked to personas through association relationships. Such end goals are linked to use-cases from the system modeling layer through support-stereotyped dependency relationships. Because use-cases are derived from business use-cases, user goals implicitly support business goals, which is really important for an enterprise product (searching the Internet for cooking recipes could be a nice user goal, but not as useful for the enterprise business).
In the context of an enterprise product, it is also important to assign one or more user roles to each persona. Add dependency relationships between the personas and the user roles defined in the IaD preparatory work. This gives you the whole picture of the described models.
Figure 3. IaD persona modeling
Figure 3 completes Figure 2 and creates a first link between the business and the user designs. However, you have not yet captured one of the main outputs of the IaD research: the persona's mental model, which plays a key role in defining the user interface.
Modeling user concepts
People do not need to know all the details about how a complex artifact actually works in order to use it. There is a cognitive shorthand for explaining it: one that is powerful enough to capture interactions with it, but that does not necessarily reflect its actual inner mechanisms. This is how Alan Cooper introduces the concept of mental model, also known as the user conceptual model.
To model the user conceptual model in UML, here are two UML stereotypes: user objects and user views (also known as abstract views). User objects describe how the user perceives the objects to be dealt with, including their relationships. User views describe how the user imagines that such objects should be presented by the systems. IaD data elements and persona conceptual models can be modeled through user objects, while user views can represent a first link between the user mental model and the user interface. User views can be considered design artifacts that are very close to Cooper's user interface framework. However, Cooper's user interface framework is also based on functional elements, and you already have use-cases that are probably more powerful than functional elements to describe things the user wants to do with the system. Storyboards, which Cooper recommends you design starting from user interface frameworks, are created taking both use-cases and abstract views as input.
The user conceptual model still lacks a connection with the business (remember that the user of an enterprise application uses it for supporting or running the business, not for the pleasure of using it). Therefore, any object a user manipulates when interacting with one or more systems needs to have some connection with the business processes supported by the same systems. In the previous analysis, you already identified some objects that business actors (from which you derived system actors and, therefore, users) exchange with business workers (from which you derived systems), and you called them business entities. Start creating user objects from business entities, defining relationships between user objects on the basis of the existing relationships between business entities. In this way, you can produce conceptual models for each business actor and, so, for each persona. It is important to highlight that, while business entities are abstract objects within business processes, user objects describe how such abstract objects are perceived by personas who implement business processes through their tasks. The result is that the same business entity can have multiple user object representations, because different personas have different mental models.
The formal relationship between business entities and user objects is a refine-stereotyped dependency, while a display stereotype was introduced for the dependency relationships between user views and user objects.
Figure 4 illustrates the link between the user conceptual model and the business analysis.
Figure 4. Links from business entities to user views
User objects and personas are simply associated through appropriate packaging of the models.
The link just described completes the interconnection between the business design and the user model depicted in Figure 3.
Figure 5 shows the whole and definitive picture.
Figure 5. Links between business and user domains
Moving toward user interface design
At this point, you have user interaction use-cases derived from business modeling, and user views derived from user modeling. The part that is still missing is the user interface design.
Some methodologies, such as the Unified Scenario Based Design methodology (see Resources) already propose stereotypes for designing the user experience (UX) storyboards, which are UML representations of the user interface to be used together with the classic pencil storyboarding Cooper proposed. It is basically the UML UX modeling discipline, with its static and dynamic views of the user interface. The static view enables you to model panels using UI elements, which are appropriately stereotyped classes, such as screen, compartment, and input form. The classes have attributes of appropriate types, which represent the controls within the panels and the operations, which are either the actions the user can perform when interacting with the controls or the actions the user interface performs in response to user interactions. The dynamic view consists of sequence diagrams, whose lifelines are the user (user-stereotyped system actor), and the UI elements, whose messages are the operations exposed by the UI elements. Such sequence diagrams (which can be converted into more readable collaboration diagrams as explained in the book, "The Unified Modeling Language User Guide" in Resources) model the interaction flows of users with systems, and so they are called user experience storyboards. Classic visual storyboards are to be used in tandem with these tools to add look and feel and to facilitate review of the design with customers.
Because a user interaction use-case defines a boundary between a user and a system, you can design a UX storyboard for each use-case. While that is valid, storyboards can miss the business big picture. As discussed, each business process originates from multiple user interaction use-cases, so that designing the user interface focusing on the use-cases one-by-one can produce several independent flows that the user must follow in order to complete a wider task related to a whole process or to a part of it, which does not support ease of use. For example, if you design a UX storyboard for the search for an end-point use-case, you run the risk of creating a panel containing only controls for searching for end-points. But searching for an end-point only makes sense if some subsequent operation must be performed on the end-point, such as changing its location within the enterprise. Taking this into account, you might want to add other controls within the same panel for moving the end-point once it is found.
This consideration leads you to focus on groups of user interaction use-cases in order to avoid missing the wider context that surrounds each individual use-case. The final solution is to draft use-cases that are organized into groups. A group is generally represented by a parent use-case generalized from others, and in turn is extended by or includes others. Parent use-cases, which can be called main use-cases, can be considered access points to the systems by the users who are associated to them. As a result of such considerations, develop UX storyboards for each main use-case, keeping in mind all use-cases included in the group, and exploring any path from the main use-case to any other use-case when creating the UI elements that make up the UX storyboard. To support Create-Update-Delete (CRUD) generalizations, design multiple alternate flows for the same UX storyboard. Create partial UX storyboards for use-cases that are included in more than one use-case, and link these to the including use-case using references within the UX storyboard sequence diagrams.
Here is an example. In Figure 5, the main use-case of the group is the manage systems use-case. The UX storyboard that corresponds to it should have at least two alternate flows for removal and movement of systems (delete and update). When designing the UI elements that participate in the UX storyboard, remember that controls should be available for searching, moving, and removing systems. Also remember that a separate UX storyboard for searching for systems should be developed and reused within the main flows. The Search for systems UX storyboard should include two alternate flows: one that leverages common search criteria and another that leverages a shortcut for searching for end-points that are to be removed from the enterprise topology.
Figure 6. Example of linkage between UX storyboards and user interaction use-cases
In this way, you have the means of defining UX storyboards that fully cover and support the business by linking to any group of user interaction use-cases. So, how do you make them usable? How do you support the users?
Alan Cooper says that any user interface should reflect the mental model of its users. Because you developed a user conceptual model based on the IaD persona mental model, you can now design UI elements derived from the user views that were, in turn, designed starting from the user objects. In other words, draft UI elements that reflect the information contained in the user views and their relationships. Complete them with controls derived by the analysis of the use-cases associated to the UX storyboards in which the UI elements are included.
Figure 7 shows the relationships between the user interface model and the business and the user conceptual models. It definitively summarizes the entire modeling stack, including all the abstraction layers.
Figure 7. From the business and the user to the user interface
The loop is now closed. You designed a user interface that takes as input the needs of the customer stakeholders synthesized in the user interaction use-cases and the vision of the users, synthesized in their conceptual models.
Exploring even more IBM Rational Software Architect tool tips
Define a library of panel controls that extend the UML primitive types. You will be aware of the technology chosen by the development team for implementing the user interface, and you can mime the set of available widgets. You can use these types when adding controls to the UI elements, setting them as types for the UI element-stereotypes classes. When you partition a UI element into compartments (compartments are also stereotyped classes that represent panel frames), notice their dynamic behavior and reflect it through environmental operations, stereotyped with a special symbol, such as the $. For example, if the user clicks a button (a button-stereotyped operation) in the compartment A, this can cause compartment B to refresh, so add a refresh $-stereotyped operation to compartment B.
Figure 8 exemplifies a UX storyboard where the UI elements are a hub screen of end-points, an end-point information compartment, and an end-point selection form (contained in a compartment not shown). The inventory administrator user role opens the panel, searches for end-points, and selects one in order to review its data. The environmental operations are the display-found end-points and the display end-point information messages, which are originated by UI elements and not by the user. The other messages are operations whose stereotypes indicate the type of active control used for the interaction.
Figure 8. An exemplification of UX storyboard with environmental operations
Following the process outlined in this article, you applied both interaction design and business modeling and found along the way that some gaps had to be filled to get a full integration between these methodologies and, in consequence, between the business (stakeholder goals) and the user (ease of use). The result is an outside-in design usage pattern. This article includes many well-known concepts and steps along with some practical tips for you to apply to your solution.
The first key point in the usage pattern is a way to leverage IaD not only to understand the user, but also to understand the business. A single interviewee cannot have a high-level picture of the business, but putting real data together and matching them against more theoretical best practices (such ITIL recommendations, marketing information, and trusted business whitepapers) can produce a complete, detailed, and concrete result. At the end of your research, analysis, and design, you will understand both the business and the user.
The second key point is a consequence of the first, to some extent. You have understood the business and the user domains, but you have to integrate them into a single model. This is the only way to design a solution that effectively supports the customer's business and is easy to use by those who run the customer's business. The integration consists of translating the abstract objects created and manipulated by the business processes into things that are familiar to users, easy to understand, and that reflect users' mental models. Because all the required information is available, you simply need to find and model the appropriate connections and relationships between the business data model and the user conceptual model, keeping in mind that each user can have a different perception of the business.
- Review IBM's SOA Foundation - An Architectural Introduction and Overview - Version 1.0 by Rob High, Stephen Kinder, Steve Graham, to see the SOA Foundation as defined by IBM and to be guided to a wealth of existing information on SOA.
- See Effective Business Modeling with UML: Describing Business Use Cases and Realizations - November 2002 by Pan-Wei Ng for an overview and some practical hints about business use-cases and business use-case realizations.
- Consult About Face 3: The Essentials of Interaction Design - Version 2.0 by Alan Cooper, Robert Reimann, and David Cronin for a book about interaction design.
- Refer to A proposal for a Unified Scenario Based Design Method - Version 1.5 by Roberto Longobardi, Alex Donatelli, Rosario Gangemi, Claudio Marinelli, for a visual, UML-based modeling methodology to link automated processes to system analysis and design.
- Look at The Unified Modeling Language User Guide - 2/E by Grady Booch, James Rumbaugh, and Ivan Jacobson for the definitive user guide of UML.
- Check out Applying Use Cases - A practical guide - 2/E by Geri Schneider and Jason P. Winters for a clear and practical introduction to the cutting-edge software development technique: the use-case analysis.
- The SOA and Web services zone on IBM developerWorks hosts hundreds of informative articles and introductory, intermediate, and advanced tutorials on how to develop Web services applications.
- The IBM SOA Web site offers an overview of SOA and how IBM can help you get there.
- Stay current with developerWorks technical events and webcasts.
- Browse for books on these and other technical topics at the Safari bookstore.
Get products and technologies
- Innovate your next development project with IBM trial software, available for download or on DVD.
- Participate in the discussion forum.
- Get involved in the developerWorks community by participating in developerWorks blogs.
Dig deeper into SOA and web services on developerWorks
Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.
Experiment with new directions in software development.
Software development in the cloud. Register today to create a project.
Evaluate IBM software and solutions, and transform challenges into opportunities.