Home arrow Development Cycles arrow Domain Modeling: Leveraging the Heart of RUP for Straight Through Processing
DEVELOPMENT CYCLES

Domain Modeling: Leveraging the Heart of RUP for Straight Through Processing


Domain Modeling can be effective to illustrate just how business entities communicate with one another within a large scale organisation. Read how this business object model can help demonstrate how these entities interact at a high level to optimise the exchange of information, both internally and between an organisation and its external trading partners.

Author Info:
By: The Rational Edge
Rating: 5 stars5 stars5 stars5 stars5 stars / 14
August 05, 2003

print this article
SEARCH DEVARTICLES

Domain Modeling can be effective to illustrate just how business entities communicate with one another within a large scale organisation. Read how this business object model can help demonstrate how these entities interact at a high level to optimise the exchange of information, both internally and between an organisation and its external trading partners.

IllustrationForward thinking financial services organizations such as investment managers, broker/dealers, and custodian banks are positioning themselves for a Wall Street recovery by updating their information technology infrastructure. This often involves adding a messaging layer to automate the exchange of information both within internal systems and between internal systems and external trading partners. To understand how to make use of this messaging layer, organizations need to examine many systems and processes throughout the trading cycle in order to discover their respective functional characteristics, user communities, and data sources. Domain modeling can be very helpful in enabling system architects to visualize the current state of the trading environment, and then to reason about how the organization can optimize various systems to achieve straight through processing (STP) -- end-to-end automation of the pre-trade to post-trade settlement process.

What is Domain Modeling?

According to Rational Unified Process,® or RUP,® a domain model is a business object model that focuses on "product, deliverables, or events that are important to the business domain."1 A domain model is an "incomplete" business model, in that it omits individual worker responsibilities. The point of domain modeling is to provide "the big picture" of the interrelationships among business entities in a complex organization. The domain model typically shows the major business entities, their functional responsibilities, and the relationships among the entities. It also provides a high-level description of the data that each entity provides.

In RUP4STP2 (Rational Unified Process for straight through processing), a RUP Plug-In developed by Rambyte, domain modeling plays a central role in understanding the current environment and planning for the future. Our Current Trading Model artifact is a visual representation of an organization's present trading cycle, and our Future Trading Model illustrates how various trading partners and internal systems might be configured to optimize processing and workflows to achieve a compressed settlement cycle. Whereas the default business modeling discipline in RUP is abstract and can be applied to all industries, the business modeling discipline in RUP4STP is specialized for the securities trading domain, using concepts, guidelines, and activities familiar to IT professionals working in that industry. For a downloadable example of a Current Trading Model created with IBM Rational Rose,® see the Appendix.

Establishing the Scope of the Domain Model

If you examine the workflow detail, Develop Domain Model, which is included in the business modeling discipline of the standard RUP, you will see that the Business Vision artifact is an essential input into this process. Likewise, RUP4STP suggests that organizations first establish an overarching STP vision to frame the scope of their modeling efforts and determine what they are trying to achieve. Another activity in RUP4STP, Create System Inventory, walks the system analyst through the steps of discovering the mainframe, client/server, Web-based, desktop, and manual systems that are used currently to process trades. This is similar to the standard RUP activity, Find Business Workers and Entities. With the resulting system list, the analyst can begin creating the Current Trading Model, using class diagrams to represent basic collaborations between systems, as shown in Figure 1.

Figure 1: Basic system collaboration

The analyst will elaborate the business systems in performing the RUP4STP activity, Refine Current Trading Model. At this early stage, however, the goal is to determine STP priorities. This requires a high-level view of which systems are candidates to be replaced, re-architected, or re-designed. Then, the analyst can create a skeleton Future Trading Model, based on an initial review of the Current Trading Model.

Elaborating the Domain Model

To better understand the operation and responsibilities of a Current Trading Model, an organization must analyze the data it uses, how the data is manipulated, and which user communities consume the value-added information processed by each business entity. The RUP4STP activity, Analyze Data Sources, references the System Inventory and the Current Trading Model to gather all sources of data used by each system. In large financial service organizations, it is not uncommon for many different systems to make use of the same data source. Indeed, several departments may be purchasing the same data source from the same outside vendor, and the RUP4STP artifact Correlation of Data Sources and Methods will highlight such duplicate feeds. In standard RUP, the real nitty-gritty of a domain elaboration occurs during the Detail a Business Entity activity. RUP4STP's analogous activity is Specify Uses of Data, which examines the operations, attributes, and behavior for which each entity or system is responsible, as shown in Figure 2.

Figure 2: Elaboration of basic system collaboration

The analyst may wish to shed additional light upon key business processes in the domain by supplementing the static view of system collaborations with activity or sequence diagrams to show behavior. Figure 3 provides a high-level context for the processing of a trade in an investment manager organization.

Figure 3: Domain model -- activity diagram showing context for trade processing

Reviewing the Domain Model

It is always wise to review and validate a domain model with subject matter experts. When planning for straight through processing, the analyst should also be cognizant of "red flags" that indicate impediments to STP: manual procedures, slowly executing processes, and redundant data processing. The analyst should also document any business rules that are applied to trade data, particularly data transformation or “scrub” procedures, as well as data validation rules. In financial service firms, these transformation and validation procedures are often manually intensive.

The Trade Timeline is another key RUP4STP artifact not included in the generic RUP business modeling discipline. This very important artifact looks at the operational history of each system to determine the elapsed time required to complete its processing. With a record of each system's dependencies, predecessors, and successors, the analyst can construct a PERT chart of the pre-trade, trade execution, post-trade, and reporting segments in the trade processing cycle.

Then, taking into account specialized business rules such as scrub and validation procedures, the weaknesses of the Current Trading Model, and the Trade Timeline, the system architect can now represent the optimum trading environment in UML by refining the Future Trade Model. With the goal of compressing trade processing cycles, perhaps ultimately to within one day, the architect, along with the project manager and business sponsors, can prioritize STP-related projects according to ROI potential, as shown in Figure 4.

Figure 4: Domain analysis generates and prioritizes projects

An Aid to Understanding Complex IT Challenges

Domain modeling can help create a better understanding of complex IT challenges such as achieving straight through processing. Documenting data sources and gaining an understanding of how these data sources are used, the functional characteristics of each business system, and the collaborations among systems, enables an organization to think clearly about re-designing, re-architecting, or replacing slow or redundant procedures in a business process. Specialized, industry-specific plug-ins to RUP, such as RUP4STP, can accelerate understanding of a business domain and stimulate ideas for optimizing the exchange of information, both internally and between an organization and its external trading partners.

NOTE: This article was the winner of a recent "Content Contest" sponsored by Rational Developer Network (www.rational.net; authorization required) for submissions by IBM Rational® software business technology partners. Rambyte, Ltd. helps organizations to realize ROI on information system projects by supplying agile analysis and system architecture services coupled with industry-specific domain process models that facilitate straight through processing. For more information, visit http://www.rambyte.com.


Appendix: Current Trading Model

Download an example of the Current Trading Model described in this article.


Notes

1 IBM Rational Unified Process, 2002.05.01, "Workflow Detail: Develop a Domain Model."

2RUP4STP is the exclusive trademark of Rambyte, Ltd. The process model and content for RUP4STP were jointly developed by Rambyte, Ltd. and Venture Financial Systems Group, Ltd. For more information, visit the RUP4STP product Web site: http://www.rambyte.com/rup4stp/rup4stp.htm



Originally written by Richard Menard
Copyright (c) 2000-2003 IBM Corporation. All rights reserved.

DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware.

All Development Cycles Tutorials
More By The Rational Edge


blog comments powered by Disqus
DEVELOPMENT CYCLES ARTICLES

- Division of Large Numbers
- Branch and Bound Algorithm Technique
- Dynamic Programming Algorithm Technique
- Genetic Algorithm Techniques
- Greedy Strategy as an Algorithm Technique
- Divide and Conquer Algorithm Technique
- The Backtracking Algorithm Technique
- More Pattern Matching Algorithms: B-M
- Pattern Matching Algorithms Demystified: KMP
- Coding Standards
- A Peek into the Future: Transactional Memory
- Learning About the Graph Construct using Gam...
- Learning About the Graph Construct using Gam...
- Learning About the Graph Construct using Gam...
- How to Strike a Match

Watch our Tech Videos 
Dev Articles Forums 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us 
Weekly Newsletter
 
Developer Updates  
Free Website Content 
Contact Us 
Site Map 
Privacy Policy 
Support 

Developer Shed Affiliates

 




© 2003-2017 by Developer Shed. All rights reserved. DS Cluster - Follow our Sitemap
Popular Web Development Topics
All Web Development Tutorials