While working on a Business Architecture effort several years ago, I collaborated on developing a new internal standard for business process and business capability description. From my perspective, a business capability is the required function or desired service that a business unit performs and the business process is the set of methods employed to realize the business capability. Business capabilities and business processes can be described as current or future state. Their description can also be scaled for strategic or tactical objectives.
This article will present an approach for documenting and aligning business capabilities, business processes, and functional requirements by integrating two distinct tools that leverage robust repositories and object metadata.
In my organization, we have ample tools and deliverable templates on hand to enable the Business Analyst to document artifacts in visual and textual form. We use iGrafx FlowCharter from Corel to draw the business process models. This tool is familiar to our business clients who already participate in our Six Sigma projects. It is more powerful than Microsoft Visio because it has an object repository built-in. It also has simulation capability for predicting business process model performance.
As a Business Analyst leading Business Architecture activities, I experimented with drawing swimlane-style business process models using standard notation, naming convention, and symbols in iGrafx. We adopted the core elements of the Business Process Modeling Notation (BPMN) standard to establish repeatable modeling methodology across project teams. The standard required that we differentiate roles, activities, business objects, business rules, and business events. The standard deliberately called for capturing the who, the how, the what, the why, and the when. By applying this rigor, we made the business process model more than a visual representation. We used iGrafx’s repository to store a comprehensive collection of metadata across business process models.
Here is an illustrative copy of our internal standard for reference. The examples used below were for processing security trades for our Vanguard mutual funds.
Each Business Process Model will have a unique name and identifier to facilitate traceability. Naming standard is as follows:
Business Process: <unique ID>: <unique name>
Business Process: EACTD 1.0: Capture Trade Detail
NOTES: Arial 20 Bold is the preferred font type/size for this field.
The standard header for each Business Process Model will include the create date and last saved date.
Create Date: Wednesday, November 09, 2007
Last Save Date: Wednesday, November 09, 2007
NOTES: Setup the header field in iGrafx to auto-generate the date/time fields. Arial 12 Bold is the preferred font type/size for this field.
Swim lanes will break out roles within an internal department/team.
Swim lanes will be sequenced from top to bottom in the following manner: external role, internal role, system.
- External role: yellow
- Internal role: grey
- System: green
Communication between swim lanes (roles) will use the following notation:
Activity boxes will include all of the following information:
Purpose is annotated on the Note tab in the Activity Properties box.
Input/Output is annotated on the Custom Data tab in the Activity Properties box.
Business Objects will be annotated using the following notation:
The key data that makes up the Business Object will be annotated on the Note tab in the Business Object Properties box.
Process flow within swim lanes will be annotated using the following notation:
Links to other sub-processes will be annotated using the following notation:
NOTE: The links may be dynamic or static.
Message Events will be annotated using the following notation:
Message Events will contain the following information:
Message Events should be anchored to the appropriate Activity box.
Event Source = Activity ID
Rules will be annotated using the following notation:
Rules will contain the following information:
Rules should be anchored to the appropriate Activity box.
Rule Source = Activity ID
More than one Rule may be anchored to a single Activity box.
Timer Events will be annotated using the following notation:
Timer Events will contain the same information as Message Events.
Timer Events should be anchored to the appropriate Activity box.
Event Source = Activity ID
Our intention was to leverage the repository as a springboard for subsequent requirements elicitation and analysis. Here is a copy of the revised business process model with the standard elements marked for reference.
Click to View Larger Image
The iGrafx application has a utility that produces a text file containing selective metadata that you input and specify for export. Here is a corresponding export for some of the business process model activities shown above:
||EACTD 1.1 Receive Trade Detail
||Preliminary Trade Detail
||Preliminary Trade Detail
||The purpose of this activity is to receive the Trade Detail to prepare it for processing
||EACTD 1.11 Update Trade Detail
||Trade Detail (Error)
||Trade Detail (Updated)
||The purpose of this activity is to update the Trade Detail with missing data and/or format changes to facilitate further processing.
||EACTD 1.13 Change Status
||Trade Detail (Updated)
||Trade Detail (Ready)
||The purpose of this activity is to change the status of the Trade Detail to facilitate further processing.
||EACTD 1.15 Contact Supervisor
Notification that two hours have elapsed since the exception message was sent w/no resolution
||The purpose of this activity is to escalate exceptions that have not been resolved within two hours of notification.
||EACTD 1.3 Check Trade Detail
||Preliminary Trade Detail
||Trade Detail (Format Checked)
||The purpose of this activity is to ensure that the trade detail business object is in the proper format to support downstream processing.
||EACTD 1.5 Change Status
||Trade Detail (Format Checked) or (Completeness Checked)
||Trade Detail (Error Status)
||The purpose of this activity is to update the status of the Trade Detail to put it into a pending state until the exception is corrected.
This export shows the notes collected about a business object. We captured the preliminary data characteristics of the object in free form text.
||Trade Detail (P)
||Dataset: Trade date Settlement date Buy/sell # of shares Principal/agent Security ID Broker ID Effective date Net Amount (price) Price
As an alternative, discrete characteristics can be created as custom metadata for each object in iGrafx. The attributes you see here for events and rules are an example.
||Trade Detail Receipt
||Role 1 sends trade detail to Role 2. Receipt of Trade Detail triggers the trade processing process.
||Confirmation of Receipt Sent
||This event represents the communication back to Role 1 to confirm receipt of the Trade Detail.
||Exception Message Receipt
||A message is received that an exception condition related to Trade Detail exists.
||Role 2 contacts Role 1 if no resolution is received within 1 hour of notification.
||Trade Detail Format
||SWIFT MT541/MT543 formats are the standard for all SWIFT enabled advisors.
||Trade Detail Status
||Trade Detail states: preliminary; format checked; completenes checked; pending exception
||Trade Data Completeness
||The following fields must have values: XXX, YYY, ZZZ
||Exception Types That Can be Resolved
||These exceptions can be repaired: XXX and YYY
||Activity Cycle Time
||Measure the cycle time between actiivty 1.5 and 1.11
||Status If Correct or Updated
||Status = "ready" for further processing
||Trade Objects Received Daily
||Collect the number of trade detail objects received daily
||Trade Detail Format Errors
||Collect the number of trade detail objects rejected due to bad formats.
||Trade Detail Error Completeness
||Collect the number of trade detail objects rejected due to lack of data completeness
If the team maintaining the business process model has the discipline to input and maintain the metadata, then this export utility can be useful in downstream requirements elicitation and analysis.
Once the business process models and metadata were documented, the Business Architecture team analyzed the future state business process models to identify business capabilities. From there, the Business Analyst differentiated the business vs. system capabilities. System capabilities were merely business capabilities enabled via an automated or semi-automated solution. Here is an example of some capabilities derived from the future state business model.
- Communicate Trade Details to Role 2
- Validate Trade Detail Completeness
- Identify Missing Trade Detail
- Communicate Missing Trade Details to Role 1
- Resolve Missing Trade Details
- Validate Trade Detail Against Accepted Values
- Identify Accepted Values Exceptions
- Communicate Accepted Values Exceptions
- Resolve Accepted Values Exceptions
- Communicate Trade Details to Role 3
- Collect Acknowledgment of Delivered Trade
Next, we imported selected iGrafx information into our requirements management tool, IBM’s Rational RequisitePro. The analysis of roles, activities, business objects, business rules, and business events served as a framework for requirements decomposition. We created specific requirement types in RequisitePro to house the business capabilities, system capabilities, system functions, and business rules (e.g. BCAP, CAP, FUNC, RULE).
An example of the BCAP properties is shown below:
Why would we copy this information from one repository to another? Well, we used ReqPro baseline the business capabilities, to decompose system capabilities into system functions, and then to directly capture, store, and trace detailed requirements as follows:
Note: The business events were not maintained as a separate requirement type in RequisitePro since they served as triggers for business activities. The business roles and objects were actually embedded as a consistent reference in the functional requirements.
By importing metadata from iGrafx directly into RequisitePro, we were able to save administrative time. More importantly, we used the information to align requirements with future state capabilities, ensure that system functions were decomposed into detailed requirements, leverage first draft business rules, and verify that business events and business objects were integrated into the functional requirements.
We used two tools with two different strong suits for a single objective – to iteratively discover, define, and document business requirements. By employing business process models and the iGrafx repository during Business Architecture, we were able to get an early start on recognizing, categorizing, and recording business information that would be valuable in later phases of the project.
Knowledge of business roles, activities, objects, rules, and events is essential for Business Analysts when analyzing requirements but it also proved useful to Technical and Data Architects when designing system solutions. They referenced the business context when they looked for design patterns and created a service-oriented architecture.
By importing metadata from the iGrafx objects into RequisitePro, we were able to fully develop the requirements and ensure that they aligned with the business vision. Integration of these two robust tools empowered our Business Analysts to perform more thorough analysis and to deliver requirements that stemmed directly from business process models.
Author: Susan Block, CBAP, is Lead Business Systems Analyst at The Vanguard Group in Malvern, PA and VP of Professional Development for the IIBA Philadelphia Chapter.