Winter 2005, Vol. 4, No. 4
By Samuel Greengard
Thomson Financial boosts time-to-market by 50% while
freeing up resources for strategic projects.
Albert Hofeldt, Ph. D., has seen the future of enterprise
computing, and it doesn’t involve tossing unlimited resources at
business problems. “One way to improve operational efficiency is
to consolidate technology resources,” says the vice president of
technology strategy at Thomson Financial, a New York-based
data and analysis provider in the financial services industry with
7,700 employees in 22 countries and 2003 revenues of $1.5
If anyone knows about optimizing business systems to realize
efficiency gains, it’s Hofeldt.
Over the past decade, Thomson Financial has acquired more than
40 companies with a diverse array of computer systems,
including legacy applications and an assortment of programming Vice President of Technology Strategy
languages. Setting a strategy to standardize on a highly flexible Dr. Albert Hofeldt worked to help
and scalable product delivery architecture wasn’t just a good Thomson Financial achieve economies
idea; it was essential for continued financial success. “We achieve of scale and decreased time to market
economies of scale and decrease time to market by creating a by optmizing its business systems.
common, cohesive system for enterprise product development,”
Hofeldt explains. Simply put, Thomson Financial wanted to ensure that its customers—those in the full
spectrum of the financial services community—could easily access its enormous database of news articles,
financial data, and reference materials. “We pride ourselves on providing financial applications with
integrated workflow and real-time market data to some of the most demanding customers around the
globe,” says Hofeldt.
To align and optimize resources, Thomson Financial used Microsoft .NET technologies to develop a reusable
architecture and software development kit (SDK) called the Thomson Reference Architecture (TRA). The
combined effect of architecture and SDK is to enhance productivity, slash costs, and drastically improve
time to market by at least 50% for the company’s products and services. A key benefit is that customers
and consultants can easily share applications and interfaces across organizations. This approach produces
bottom-line benefits for financial professionals using Thomson Financial’s services.
For example, with a single, highly customizable workspace, financial professionals can view information in a
manner that suits their specific position or work style. Not only does this approach reduce the number of
actions financial professionals must take, but it also allows them to spot data trends faster than competitors
and use information to achieve greater gains. Consider this: Thomson ONE Portfolio, a portfolio analysis
solution, can analyze portfolio performance against the S&P 500 index over a one-year period several times
faster than a previous Thomson Financial system because of the streamlined efficiency provided by the
TRA. “Our users are very sophisticated, and it is essential to empower them with functionality that improves
job efficiency while providing the highest level of service, ease of maintenance, and overall cost for the
business,” says Hofeldt.
Gaining a competitive advantage and achieving outstanding results requires a deft balance between
business strategy and technical concerns. “I’m a strong believer in strategic portfolio management and
what-if scenario planning covering both depth and breadth of the technology landscape in the three- to
five-year time frame,” say Hofeldt.
A few years ago, Thomson Financial found itself coping with different operating systems, varying
programming environments, and a multitude of data sources and legacy programming languages.
Compounding the problem, different divisions, business units, and teams often had their own ideas about
what environment to use.
“Many of the business units had achieved a great deal of success with their own applications and approach,”
Hofeldt notes. “But the bigger picture was that the organization needed a common set of standards and
processes in order to achieve maximum results in a cost-effective way. The synergy gained from unifying
and consolidating various systems would boost performance and profits.”
Align, optimize, adapt
At Thomson Financial, aligning and
optimizing resources has become a key
Tapping into a set of software
components based on Microsoft’s .NET
technology, Thomson Financial built a
reusable architecture and software
development kit called the Thomson
Reference Architecture (TRA). The
system uses a service-oriented
architecture and emerging Web
services to adapt functionality without
constantly reprogramming systems
and installing new software. The end
result? Thomson Financial is able to
adapt to change quickly and has
bolstered its IT infrastructure.
The service-oriented architecture
hinges on two primary components: a
service layer that taps reusable Web
services to manage business
functionality, and a client application
that accesses the Web services and
delivers them to users. Together, the
components create a highly optimized
data environment that works on both
conventional and thin clients and
requires only streamlined programming
by a handful of developers.
Thomson Financial used the Microsoft
Visual Studio .NET development
system to build all new TRA
components and is now steadily
migrating applications to a service-
oriented architecture framework,
explains Dr. Albert Hofeldt, vice
president of technology strategy. And
according to Brenton Webster, a
solutions architect for Microsoft,
balancing business requirements with
technical issues was a core goal. “It
was essential to deliver application
functionality to Thomson’s broad
spectrum of users. That meant
architecting the application from the
ground up for delivery into a smart-
client environment designed for power
users, as well as a Web-based
environment for users who desired
simpler functionality, accessible
anywhere,” Webster says.
Yet, from the start, Thomson had a
clear vision of what it wanted to
achieve with the service-oriented
architecture initiative, and .NET
technology fit the concept, Webster
The team began to identify key business drivers. Most important, adds. Thomson collaborated with
the company needed to improve the user experience for its Microsoft’s .NET Enterprise Architecture
customers, including highly customizable workspaces and Team, .NEAT, to deliver this
sophisticated charting and graphing tools—via both Web and sophisticated capability.
other interfaces. Thomson Financial also wanted to better
integrate its product offerings so that customers wouldn’t have to deal with different applications for the
complex workflow of the product suite. By streamlining workflow and boosting productivity through one
integrated suite, Thomson ONE, customers could make decisions faster and better. Finally, by consolidating
a number of large and complex systems—many of which contained redundant data—the firm could save
millions of dollars in operating and infrastructure costs.
The enterprise architectural group examined systems from all the various development teams and groups
within the company in order to glean best practices. After conducting side-by-side comparisons and
narrowing the list down, the group began to refine the best practices to fit an integrated product
development life cycle. “It is impossible to meet everyone’s needs, but it is possible to focus on the
workflow, processes, and standards that can maximize productivity and compliance,” Hofeldt states.
The group chose to transition to a service-oriented architecture, which uses modular and reusable software
components to deploy services more quickly and easily. Working out the details of the transition was not
easy. Gabriel Gilabert, enterprise software architect for Thomson Financial, had to develop a set of .NET
components and user interfaces that would work across the organization and in all circumstances. He also
had to ensure that performance standards were in place, authentication mechanisms worked properly, and
workflow operated reliably.
“Some customers are interested only in our data; others are interested in our applications. Some customers
have their own portals and homegrown workflow and solutions. So, it was essential to build an environment
that could work in various situations and present data in the format that customers desired,” Gilabert points
out. The company began introducing the service-oriented architecture in May 2003.
Already the payoff has been realized. “By building applications that are open and flexible, we are able to
use IT resources and talent far more efficiently and strategically,” Hofeldt notes. “We have taken a great
deal of the administrative burden off the shoulders of programmers and freed them from constantly
handling custom applications development. Instead, they are able to focus on solutions that benefit the
company’s bottom line,” such as new services and faster applications.
Thomson Financial has also been able to begin its data center consolidation initiative, which is a huge
undertaking. By migrating off a legacy infrastructure and adopting a service-oriented architecture, the firm
is slimming down hardware and software infrastructure requirements. For example, instead of storing user
profiles, customer demographics, and other data within each application or service, it will use only one or
two data sets across the organization. “It has simplified data management enormously,” Gilabert explains.
Today, the TRA is an enterprise standard. According to Hofeldt, it is helping the company boost sales, trim
costs, and shorten development cycles. “One thing that makes a service-oriented architecture so attractive
is that cost savings and productivity gains accumulate over time as the organization is able to re-use
components and create enormous synergies,” Hofeldt says. “We have only begun to tap into the potential of
a service-oriented architecture.”
Samuel Greengard covers business and technology for numerous publications and is a past president of the
American Society of Journalists and Authors.
Photograph by Joshua Paul