IBM Certification Test 992.2 - Modeling
Use WebSphere Business Modeler team support and publishing functionality to work in a collaborative environment
For modeling projects to be successful and to ensure that they effectively factor in the broad organizational expertise for a particular domain, it is critical that teams be able to share process elements and have robust mechanisms for reviewing each other’s work. In WebSphere Business Modeler, business analysts can share model project data through
- Import and export facilities
- Team support (CVS, Rational ClearCase®)
- Sharing of PDF reports.
- Teams can also collaborate by sharing data across projects, making project data available for viewing and commenting through the Publishing Server, and taking advantage of faster Rational ClearCase integration.
Team modeling
When it is not practical for a single person to model business processes, use a team approach.
Effective and comprehensive business process models can be labor intensive to create. For example, although a simple model might have less than 20 elements, each of these elements might have many attributes that need to be documented. Larger models might be impossible for one person to create in a timely manner.
As another example, an enterprise might have many organization units and locations. Rather than move one person from place to place, it might be easier to have one or more team members in each organization unit or location model the processes that each unit or location uses.
When using a team approach to modeling, there are numerous decisions that team members must make. These decisions revolve around how the team protects information while simultaneously making it available for all team members to see and use.
-
When to use project versioning versus exporting and importingWebSphere Business Modeler provides two mechanisms for sharing information between team members: the project versioning component and import and export functionality.
- When to use Rational ClearCase versus CVS
The project versioning component supports both Rational® ClearCase® and CVS as the version control system for WebSphere Business Modeler. When choosing between the two systems, consider whether you already have one of the systems implemented.
- When to use one large project versus many smaller ones
Before you start modeling the processes, plan the structure of your projects. One of the most important decisions you will make is whether to use one large project or a number of smaller projects to contain the modeling data.
- When to use restricted versus unrestricted ownership
Restricted ownership is when a user owns a project or specific catalogs in a project and only the owner is allowed to modify an element in the project or catalog. Unrestricted ownership is when a user owns a project or specific catalogs but any user can modify an element in the project or catalog if the owner agrees.
Modeling team composition
To model the business processes effectively, a modeling team uses a diverse set of skills and roles. A team member can fill more than one role, and more than one person can fill a role.The following list describes the typical roles in a modeling team:
- The leader coordinates the activities of the modeling team. This person also maintains the schedule and manages inter-personnel problems. The leader should have experience in project management and in the business process methodology that the team uses.
- The architect or senior business analyst defines the structure that the team will use within WebSphere® Business Modeler to store the model information. If the team uses one large project or if the team uses a project as a template, the architect can create the structure of the project by defining its main folders. To preserve the structure when committing the project to a repository, the architect creates a dummy file in each folder. The team deletes the dummy file when there is real content to put into the folder. The architect also defines the conventions that the modeling team uses. An architect should have experience with the modeling processes and with using WebSphere Business Modeler. The architect might also have to reconcile conflicting versions of elements (which arise when one version overwrites another version) to create a version that satisfies the conflicting versions. For example, Sam needs Business Item A to have Attribute B. Melissa needs Business Item A to have Attribute C. Sam and Melissa check out Business Item A at the same time. Sam adds Attribute B and commits this change, and then Melissa adds Attribute C and commits the change, overwriting Sam’s change. In this case, the architect creates a third version of Business Item A that has Attribute B and Attribute C to satisfy both needs.
-
The modeling team member is a process analyst or business analyst who gathers and enters information into the projects. Gathering information includes activities such as interviewing subject matter experts and reviewing documentation. Modeling team members should have some experience with using WebSphere Business Modeler.
-
The publisher uses WebSphere Business Modeler Publishing Server to publish projects to a publishing server. The publishing server displays projects using a Web interface and handles comments that reviewers can enter as feedback. If the team does not use a publishing server, the role of publisher is not needed. Although every member of the team can be a publisher because every instance of WebSphere Business Modeler can publish, only a few team members should fill this role to control what the team publishes. Publishers should also be publishing server administrators so that they can set the access rights of any projects they publish. These administrators also manage the content of the publishing server and moderate the comments.
The modeling team also needs support from IT personnel to set up the version control repositories if the team uses project versioning and to set up WebSphere Business Modeler Publishing Server if the team uses this product to publish its models to a Web interface.
Publishing projects
WebSphere Business Modeler provides a built-in capability to connect with WebSphere Business Modeler Publishing Server. WebSphere Business Modeler Publishing Server enhances WebSphere Business Modeler by providing a way to publish business processes and related business information, such as organization diagrams, to a secure Web site. This capability supports the development, documentation, and dissemination of business process models on enterprise and worldwide scales.With WebSphere Business Modeler Publishing Server, process definitions and other model artifacts can be shared across a broad organization. By using a Web browser, you can view and comment on published draft processes, providing the opportunity for SMEs, process implementers, and business analysts to collaborate on the definition of process models. After processes have been reviewed and
approved, system-of-record process models can be published for referral across the enterprise intranet and even through a secure extranet with business partners.
By publishing business processes in a Web-based format, multiple people on multiple teams around the globe can view and contribute to the development of the business processes. To accommodate the differences between viewers and contributors, WebSphere Business Modeler Publishing Server provides two stages of publishing.
-
The first stage enables contributors to review the developing business processes and, through comments and attachments, provide the modeling team with feedback and additional information. At a chosen point, the business process models become ready for people to use as a reference in their day-to-day activities.
-
The second stage of publishing makes the business processes available for these viewers.
- Model publishing
Model publishing involves sending a consistent model to a publishing server. To achieve consistency, there must be an integration of model elements from different WebSphere Business Modeler instances.
- Connecting to publishing servers
You connect to a publishing server to publish projects. Once you have published a project, other people can use a Web browser to view and comment on the project's elements such as processes, business items, and resources.
- Setting the default publishing server
You can set a default publishing server to host published projects. WebSphere Business Modeler initially highlights this server when you are publishing although you can override the default by selecting a different server.
- Editing publishing server connections
You can edit a publishing server connection to change the information used to connect to the server. For example, you would edit the publishing server information if the password used to access the server is no longer valid.
- Removing publishing server connections
You can remove a publishing server connection to remove obsolete or unavailable servers from the list of available servers. Once you remove a publishing server connection, you cannot publish a project to it.
- Sending projects to the server
You can send an entire project or selected elements in the project to a publishing server by publishing it. Publishing copies the project and its elements to a publishing server.
- Effects of renaming, importing, moving, and deleting elements on publishing
A publishing server is able to identify when you are republishing an element, even if you have renamed it, moved, or imported it. The publishing server also maintains elements deleted in WebSphere Business Modeler until a publishing server administrator deletes them.
Sharing and exporting processes
Simply put, maintaining multiple copies of the same element across multiple projects is time consuming and leads to errors. By having sharable, dedicated projects to particular domains of process information, an organization can effectively build libraries of process elements, such as sharable projects for all credit-related services and for all claim-related business items. With the ability to share elements across projects, one project can refer to process elements in another project. As a recommended best practice, sharable projects can be treated as read-only in each team member’s local workspace. Each project in your workspace includes a reference group, which represents the set of other projects that a given project can use for element reuse.
You can share your process models, business items (data), and business measures with your modeling team, reviewers, stakeholders, and IT developers in different ways: using project versioning, Web-based publishing, an asset repository, and file export.
- Versioning projects
To support collaborative business modeling, project versioning enables team members to work from a common source and track changes to a model as it evolves.
- Project versioning
You can distribute the effort of modeling or modifying an entire project to a team of modelers. In this case, team members post copies of modeling projects to a version control system so that all team members can view these projects, create their own local versions of them, and submit their modifications back to the repository locations.
- Publishing projects
Publishing a project copies the project and its model elements from WebSphere® Business Modeler to IBM® WebSphere Business Modeler Publishing Server Version 6.1.2.
- Exporting models
You can export models from WebSphere Business Modeler using several different formats.
- Changing modeling modes
- Modeling for monitoring
- Modeling for WebSphere Integration Developer implementation
- Sharing assets
When you want to share the business process management (BPM) artifacts that you create, store them in a central asset repository that you and others can browse. For example, you want to be able to find and reuse the approved version of a process model even if someone else created it. With the asset repository, you can do just that.
Related links
- Business Process Management: Modeling through Monitoring Using WebSphere V6.0.2 Products
- WebSphere business process management zone (IBM Developerworks)
- WebSphere Business Modeler certification exam 992 prep, Part 2: Model business processes
No comments:
Post a Comment