Customer Solution Case Study
/ / Leading Financial Data Provider Standardizes on Web Services for Product Delivery
Overview
Country or Region:United States
Industry:Financial services
Customer Profile
New York, New York–based Thomson Financial is one of the largest data and analysis providers in the financial services industry, with 7,700 employees in 22 countries and 2003 revenues of U.S.$1.5 billion.
Business Situation
To better meet customer needs and reduce the complexity of its IT infrastructure, Thomson Financial wanted to standardize on a single, highly flexible product delivery architecture.
Solution
Thomson ONE solutions, built using various technologies including Microsoft® .NET, employ a common, reusable set of software services that are accessed through a configurable desktop application.
Benefits
Improved ability to meet customer needs
Greater user productivity
Faster, deeper integration with customer systems
Increased sales
Faster time-to-market / “Microsoft .NET technology is helping us be a company that listens intently to customer needs. We can say … ‘Tell us about your needs and workflows’ instead of having to force the sale of rigidly defined products.”
Bill Quinn, Vice President, Product Management, Thomson Financial
Due to a history of growth through acquisition, Thomson Financial had multiple systems that delivered the same types of information and forced customers to access the company’s different offerings in different ways. To appear as a single company to customers and to reduce the cost of product delivery, Thomson Financial developed a common product delivery architecture—dubbed Thomson ONE—using Microsoft® .NET technology. Based on a reusable set ofsoftware services and a highly configurable desktop client, Thomson ONE solutions are helping the company enhance user productivity, integrate more deeply with customer systems, reduce IT costs, and accelerate time-to-market. With Thomson ONE solutions, the company can say “yes” to customers more often, letting customers—and not internal systems—dictate how Thomson Financial products are used.
Situation
Thomson Financial is one of the largest dataand analysis providers in the financial services industry, with operations in 22 countries and 2003 revenues of U.S.$1.5 billion. The company’s diverse assets include more than 40 businesses, many of which were acquisitions.
In the past, the company’s mode of operation was to leave newly acquired businesses largely untouched, letting them continue to deliver the products that made them attractive acquisitions in the first place. But the company began to reevaluate that hands-off strategy a few years ago—driven by consolidation in its industry, the need to minimize the cost of product development and delivery, and, most important, constantly growing customer expectations and demand for greater value.
One area where Thomson Financial saw considerable opportunity for improvement was in the technology infrastructure used to deliver its diverse range of products. Those products were supported by multiple operating systems (primarily Microsoft® Windows® and UNIX), technologies such as Java 2 Platform Enterprise Edition (J2EE) and the Component Object Model, and earlyprogramming languages like C and Fortran.
Moving forward, the company envisioned a single, common product delivery architecture that could support all its offerings. Key business drivers for that vision included:
Improved user experience. To better accommodate the needs of the financial professionals and help increase their productivity, Thomson Financial wanted to deliver a richer and more responsive user experience. Users of the company’s offerings do a good deal of analysis—an area where Thomson Financial delivers significant value by providing features like customizable workspaces and advanced charting and graphing tools.
Deeper integration with customers. Many of the applications that Thomson Financial used to deliver its products to customers had user interfaces (UIs), business logic, and data stores that were tightly coupled together. Because of this, customers who used more than one of the company’s offerings often had to do so through multiple interfaces—which made those customers less productive than if the same products had been accessible through a single, well-integrated interface. In addition, the tightly coupled architecture made it hard for customers to integrate Thomson Financial offerings into their own systems. By providing a single, common UI for all its offerings and a way for customers to integrate those offerings into their own systems, Thomson Financial knew that it could deliver new customer value in the form of reduced costs, streamlined workflows, improved productivity, and the ability to make better and faster decisions.
Reduced infrastructure and development costs. As Thomson Financial grew, so didthe number of systems that it usedto service customers. Those systems numbered more than 100, with a good deal of overlap in terms of functionality and with the same data stored in multiple places across the organization. Most data stores supported multiple applications, and many of those applications had multiple user interfaces—often cloned and customized to meet the needs of specific customers. By reducing redundancy and serving customers with fewer systems, the company knew it could save millions in infrastructure costs. In addition, having fewer systems would reduce software development costs because the company would no longer need to maintain so many applications—ordevelop new functionality more than once for delivery to different customer segments.
“Content providers traditionally were focused on a single [market]such as news, research, or analytics, but industry consolidation is changing that,” says Bill Quinn, Vice President for Product Management at Thomson Financial. “We saw that meeting allof a customer’s needs through individual applications was no longer enough—and began working to integrate our offerings to help customersstreamline workflows and reduce costs.”
Solution
Thomson ONE solutions, based on Microsoft .NET software, are helping the company reduce the complexity and redundancy of its technology infrastructure and thus decrease costs. In addition, the solutions improve the company’s ability to meet customer needs by allowing those customers to access the broad range of Thomson Financial products in multiple ways: through direct, programmatic integration with the customer’s internal systems using broadly accepted Web standards; or by using a common, highly customizable user interface that delivers the richness and responsiveness of Windows-based desktop applications together with the deployment and manageability benefits of Web-based solutions.
Developed with guidance from Microsoft, Thomson ONE solutions provide those capabilities through a service-oriented architecture that consists of two primary components: a service layer that encapsulates business functionality and exposes it as a set of reusable Web services,and a smart client application that programmatically accesses those services to deliver the user experience.
Service layer. In a service-oriented architecture, the service layer encapsulates the solution’s data store and business logic layer, exposing their combined functionality (for example, methods of analysis on financial market data) as Web services—discrete application components that are accessed using standard Web protocols like XML, SOAP, and WSDL. Unlike tightly coupled solutions in which the presentation tier must know how to access the business logic tier (in essence, a self-service model), the means of interaction in a service-oriented architecture is a full-service model in which a system that wants to access the service layer must only describe to the service layer what it needs. The service layer handles the details of fulfilling the request—for example, retrieving data from a database and analyzing it—and delivers the desired results while hiding the underlying complexity of servicing that request. In Thomson ONE solutions, the service layer also provides a set of infrastructure services, such as those for user authentication and authorization, storage of user preferences, system eventlogging, and application updates.
Smart client. A smart client is an easily deployed and managed application that runs locally on a user’s device and intelligently connects to distributed data sources (in the case of Thomson ONE solutions, this is done through the service layer). By usinglocal computing resources such as processing power, memory, disk storage, and peripherals, the Thomson ONE smart client can deliver a user experience that is rich, very responsive, and adaptive to the way that people work. For example, the rendering of user interface elements like charts and graphs is fast because those processor-intensive tasks are performed locally by the smart client. When the smart client needs data that it does not have, it sends a message to the service layer. The service layer replies with another message containing the requested data, which the smart client stores locally for further analysis or manipulation—including at times when the user is offline. Updates tothe smart client application itself are automatic—again through functionality provided by the service layer.
For some new solutions, both the service layer and smart client are being developed using the Microsoft Visual Studio® .NET development system and are based on the Microsoft .NET Framework—an integral component of the Windows operating system that provides a common programming model and runtime for developing Web services, Web applications, and smart client applications. Inother cases, a smart client based on .NET technology connects to a solution that runs on another platform through the use of Web services. In a third scenario, .NET technology is used to provide a service layer in front of an existing solution, allowing it to be accessed by either smart clients or Web-based solutions.
“We have engineered our business strategy around customer segmentation and our technology strategy around application interoperability and integration—as achieved through a service-oriented architecture,” says Dr. Albert Hofeldt, Vice President of Technology Strategy for Thomson Financial. “Such a strategic combination facilitates cross-application workflows that provide our customers with direct efficiency gains by drastically simplifying the execution of complex business processes.”
How ItWorks
Figure 1 shows how a service-oriented architecture based on Web services can support both smart client applications and internal Web solutionsthat Thomson Financial customers might choose to build. The Web services exposed by the service layer can be consumed by solutions running on all major platforms—a big integration benefit. The service layer can be accessed easily by the internal systems of a Thomson Financial customer, another Thomson Financial system, or a smart client running on a user’s desktop PC, regardless of the platform on which the system calling the service resides.
Moreover, because Web services are based on Internet standards, they can be accessed just as easily over the Internet as through dedicated lines. (Thomson Financial customers usually prefer dedicatedlines because they value performance and reliability over connectivity cost savings. However, even in those cases, Web services make it easier to configure thededicatedlines and the networks that they connect.)
“In the past, a solution’s user interface was tightly tied to its business logic,” says Joe McMenimen, Enterprise Architect at Thomson Financial. “Customers had to take the UI that came with the solution, or we had to clone the solution and then modify the UI, ending up with yet another system to maintain and manage. With a service-oriented architecture, we can build a Web service once and use it over and over again, accessing it through whichever user interface is best suited to the needs of the customer. With its extensive support for Web services, Microsoft .NET technology is an outstanding option for building such an architecture. As an added benefit, we can use the same tool set and programming model to build the desktop client that accesses the service layer.”
Proof of Concept
To validate the architecture for Thomson ONE solutions,developers and system architects from the financial services company worked side by side with architects on the Microsoft .NET Enterprise Architecture Team, which helps Microsoft customers use .NET technology combined with industry best practices to solve real-world business problems.
During the three-month proof of concept, the combined development group took a snapshot of data from Thomson Financial production systems and loaded it into a Microsoft SQL Server™2000 database. The groupdeveloped the business logic required to access the database and manipulate its data, exposing that functionality as a set of three MicrosoftASP.NET–based Web services: a portfolio management service for creating investment portfolios and specifying holdings, a research service that exposes reports and news items, and a quantitative service that exposes such information as earnings estimates and price-to-earnings ratios. The services ran on the Microsoft Windows Server™2003 operating system and the .NET Framework. All development was done using the C# programming language and the Visual Studio .NET 2003 development system.
Using the same programming framework and tool set, the groupalso developed a smart client that could meet the needs of Thomson Financial’s diverse and demanding user base. Built to run on the Microsoft Windows XP Professional operating system, the smart client provides enormous flexibility in the way that users work with data by providing an extensible, highly customizable workspace that the user can configure to meet his or her needs and working style.
Within the workspace are individual Thomlets, or UI elements, which can be repositioned by the user. Each Thomlet performs a single function, such as managing the holdings in a portfolio or displaying a graph. Thomlets that appear within the smart client, and the Web services that they access, are controlled with configuration settings. That means Thomson Financial can create a set of common Thomlets once and easily combine them in different ways to meet the needs of any market segment—or any specific customer—without having to write additional code.
Thomson ONE Portfolio
Even before the Thomson ONE architecture was finalized, Thomson Financial began to employ its core principles. One such example is the company’s Thomson ONE Portfolio, a portfolio performance attribution solution that uses a smart client to access aservice layer.
Development of the solution began in 2001, when the Thomson Financial business group that owns the solution was part of Vestek, a company that Thomson Financial has since acquired. At the time, Vestek used non-Microsoft technologies for application development and database management—technologies that the company planned to use to replace an existing portfolio analysis product.
Originally, plans called for the new version of the product to have a Web-based interface. That decision was based on the company’s experience with its chosen technology at the time and the belief that it could not easily support loose coupling. Instead, that technology forced the use of a tightly coupled, Web-based architecture where both the Web and business logic tiers ran in the same location. The business logic tier, in turn, would connect to a new database tier that the company was building.
By the time that Thomson Financial acquired Vestek, significant work already had been done—work that the company did not want to discard as it transitioned to its new common architecture. A database tier had been built, the data model had been designed, and developers had built a replication mechanism between the solution’s database tier and the legacy system’s flat file data store. In addition, a good deal of work had been done at the business logic layer. However, it had become clear to Thomson Financial that a solution based on theexisting technology could not deliver the desired user experience, nor would it help the company move toward the looselycoupled product delivery architecture that it envisioned.
When work was scheduled to start on the presentation tier, Thomson Financial decided to evaluate the use of Microsoft .NET technology, including its ability to support the common product delivery architecture that the company wanted to achieve. Soon after that decision, the company’s developers came to Microsoft to work with the .NET Enterprise Architecture Team on the proof of concept described earlier.
After the successful proof of concept, six developers implemented the solution’s business logic tier using Visual Studio .NET and the .NET Framework. The developers used an Oracle data provider for .NET to access the already-completed database tier, allowing the company to retain its existing database investment. They used the C# language to implement the algorithms that calculate portfolio performance and exposed that logic as a set of Web services. While one part of the groupbuilt the service layer, three developers built the smart client—parallel development that was facilitated by the use of Web services and a service-oriented architecture.
Several major Thomson Financial customers are using Thomson ONE Portfolio, which the company is continuing to roll out to other customers. “Development of Thomson ONE Portfolio using Microsoft .NET technology went fast and was an easy transition for our developers,” says Mark Pahlavan, Vice President of Development for the Thomson ONE Portfolio Analytics Service (TOPAS). “Customers have been very impressed with the smart client interface and are happy with the way it accommodates how a portfolio manager works. With Microsoft .NET technology, we’re able to deliver a highly rich and productive user experience.”