The Enterprise Business Modeling Discipline

This chapter is from the book

Enterprise Unified Process, The: Extending the Rational Unified Process

Learn More Buy

This chapter is from the book

This chapter is from the book 

Enterprise Unified Process, The: Extending the Rational Unified Process

Learn More Buy

Reader ROI

• Enterprise business models should provide high-level overviews, not onerous details.

• Enterprise business modeling should occur on a regular basis throughout the life of your organization.

• Enterprise business models explore the businesses processes, external environment, organization structure, and critical business entities pertinent to your organization.

• Your enterprise stakeholders must be active participants in the development of your models.

• Involve the actual stakeholders for your enterprise business models when you're developing them to ensure that the models reflect their requirements.

Business modeling is an integral part of the RUP. The existing RUP business modeling discipline provides a view of the business structures and processes of the organization relative to a specific project, identifying the proper scope of the project and showing how the system fits into and supports the business. This is incredibly important for a project, but it isn't sufficient for the enterprise; the enterprise business modeling discipline encompasses the same activities as the business modeling discipline but does so at the enterprise level. To be fair, the RUP product (IBM 2004) does describe the need to model at the enterprise level, but because there is no mechanism within RUP to depict cross-system issues adequately, it doesn't do the concept justice, nor does it provide an explicit way to share information between projects—hence the need for this discipline within the Enterprise Unified Process (EUP).

Carr (2004) makes a very good case that most information technology (IT) investments do not provide competitive advantages for the organization implementing them. He points out that if all of your competitors implement or buy a customer relationship management (CRM) system or an enterprise resource planning (ERP) system, there is very little chance that you will gain a competitive advantage by doing so. And you know what? He's right. To succeed, you need to look beyond IT and consider the larger picture—that of the entire business process (Smith and Fingar 2003). This is why enterprise business modeling is required for your organization to succeed—it takes an organization-wide viewpoint when modeling the processes, structure, and external environment of your business. Your goal is to provide the context that your IT department supports and works within—fundamentally, all business software is embedded within business processes, and a business system isn't successful unless the business is (Poppendieck and Poppendieck 2003).

Your enterprise business modeling efforts should explore a wide range of issues. As a result, your enterprise business model is actually composed of a collection of smaller artifacts (see Table 7-1). The business issues that you should explore include the following:

• Business entity types: Something of interest to your enterprise, such as a person, place, thing, or concept. Business entities within a bank would include Account, Customer, and Branch. Business entity types will typically be captured within your enterprise domain model.

• Business environment: Your external business environment includes your customers, suppliers, partners, and competitors. Note that these are not mutually exclusive groups, for you may find yourself competing against some of your customers. Your business environment is also defined by the rules and regulations (which are defined by government legislation and industry governance bodies) that constrain your activities. Examples of such legislation within the United States include the Sarbanes-Oxley (Sarbox) Compliance Act (U.S. Government 2002) and the Health Insurance Portability and Accountability Act (HIPAA) (U.S. Government 2004). Your business environment will affect all aspects of your enterprise business model, although it will be most explicitly depicted by your enterprise business process model.

• Business processes: A collection of coordinated activities, either manual or automated, that provides value to one or more internal or external clients. Business processes within a bank would include generation of account statements and fulfillment of retail banking transactions such as deposits and withdrawals. Business processes should be described within your enterprise business model.

• Business rules: Constraints that influence or guide the everyday workings of an organization. Within a bank, a potential business rule would be that monthly interest for a checking account is calculated by multiplying the interest rate by the lowest balance within the account that month. This is captured within your enterprise business rules specification.

• Locations: An enterprise must know both the physical and virtual territories where it does business. For a bank, this would include places such as Canada, Germany, the state of Alaska, the British Isles, and the Internet. This is depicted by your organization model.

• Management concerns: This includes a definition of the mission and vision for the organization as well as associated long-term plans. They are captured within your enterprise mission statement and enterprise vision.

• Organization structure: This consists of the organizational units (teams, groups, divisions, and so on), the people or positions within the organization, the roles that the people and organizational units fulfill, and the relationships between them all. The organization structure of a bank would indicate the various divisions (for example, retail banking and corporate banking), the international groups within the bank (for example, North America and Continental Europe), and the senior executives within each division. This is captured within your organization model.

TABLE 7-1: Components of an Enterprise Business Model

Development of the enterprise business model starts with a broad view of the entire business. This doesn't mean that you'll model your entire business—for example, you may choose to ignore the accounting aspects of your organization because it's stable—but it does mean that your model will go beyond the scope of a single project. Your goal should be to capture the fundamentals of your business by working with your stakeholders in an all-encompassing yet shallow model—you don't need much detail, but you do need breadth. You need to identify and prioritize areas of importance so that they can be explored in detail by the business modeling efforts of individual project teams. Your enterprise business model should define an accurate, high-level overview of the business and should contain information that is relatively stable over time. For example, within a bank, the need to process retail banking transactions has existed for centuries, yet the way in which this occurs has changed dramatically over time—the high-level need is stable, whereas the details are very fluid.

Enterprise business modeling is important to the success of your IT organization for several reasons. First, it helps facilitate a common understanding of the business that your organization is engaged in. Although this may seem superfluous to some, formally documenting the business that your organization engages in will lead to many interesting conversations about how things should really work and, ultimately, to a shared understanding of exactly what business you are in and how you execute your work. Second, it helps identify areas of your business that can be improved either through targeted automation or wide-scale business process reengineering. Third, it helps identify business areas that your organization doesn't yet address or that your organization is very weak in. Fourth, it provides important information to project teams that can help them to delimit the scope of their project, in particular helping them to identify how their effort fits into the overall business.

Enterprise business models are used to depict both "as-is" and "to-be" views; this is important for strategic planning because changes in strategic direction can be mapped out and examined before they are implemented. Senior management, not just IT implementers, can benefit greatly from enterprise business modeling that is forward-looking. Because they are developing a shared vision together, it can often be the impetus that gets business and IT executives working together effectively in organizations where a divide exists between the two groups.

From a technical point of view, an enterprise business model can be used to identify common concepts that should be automated and reused repeatedly in systems. Enterprise architects, working with reuse engineers, can examine the domain model within the current and targeted areas of automation to identify potential domain assets, a concept called domain engineering. Implementation of these assets can lead to increased efficiencies in system development efforts by reducing both development and maintenance costs (Chapter 10).

Workflow

The workflow for the Enterprise Business Modeling discipline is shown in Figure 7-1. A critical success factor for this discipline is your relationship with your enterprise stakeholders, which includes senior IT executives, senior business executives, suppliers, customers, and domain experts (often senior business analysts). Agile Modeling (http://www.agilemodeling.com) promotes a practice called Active Stakeholder Participation. Not only should stakeholders be available to make decisions and provide information in a timely manner, but they also should be actively involved with your modeling efforts, something that is possible when you work with inclusive tools and techniques that are easy to learn and work with. Inclusive tools include paper, whiteboards, and word processors; inclusive techniques include essential use cases (Constantine and Lockwood 1999; Ambler 2004) and simplified or reduced versions of common modeling notations for data modeling or process modeling.

FIGURE 7-1 The Enterprise Business Modeling discipline workflow.

Define Enterprise Strategy

A critical aspect of enterprise business modeling is to define your overall business strategy because it guides your business modeling efforts. The workflow diagram is depicted in Figure 7-2. Work closely with your enterprise stakeholders to develop the enterprise business strategy—the strategy must come from and be accepted by the business; it isn't an IT-only strategy.

FIGURE 7-2 Define Enterprise Strategy workflow details.

Enterprise business modelers will work closely with the enterprise stakeholders to define the goals, targets, and vision for your enterprise. Options for doing this include facilitated modeling sessions such as joint application development (JAD) meetings (Wood and Silver 1995), less-formal agile modeling sessions, or separate one-on-one interviews. Your goals and targets are typically short-term, such as to grow the number of corporate banking customers (the goal) by 2% this quarter (the target), and are therefore likely to change on a regular basis. Your vision, such as to become the largest retail and corporate bank in North America as measured by managed assets, is typically longer-term and therefore less likely to change over time. It's important to have an overall vision—if you don't know where you're going, you'll never get there.

There is more to this effort than simple brainstorming—you must assess your organization's capability to fulfill your goals. One aspect of this capability analysis should be to simply ask the appropriate people what your organization is capable of achieving, what its core competencies are, and what its overall weaknesses include. This approach works in an organization that has a culture of open and honest communication, but it will often result in an overly optimistic (and grossly inaccurate) assessment when this isn't the case. Facilitation by an outsider, usually a consultant, should be considered when you are unable to assess yourselves accurately. An outsider can lead you through politically sensitive challenges without fear of political repercussions.

You will then need to develop strategies to address the gap between what you can do and your vision for what you want to achieve. Your strategies, which will change over time, will be captured within your enterprise mission statement. An enterprise mission statement defines the ongoing operation activity of your organization and is the means to achieving your enterprise vision (Hay 2003). Your enterprise vision and mission statements should be concise—often a paragraph and a collection of five to eight points.

For example, consider a company that is a collection of martial arts studios. The vision might read, "The XYZ Schools will help their students improve their minds, bodies, and spirits through training in the martial arts." The mission statement may contain the following points:

• XYZ Schools will offer training in Goju Ryu karate, Kobudo, Ju Jitsu, and Taoist Tai Chi.

• Both adults and children (at least six years of age) will be encouraged to train.

• Martial arts philosophies and history will be intertwined into training classes.

• Respect for family, self, and country will be encouraged in training classes.

• XYZ Schools will work with external experts to bring specialized skills to their students.

• Camaraderie between students will be encouraged. We should be able to have fun while we're learning.

Figure 7-2 indicates that you should review your enterprise strategy, but this is only one way to validate the quality of your work. Reviews compensate for overly serial processes and for a lack of collaboration during the development of an artifact (Chapter 3). If you follow a more agile approach, you don't need to compensate by holding a review.

A strategy map (Kaplan and Norton 2004) is a style of flow chart that is a useful technique for validating your enterprise strategies. Strategy maps model specific processes, competencies, cultural attributes, and technologies, showing how these elements are connected to satisfying customers and increasing long-term shareholder value. By creating strategy maps, you approach the issue from a different angle, providing opportunities to validate and hopefully improve your enterprise mission statement.

Model Business Processes

The modeling of business processes is one of several modeling activities within this discipline, the workflow details of which are presented in Figure 7-3. Your business process modeling efforts address the How (Function) column within the Zachman Framework (ZF) (Chapter 3) and should reflect both your enterprise mission and vision. Your business process model should describe the following:

• Your external environment: Before you can effectively model a business process, you need to understand the environment it exists within. You must identify your customers, in particular their needs (some of which are perceived and some of which may be motivated by your sales and marketing efforts). You must also identify the suppliers/vendors/partners of services and materials to your organization—perhaps you work with courier companies as part of your order fulfillment process. An important part of your environment is your competition—your rivals will be doing their best to lure your customers away from you by offering better value. Your competitors may not always be obvious, and who they are will change over time. For example, Wal-Mart was seen as a primary competitor of department stores and smaller specialty shops for years, yet it was not perceived by grocery stores to be much of a threat. Then in the late 1990s, Wal-Mart entered the grocery business with its superstores and has put hundreds of grocery stores out of business as a result.

FIGURE 7-3 Model Business Processes workflow details.

• Business processes: The business processes of an online retailer would include marketing, sales, order fulfillment, inventory management, and government reporting. An important part of enterprise business process modeling is identifying the offerings (services and products) your organization provides to your customers, what you want to provide, and what you would like to stop providing. The next step is to identify, at least at a high level, how you go about (or should go about) doing so. Although the RUP product suggests that use case models should be used for business process modeling, the fact is that many options are available to you, as summarized in Table 7-2, and you should choose the ones that are best suited for your environment. Some models are good for logical process modeling, where you focus on what you need to accomplish but not how you'll do it; others are well-suited for physical modeling, where you focus on how the processes are accomplished. Some models can be used for either. Many of these models are described, with examples, at http://www.agilemodeling.com/artifacts/.

• Critical business rules: As you explore the business processes within your organization, you will also identify critical business rules that you should capture. Your goal should be to focus on capturing the fundamental idea, such as the rule that a bank will charge a monthly fee for checking accounts, but to not go into the details (for example, specify what to charge for each type of account but not how to do it). Enterprise business rules should stand the test of time—they should describe business policies that will very likely still be in effect years from now.

TABLE 7-2 Potential Business Process Modeling Artifacts

Our experience is that effective enterprise process models are mostly if not completely logical in nature. This is because the fundamentals of what your enterprise is trying to accomplish change slowly over time, whereas the physical aspects of what you do can change quite rapidly. Furthermore, enterprise models, including both business and architecture models (Chapter 9), should be very high-level. Details, although important, are better left to specific project teams. If you find yourself documenting the specifics of a business rule or business process, perhaps in something like business process execution language (BPEL) or object constraint language (OCL) (http://www.omg.org), you're definitely going into too much detail at this level.

An emerging standard is the Business Process Modeling Notation (BPMN) from the Business Process Management Initiative (BPMI) (http://www.bpmi.org). The BPMN specification defines a (potentially) standard graphical notation for expressing business processes. Figure 7-4 applies BPMN to depict the business processes of managing XYZ Schools. Figure 7-4 is a simple model; a good enterprise business process model should capture the fundamental processes. The objective of BPMN is to define a notation that is intuitive to business users yet still sophisticated enough to represent complex process semantics for the developers. In addition to the basic process flow and activities depicted in Figure 7-4, it is also possible with BPMN to depict swimlanes (which indicate who/what performs activities), data flows, and message sends. At the time of this writing, BPMN v1.0 had just been released, and many people within the business modeling community seem to be accepting it. Our suggestion is that you keep an eye on this emerging standard but beware of the hype. The important thing is that IT and business stakeholders work together—the shapes of the bubbles and lines they draw when doing so aren't nearly as important.

FIGURE 7-4 A business process diagram for XYZ Schools.

Identify Process Implementation Options

Identifying areas for process automation is a key component of enterprise business modeling because it helps put your IT efforts into the context of the overall organization. IT must be viewed as an enabler of your business, not an end unto itself. Putting automation in the context of the business ensures that technology is not implemented for its own sake. Some processes will be fully automated, and some will be fully manual, but the vast majority will be somewhere in between. Our philosophy is that the term "process automation" can bias people toward IT solutions when manual ones are not only viable but also better options; therefore, we prefer the term "process implementation."

Figure 7-5 depicts the workflow details for identifying process implementation options. New ideas for projects will be identified during the discussions, and information will then be provided to the portfolio management planning efforts in the form of a very informal project proposal (which could be something as simple as a few sentences on a whiteboard).

FIGURE 7-5 Identify Process Implementation Options workflow details.

Identifying potential ways to implement a business process is an art. If it weren't, every bookstore chain in the world would have seen the opportunity presented by the Internet and would have built its own version of Amazon.com. Furthermore, determining implementation strategies can be very difficult: the goal is to identify what to automate, what to perform manually (you'll still want to find ways to improve your manual processes), and what style of business process interactions you need between the various sub-processes. To identify effective implementation strategies, we advise you to do the following:

• Leverage people: People are very good at handling situations involving inconsistent or incomplete information, situations where computer systems struggle. Therefore, you want to find ways to provide good-enough information (even if it's not perfect) to help people make informed decisions. Don't try to automate things at which people are well suited.

• Automate repetitive tasks: Computer systems are good at processing vast quantities of information and relatively straightforward tasks; therefore, automate these things.

• Focus on financial return: The tasks that you automate should have both a positive return on investment (ROI) and a relatively short payback period. As a general rule, if it will take more than two years to recoup your investment, you should consider a different strategy, because your business environment likely changes too fast to allow you more than two years to benefit from the new system. Spend what is required but no more to achieve essential differentiation via business processes and the IT systems that support them. Estimating, at least roughly, the actual ROI, payback period, and other financial statistics is an activity of the portfolio management discipline (Chapter 8). However, effective business modelers will always consider financial implications to ensure that they invest their time wisely.

Model the Domain

An important part of enterprise business modeling is the creation of a high-level domain/conceptual model that depicts the main business entities and their relationships that are of interest to your organization. This model, which does not need to be very detailed, is valuable input into the enterprise data modeling efforts of your information administration group (Chapter 12) as well as the requirements and business modeling efforts of project teams. In both cases the enterprise domain model provides a basis from which to begin more-detailed modeling efforts—the project teams won't have to reinvent your domain model each time. In parallel you will also create an enterprise business glossary, which defines a common vocabulary within your organization. This enterprise business glossary is a valuable resource that should be shared with all your project teams. It doesn't make sense for individual project teams to define common business terms such as "customer" over and over again because this can lead to wrong assumptions and incorrect data. Instead, teams should reference the commonly accepted enterprise business glossary and then focus on the terminology that is unique to their effort. This is an example of artifact reuse (Chapter 10). The workflow details for enterprise domain modeling are shown in Figure 7-6.

FIGURE 7-6 Model the Domain workflow details.

You have several options for enterprise domain modeling, as summarized in Table 7-3. Although several types of models are described, the bottom line is that at this level of modeling it really doesn't matter which one you choose, as long as it gets the job done. Your enterprise domain model should be very slim, showing boxes representing business entities that are connected by lines that represent relationships. The boxes should be labeled with the name of the business entity (for example, Customer and Order within an e-commerce organization), and the lines should have a label representing the relationship between the entities (for example, places) as well as the multiplicity of the relationship to indicate how many of each entity is involved (for example, a customer places one or more orders). That's it. Any more detail, such as an indication of data attributes or operations of an entity, is better left to the more-detailed modeling efforts described in Chapter 12. Figure 7-7 depicts a slim domain model for XYZ Schools, which uses the UML 2 class diagram notation. Because the model is so simple, which notation you choose doesn't really matter, as long as the model's audience understands it. Furthermore, you can and should take liberties with the notation to make your diagrams inclusive for non-technical stakeholders. Note that it is very common for diagrams like this to include more than 100 entity types. Figure 7-7 is smaller because the domain is limited in scope.

TABLE 7-3 Potential Enterprise Domain Modeling Artifacts

FIGURE 7-7 An enterprise domain model for XYZ Schools.

Model the Organization

Your organizational structure is what enables you to implement your business processes, and the two must be aligned if your organization is to succeed. Most people think of organization modeling as the creation of an organization chart, which depicts the reporting structure of your senior executives. That's important information, but it's just a start. A true organization model describes your organizational units (teams, groups, divisions, and so on), the primary positions, the senior people, the roles and responsibilities that the people and organizational units fulfill, and the relationships (potentially including both reporting and flow of control) between them all. The workflow diagram for organization modeling is depicted in Figure 7-8.

FIGURE 7-8 Model the Organization workflow details.

Your enterprise business process model identifies what your organization wants to achieve. This is valuable information when you're modeling the structures that will help you do so. The following list includes our advice for each aspect of the model:

• People/position reporting structures: You don't need to model each and every position and person within your organization; however, you do need to identify the fundamental roles and reporting structures. Keep your models simple and concise; you probably need a lot less documentation than you think.

• Location modeling: You need to identify the territories in which you're doing business because the regulations and customs within those territories will constrain the way in which you do so. Note that territories may be physical, such as the Canadian Maritime Provinces, or they may be virtual, such as the Internet. You will also need to know where all your main offices or manufacturing plants are, but in the case of organizations with many stores (for example, Starbucks locations) or branches (for example, HSBC bank branches), an estimated count by territory is likely sufficient. Model to the level of detail that is appropriate to your audience, and no more.

• Organization units: Organization units may cross-cut both your reporting structures and location structure. For example, a business development team may be made up of people from around the world, each reporting to a different director. This aspect of your model may simply be a list of major teams within your organization, a brief description of the team's charter, and an indication of who is sponsoring and/or leading the team. This information will help provide insight into the tactical working infrastructure of your organization.

• Organizational relationships: Model the high-level relationships between your organizational units. Limit your models to the relationships that define your overall business goals. For example, in your organization, your Marketing unit may be chartered to identify new product opportunities that the IT or Development unit will produce. Approval of that product development would result in a notification to the Sales unit and the Operations and Support unit so that they can begin preparing for the eventual delivery and support of the product. We recommend that you not model low-level, tactical relationships between these organizations; for example, do not include the acceptance criteria that Quality Assurance presents to IT for all products submitted to system and acceptance testing.

Figure 7-9 depicts an organization model for XYZ Schools. The diagram is simple—the company is small, after all—but it captures critical concepts. Various roles exist—external experts who teach additional seminars to students, senseis (senior martial arts instructors) who run their own schools, and a pool of instructors who teach classes at one or more dojos (martial arts schools)—and various relationships exist between them. Remember that one person can fill more than one role.

FIGURE 7-9 An organization model for XYZ Schools.

Support Project Teams

It isn't sufficient to simply create enterprise business models and give them to your project teams because they probably will simply ignore the models. We've worked on development projects in several organizations where we discovered that many times an enterprise business model is available but the teams never think to take advantage of it, if they even know it exists. Successful enterprise business modelers communicate their work to development teams and are willing to support the teams in taking advantage of the enterprise business models.

Figure 7-10 depicts how enterprise business modelers will support project teams. It is quite common for them to mentor or train business analysts in process modeling skills and all developers in general analysis and modeling skills (Chapter 3). It is also common for enterprise business modelers to take an active part on development teams, often in the role of business analyst. They will also develop and maintain appropriate modeling guidelines and standards (guidance) for enterprise business modeling. This guidance is often something as simple as the selection of standard modeling notation, such as BPMN or UML 2, as well as guidelines for effective models (visit http://www.agilemodeling.com/style/ for a collection of suggested modeling guidelines). Your enterprise stakeholders should be part of the review process for your modeling guidance because they are an important part of the audience for your enterprise business models. In addition, you need to ensure that your guidance describes how to develop models that stakeholders will understand so that they can be actively involved in modeling.

FIGURE 7-10 Support Project Teams workflow details.