![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
Forward 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.
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.
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
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 (crub) 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.
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.
As president of Rambyte, Ltd., Richard Menard is responsible for design and service delivery to multinational clients in the financial services and health care industries. A key contributor to the technical design of the world's most widely used software engine to match security trades, he is now working with nsurance institutions to shorten the processing cycle for health care claims. Before founding Rambyte, Ltd., he held leadership positions at Hewlett-Packard, GTE, and Compaq. He has an MBA from Boston College and a philosophy degree from Rhode Island College.
Table of contents
Local resources
Tags
Use the slider bar to see more or fewer tags.
For articles in technology zones (such as Java technology, Linux, Open source, XML), Popular tags shows the top tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), Popular tags shows the top tags for just that product zone.
For articles in technology zones (such as Java technology, Linux, Open source, XML), My tags shows your tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), My tags shows your tags for just that product zone.
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
