Enterprise Business Modeling: Enterprise Unified Process

The Enterprise Unified Process^TM (EUP) extends iterative/agile processes such as Disciplined Agile Delivery (DAD), Extreme Programming (XP), or Scrum with an Enterprise Business Modeling discipline. Enterprise business modeling is one aspect of enterprise discipline, a critical factor for ensuring that agile approaches scale to meet the needs of your full IT organization.

Overview
Define enterprise strategy
Model business processes
Identify process implementation options
Model the domain
Model the organization
Support project teams
Translations

1. Overview of Enterprise Business Modeling

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.

Enterprise business modeling activities

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 (click to enlarge).

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

It is quite common for organizations to mentor or train business analysts in process modeling skills and all developers in general analysis and modeling skills. 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 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.

8. Translations

Japanese