The Enterprise Business Modeling Discipline: Scaling Agile Software Development
Home  |  Contact Me  |  Licensing  |  Mailing List  |  Downloads  |  Site Map

Business modeling is an integral part of the Rational Unified Process (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 RUP's business modeling discipline but does so at the enterprise level. To be fair, the RUP product 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 for an explicit way to share information between projects.  The Enterprise Unified ProcessTM (EUP) extends iterative/agile processes such as the Rational Unified Process (RUP), Extreme Programming (XP), or Scrum with an Enterprise Business Modeling discipline. Enterprise business modeling is one aspect of enterprise discipline, a critical scaling factors for ensuring that agile approaches scale to meet the needs of your full IT organization.

Table of Contents

1. Overview
2. Define enterprise strategy
3. Model business processes
4. Identify process implementation options
5. Model the domain
6. Model the organization
7. Support project teams
8. Translations

1. Overview

The Enterprise Business Modeling discipline is important to the success of your IT organization for several reasons:

• It helps to 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.
• It helps to identify areas of your business that can be improved either through targeted automation or wide-scale business process reengineering. 
• It helps to identify business areas that your organization doesn't yet address or that your organization is very weak in.
• 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.

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.  Your enterprise business modeling efforts should explore a wide range of issues, and as a result, your enterprise business model is actually composed of a collection of smaller artifacts, such as:

• Enterprise business rules
• Enterprise business process model
• Enterprise domain model
• Enterprise mission statement
• Enterprise vision
• Organization model

The high-level workflow for the enterprise business modeling discipline is shown in Figure 1 and the detailed amalgamated workflow in Figure 2.  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 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 as well, 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 and simplified or reduced versions of common modeling notations for data modeling or process modeling.  In short, an important message of this discipline is that in order for it to succeed your organization must be as agile as possible: it is possible for enterprise-level professionals to work in an agile manner, but they must choose to do so and be allowed to do so.

Figure 1. The Enterprise Business Modeling Discipline workflow.

Figure 2. The amalgamated workflow of the Enterprise Business Modeling discipline.

2. Define Enterprise Strategy

A critical aspect of enterprise business modeling is to define your overall business strategy because it guides your business modeling efforts.  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.

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

3. Model Business Processes

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

• Your external environment. Before you can effectively model a business process, you need to understand the environment that 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.
• 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 the identification of 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 suggests that use case models should be used for business process modeling, the fact is that many options are available to you, such as data flow diagrams (DFDs) and UML activity diagrams, 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.
• 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 do 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.

Figure 3. Model Business Processes workflow details.

My 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, 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 (BEPL) or object constraint language (OCL), then you're definitely going into too much detail at this level.  Be as agile as you possibly can by creating models which are just barely good enough (JBGE) for the situation at hand -- you can always gather the details later.

4. Identify Process Implementation Options

Identifying areas for process automation is a key component of enterprise business modeling because it helps to put your IT efforts into 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 being implemented for it's own sake. Some processes will be fully automated, and some will be fully manual, but the vast majority will be somewhere in between. My philosophy is that the term "process automation" can bias people towards IT solutions when manual ones are not only viable but also better options; therefore I prefer the term "process implementation."  Similarly, 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).

Identifying potential ways to implement a business process is an art.  If it wasn't, every book store chain in the world would have seen the opportunity presented by the Internet and would have built their 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.

5. 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 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 of 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.

Some organizations will attempt a domain engineering approach where high-level domain concepts are implemented in a reusable manner, perhaps as domain components or collections of web services.  This approach requires significant sophistication within your organization, including a strong approach to enterprise business modeling as well as to enterprise architecture.  Domain engineering represents the pinnacle of strategic reuse.

Do not fall into the "One Truth Above All Else" trap.  If you strive to maximize stakeholder ROI you will quickly realize that the desire to ascertain the "one truth" proves to be little more than busy work in practice used to justify the data bureaucracy within your organization.

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

7. 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. I've worked on development projects in several organizations where I discovered that many times an enterprise business model is available but that the teams never think to take advantage of them, if they even know they exist. 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.  The strategies of the agile community, particularly around improved communication and collaboration, are absolutely critical to your success at enterprise business modeling.

8. Translations

• Japanese

9. Recommended Resources

The Enterprise Unified Process: Extending the Rational Unified Process by Scott W. Ambler, John Nalbone, and Michael Vizdos.  Whereas the RUP defines a software development lifecycle, the EUP extends it to cover the entire information technology (IT) lifecycle. The extensions include two new phases, Production and Retirement, and several new disciplines: Operations and Support and the seven enterprise disciplines (Enterprise Business Modeling, Portfolio Management, Enterprise Architecture, Strategic Reuse, People Management, Enterprise Administration, and Software Process Improvement).

Copyright © 2004-2009 Scott W. Ambler This site is property of Ambysoft Inc.  Agile Data (AD)  |  Agile Modeling (AM)  |  Agile Unified Process (AUP)  |  My Writings  | IT Surveys