The Enterprise Business Modeling Discipline: Scaling Agile Software Development
|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.||
The Enterprise Business Modeling discipline is important to the success of your IT organization for several reasons:
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:
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.
|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;
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.
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:
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.
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.
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.
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.
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.
|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).|
This site owned by Ambysoft Inc.