The ICONIX Business Modeling Roadmap
Doug Rosenberg
ICONIX Software Engineering, Inc.
While ICONIX primarily provides training and consulting to software
projects and organizations, we occasionally are requested to provide guidance
to companies who are modeling business processes. In many cases, these
business process engineering efforts are a precursor to software system design,
and there is a natural desire to maximize commonality between the business
modeling process and the software design process which will subsequently followed,
which is often ICONIX Process.
Based on our experience in helping a number of business process engineering
projects over the last few years, we have developed the ICONIX
Business Modeling Roadmap ; a set of activity diagrams which
detail our simplified approach to business modeling and is the subject of this
paper.
Similarities and differences between software design and business
modeling
Before we can leverage our experience in modeling software projects
and formulate a compatible strategy for effective business modeling, it's
important to understand what's similar and what's different between these
two endeavors.
Business modeling and software design are similar in a number of ways; to begin
with both business processes and software designs are best understood by modeling scenarios . In
both cases, the scenarios that are identified exist to accomplish requirements ,
which can be either functional or non-functional requirements. Also in
both cases, and unambiguous vocabulary which describes the important “things” (entities)
in the problem domain is very desirable to avoid
ambiguity in the scenario descriptions. And in both cases, first-draft
scenarios typically get elaborated with a diagrammatic
representation of the scenario.
Business modeling and software designs are different in a number of ways; software
scenarios (aka use cases) typically involve one or more users interacting with
a software system, while business scenarios typically involve a mix of human-computer
and human-human interactions, where the human-computer interactions may span
multiple software systems.
Business scenarios are often modeled in both “as-is” (existing business) and “to-be” (future
business) forms, and it is especially important that business scenarios are
well understood by non-technical Subject Matter Experts (SMEs) who understand
what the business is about but may not be involved in IT at all.
Software scenarios in ICONIX Process need to be linked to objects, and to screens
and GUI storyboards - business scenarios do not. Elaborating software
use cases with robustness diagrams forces those linkages, and is thus the step
we use in ICONIX Process to disambiguate the use cases prior to doing detailed
design on sequence diagrams. There is a learning curve associated with
the robustness diagram notation (boundary, control, entity stereotypes) which
is easily justified for software designers but is less easily justified for
business modeling, which inevitably involves non-technical SMEs. As a
result the ICONIX Business Modeling Roadmap specifies that business scenarios
should be elaborated with activity diagrams instead of robustness diagrams.
Roadmap Overview
The Roadmap consists of four major activities: modeling business
process scenarios , identifying requirements (and
allocating them to the business scenarios), modeling the problem
domain , and subsequently identifying software
scenarios so that the new business processes can be automated.
Figure 1 – ICONIX Business Roadmap Top Level Activities
Each of these Top Level Activities is further decomposed into its own step-by-step
activity diagram. We'll discuss these one at a time.
Requirements Capture and Allocation
We use Requirement Diagrams to capture and organize Requirements .
The Roadmap identifies four specific categories of requirements: Functional , Non-Functional , Business
Rules , and Data Requirements . However,
these categories are simply meant as guidelines; feel free to group your requirements
into whatever categories make sense for your business.
Figure 2 – Requirements Capture and Allocation Activies
Note that our Roadmap specifies both an “internal” Subject Matter
Expert (this is someone within the Business Analyst team
who is knowledgeable about the relevant part of the business) as well as
the “real” Subject Matter Expert , who is typically
part of the operational business as opposed to a member of the IT staff.
Also note that the Roadmap specifies that Requirements, once identified, should
be allocated to the business scenarios, and that traceability
matrices should be generated and reviewed. We have found that
the Enterprise Architect (EA) modeling tool does a remarkably good job at automating
these activities. Requirements can be allocated to scenarios using a simple
drag-and-drop, and EA's built-in relationship matrix takes all the pain out
of generating the traceability reports. Allocating and tracing requirements
is critically important to verifying the integrity of the business process
models.
Figure 3 – Requirements are accepted or rejected based on SME
Review
Modeling the Problem Domain
As with our software design process (standard ICONIX Process), disambiguation is
of fundamental importance in the ICONIX approach to Business Modeling.
Ambiguity in specifications (whether they are at the business scenario or
at the software scenario level) often starts with analysts using multiple names
for the same “problem domain entity”. Therefore the same guidance that we provide
in the ICONIX Process Roadmap applies in our business modeling roadmap.
Business Process Scenarios should refer to entities in the problem domain
unambiguously, using a well-defined and documented name. We show these entities
on a domain model diagram (a simplified UML class diagram) which shows the
entities along with the “has” and “is” relationships (aka aggregation and generalization)
between them.
Figure 4. Modeling the Problem Domain is a critical element of
ICONIX Business Process Modeling
Modeling the Business Scenarios
Modeling Business Process Scenarios represents the bulk of the Business Analyst
activity specified by our roadmap. We first decompose the business into subsystems (functionally
related areas) and show this decomposition on UML package diagrams.
Within each subsystem, we identify the business scenarios as
stereotyped use cases on UML use case diagrams. As with software scenarios,
each business scenario is written in English, and will typically contain both
a sunny-day (basic course of action) and a rainy-day (alternate
courses of action) section.
It often makes sense to capture both as-is (existing state) and to-be (future
state) business processes. While our roadmap shows the path for future scenarios,
the same steps can easily be used for modeling as-is scenarios, which would
logically precede the modeling of future scenarios.
Figure 5 – Business Process Scenarios are identified and documented,
requirements are allocated and traced, and the scenarios are elaborated
using Activity Diagrams to expose errors.
After the business scenarios have been identified and documented in English,
they are linked to Requirements that have been identified earlier in the process.
Typically additional requirements are identified and captured during this process.
Once the scenarios have been captured, it's generally advisable to elaborate
them in diagrammatic form , as (similarly to software scenarios)
the act of elaborating a scenario by drawing a picture of it tends to expose
errors and inconsistencies. Our business modeling roadmap specifies the
use of UML Activity Diagrams for this purpose, whereas the ICONIX software
roadmap uses robustness diagrams. There are several reasons for the choice
of activity diagrams as opposed to robustness diagrams, including:
- activity diagrams are more easily understood by SMEs
- business processes don't need to be linked to GUI storyboards and object
names as tightly as software use cases do
- using a different diagram helps to eliminate confusion between business
scenarios and software scenarios
Identify Software Use Cases and proceed with System Design
When we have captured and reviewed all of our business scenarios with subject
matter experts, we can consider moving forward to implement those scenarios.
In some cases, the future-state business scenarios may be realized by multiple
software systems. These automation opportunities should be systematically identified,
prioritized, and scheduled. For each new system developed, the software scenarios
which realize the business scenarios should be identified and design should
proceeed following the normal ICONIX Process Roadmap. Note that the requirements
identified during the business modeling activities should once again be allocated
and traced to and from the software use cases.
Conclusion
The ICONIX Business Modeling Roadmap specifies a simple, intuitive, yet rigorous
approach to business modeling and offers a seamless transition to software
design when it becomes time to automate portions of the future state scenarios.
The Virginia Department of Motor Vehicles has made extensive use of the ICONIX
approach to BPR and requirements development. You can view an HTML
report of the Virginia DMV Systems Redesign model built using the
Enterprise Architect tool. This model is very large but is still "work-in-progress." It
represents the combined effort of a team of more than thirty dedicated professionals,
all working together in one model, with one goal: an effective new system for
the DMV to support its full range of internal and customer support activities.
Virginia DMV and other ICONIX customers report good success following this
roadmap, and we hope it will prove useful to your organization. For further
questions, contact us at umltraining@iconixsw.com.
|
