Based in San Francisco, investment bank Putnam Lovell NBF Securities focuses on the financial services industry and, as a result, has asset management, banking, insurance, investment, and brokerage firms among its clients. In addition to mergers and acquisitions advice, private placements, and public offerings, the firm offers research on more than one hundred public companies. Putnam Lovell is an affiliate of National Bank Financial, one of Canada's largest investment banks, which acquired Putnam Lovell in 2002.
Rodric R. O'Connor was Putnam Lovell NBF's chief technology officer until February 2003, when he left to take a similar post with Blum Capital Partners, L.P., a San Francisco-based investment firm. Under O'Connor's leadership, Putnam Lovell adopted a Web services strategy. To implement the plan, he tapped Salesforce.com Enterprise to handle customer relationship management (CRM) tasks, Grand Central Communication Enterprise Solution as an integration hub, BlueMatrix Research for research content creation, and Appshop for Oracle financial applications hosting.
O'Connor says he was attracted to Web services because the technology is ideally suited for Putnam Lovell's most important task—information distribution.
Our primary business process is distributing our research to clients via e-mail. We've accomplished that by using Web services to integrate to Internet-based applications. We are using Web services to build point-to-point integration between those applications.
We have a research creation application called BlueMatrix that is a native Internet application. The server application resides on an Internet server provided and managed by BlueMatrix. Equity research analysts use the system to create equity research. It has an internal database of equity data that is populated from market feeds with share price and trading volume information. It builds a database of all the equities that we produce research on. Via a Web browser, a research analyst initiates a piece of research on a specific company. The system then prepopulates the content with numerics from the database and allows the analyst to add free-form text into their research piece. There is a work flow within the application for editorial and compliance approval, to ensure the legality of the research content. The application then distributes the finished research piece to eight different content aggregators—Bloomberg and Thompson Financial's FirstCall, for example.
O'Connor notes that Putnam Lovell wanted to use Web services to start distributing research directly to its clients—individual institutional investors—rather than supplying its information through external content aggregators.
We have a CRM system—Salesforce.com—that's also Internet-based. We use Salesforce.com to keep track of all our contacts and companies. Within the application, each employee tracks whether or not the client wants to receive research, and what type of research he wants to receive.
BlueMatrix has the content, and Salesforce.com has the client's interest profile. The challenge that we had was to connect to the two independently managed and distributed systems to enable the content to be automatically sent to those clients that had a specific interest.
To link BlueMatrix with Salesforce.com, Putnam Lovell uses a network-based service provided by Grand Central Communications.
Grand Central is also an Internet-based application, which we subscribe to as a service. We do not have any server or software running on our network, but we configure their service to have a connector between BlueMatrix and Salesforce.com. Within the Grand Central network, we can configure the security rules to specify the type of data that is allowed to pass between the two applications.
Early on, Putnam Lovell relied on "screen scraping''—acquiring data displayed on screen by capturing the characters with a utility. Screen scraping has long been used to save meaningful data for later use. However, distributing data elements into identifiable fields for database processing must be done manually, or via intelligence built into a specialized software utility. As more text on Web pages is defined by XML tags, the job of transferring data elements into databases and between applications can be made more automatic.
We initially used Grand Central to screen scrape Salesforce.com. Then, about two months after we went into production, Salesforce.com released their direct XML API. We could then build another connector in Grand Central to point to Salesforce.com's XML API.
Although Salesforce.com now supports XML, Grand Central is still highly useful as an intermediary.
We could have built a point-to-point connection, but there are several advantages to having a proxy service. For one, it isolates each vendor's connection from changes at the other. We have seen several examples of this. For example, Salesforce.com changed its protocol and implemented its API in a new way. We developed an additional connector from Grand Central to Salesforce.com's new API. We tested it to make sure it was correct, and then switched over from the old way to the new way without any intervention from BlueMatrix.
Proxying the interface made the whole process more resilient and cheaper to maintain. It reduced the cost of ownership, as you do not have to get everybody involved. Grand Central also provides reporting, e-mail notification of errors, and security.
Taking advantage of new features, as software vendors offer them, is key to deriving the maximum value out of Web services, says O'Connor.
Salesforce.com is coming out with a SOAP-based interface within the next few months. On average, I would expect each vendor to change some aspect of its API each year.
O'Connor notes that the real power of an integration hub, like Grand Central, becomes apparent as more applications are added to the Web services implementation.
The real benefit is when you add multiple applications, for example, when a third application needs to be integrated with either of the existing nodes. You would just have to add a connector to the new application. The connection and security of the other two application connections can be reused.
An integration hub can also simplify a complex Web services arrangement, says O'Connor.
Say you have six applications, with each application talking to three others—you end up with a rat's nest of connections, where it could become very expensive to replace or upgrade any application. If you proxy the connection to a single location, it makes the process of change much simpler.
For Putnam Lovell, the introduction of Web services marked a major change from the way the firm used to handle information distribution. As a result of its Web services initiative, Putnam Lovell has been able to slice its $40,000 quarterly budget for information distribution in half.
We produce a lot of printed research. Part of the Web services effort was to move from printed to electronic content and distribution of research. One of the drivers was reducing the cost of printing and mailing. It doesn't cost you anything if you find there's been a change of address, for example.
Converting its information distribution process over to Web services was a carefully planned process, says O'Connor.
The first step was to use the Internet to provision our generic enterprise applications in early 2000. That excluded actual transaction applications, such as our trading platforms and our communications, which we kept inside the firewall. With every generic application, we looked to provision via an Internet-based service, rather than the traditional strategy of owning and looking after the software. Down that path, we implemented BlueMatrix, Salesforce.com, and several other components of our application infrastructures. We wanted to outsource our nonfinancial transaction applications wherever it made sense.
Because we followed this strategy, we could not follow the normal path of integration by utilizing direct database-to-database connections. We didn't have visibility to the database layer, only to vendor-provided APIs into the application.
Implementing the system was fast and relatively painfree, says O'Connor.
We went live in September 2001. It took four weeks to get the first business process automated. It went very quickly.
Web services also helps Putnam Lovell clients find information on their own.
BlueMatrix provides a client research library on our Web site. Clients can log in with a user name and password and see all of the research that we've published. They can access recent reports, or search for all content on a particular company.
We control permission to access the library via a custom field in Salesforce.com. An employee can very easily set up a client to have access. The integration is using the same Grand Central network as the research distribution process. It was very simple for us to reuse the configuration from the first process to enable the second—approximately eight hours of development.
O'Connor says he doesn't worry too much about Web standards, since they're beyond his control. He has resisted the temptation to try any features that are on the extreme cutting edge.
I am using very low-level Web services standards—such as SOAP and XML. I'm using my own dialect of XML because the dataset is very simple, and I control both the producer and consumer of the content. I'm not using ebXML or riXML to define research.
Since we are using XML as a standard, we can use XML tools to examine and manipulate the data. We are using SOAP where we can. The standards I'm using are lower down the stack, and hence, well defined and unlikely to change. The confusion seems to be higher up the stack in the areas of security and transaction control.
Error handling and asynchronous messaging can be pitfalls for novice Web services developers, says O'Connor.
Traditionally, this kind of integration would be via a synchronous RPC. So you've got to make sure your developers understand that they have to handle errors and asynchronous messaging somewhat differently.
For example, application A starts query one, "I want to know X,'' and then disconnects. It then sends query two, "I want to know Y.'' It may not get the return sets back in the same order that it requested them. The first answer it may get back is, "This is Y.'' Or, it may get something back saying, "I can't give you Y—there's an error giving you Y.'' So you've got to make sure that your calls—what it's asking for and what it gets back—are correlated. You have to make sure that the error handling is set up to cope with the time differences between your queries and replies.
Security, says O'Connor, is also an important consideration, particularly when dealing with critical proprietary research information. Fortunately, the implementation he designed has built-in safeguards.
We're relying on Grand Central to reduce the complexity of security. BlueMatrix doesn't have visibility into the Salesforce.com. BlueMatrix authenticates to Grand Central, and uses SSL to encrypt authentication and session data.
We configure Grand Central to allow BlueMatrix to initiate specific queries into the Salesforce.com connector. It then authenticates to Salesforce.com, and again communicates over an SSL-encrypted session.
It's interesting, because none of these applications are on my side of the firewall. Everything is on the Internet. Each one is an island with its own secure perimeter. BlueMatrix can't talk to Salesforce.com directly, it can only talk to Grand Central, and Grand Central has tight security between it and both vendors: BlueMatrix and Salesforce.com.
O'Connor admits, however, that this arrangement probably wouldn't be secure enough for an enterprise engaged in financial transactions.
As a conscious decision, I would not put financial transactions over the same mechanism.
A strong advocate of Web services, O'Connor believes that the technology is ready for widespread use.
I would recommend it for application-to-application integration, where you control all the points of integration. It's a much more controllable environment than a one-to-many integration, or opening up internal legacy systems to anybody coming in from the Internet. That's a very different scenario than integrating two applications that are already built natively for the Internet.
He feels that Web services are also suitable for exchanging data with business partners, although he advocates starting small.
It depends on how many vendors you have, and the amount of resource you are willing to dedicate. I would recommend starting with a manageable number of parties, and, once operational, expand the quantity of connection points. Historically, if you had a requirement to electronically transmit content to your suppliers, your options were limited to expensive EDI or quick and dirty FTP that's relatively easy to set up, but very expensive to manage going forward. Today you have an alternative of using Web services, and using a service like Grand Central to manage the connections for you.
Down the road, O'Connor sees emerging Web services technologies providing a path to new types of applications.
Some of the emerging standards are very interesting. I think the WS process and the WS security are going to open a lot of applications and new uses.
O'Connor feels that the Web services market will eventually be dominated by major software players.
I think the larger ones are tying it up pretty well. IBM certainly seems to be investing a lot into this. And then, there's Microsoft with its .NET initiative. Sun seems to be trying to catch up.
I've been watching the field very closely for the last couple of years. It started off with some of the smaller, emerging companies who were doing some very interesting things—and I think they will continue to have a position in certain niches. But the larger players are setting the direction of the standards.
O'Connor advises IT managers to start small and to pick their Web services projects carefully.
I would suggest trying to pick small integration projects to act as good learning exercises.
The global recession has set back many Web services projects, says O'Connor.
There have been a lot of pilot projects. I think lots of those were probably hit by the recession, so maybe they didn't get from pilot to widespread adoption because of the economy.
As Web services become more popular, it will become easier for enterprises to implement the technology, says O'Connor.
It will become more and more of a standard. We are starting to see off-the-shelf applications and services that include Web services APIs. I think you'll probably see a large number of them blossom over the next twenty-four months. I think one of the catalysts to this adoption will be new XML-based offerings from Microsoft, such as Office 2003 and xDocs.
Microsoft InfoPath (formerly code-named XDocs) is a new product in the Microsoft Office family that streamlines the process of gathering information by enabling teams and organizations to easily create and work with rich, dynamic forms. The information collected can be integrated with a broad range of business processes because InfoPath supports any customer-defined XML schema and integrates with XML Web services. As a result, InfoPath helps to connect information workers directly to organizational information. It gives them the ability to act on it, which leads to greater business impact.
|
