CA Meets IT, Integration Challenges (Continued)
Web Services Behind Portlets
Matt Carter: First of all, can you give me an overview of Computer Associates' infrastructure?
Don LeClair: From an IT perspective, we have a single, worldwide, connected network to tie all of the offices together. CA is 15,000 people in 50 countries. This includes software development not just in North America, but also in Europe, Australia, and the Far East. We have a distributed organization, both from the sales force and where we do business as well as how we build and deliver our products. We also have a lot of applications that run on Windows servers, on Solaris, on Java—so like any large company with a long history, we have a remarkable mix of hardware and software that we build and deploy our applications from.
Carter: How does CA use its own software products in your IT environment?
LeClair: Given the heterogeneous environment of our back end, we have a strong incentive to Web-enable and provide a consistent interface across all of these systems for our employees and customers. This would help our employees do their jobs more effectively, as well as give our customers a single view to CA. If you are a CA customer, you want to be able to get information about your outstanding contracts, your build, your support issues, and get that kind of information online. And if you're an employee, certainly in a customer-facing position, you want to be able to get the same kind of information that we're giving to our clients.
Doing that requires a lot of integration across platforms. So, we use a combination of a Microsoft platform as well as Java. Given our operating environments today—Windows, Solaris, and mainframe—we tend to use Java in a lot of our multiplatform applications. Plus, we have significant initiatives to deliver useful pieces of functionality as portlets in the context of those portals, so you can get information from multiple environments and integrate that onto a single person or customer's desktop.
Carter: Do portlets use Web services, or are they separate from Web services?
LeClair: That's a good question. We would describe a portlet as a piece of information that you can get at, or a presentation or a window within a portal. As a matter of fact, the standard in our IT-development practice is to provide the business-level processing behind those portlets as Web services.
So, here's our typical portlet implementation: We'll have a Web service, for example, to get customer information such as name and address and display it. In that case, it probably is talking to our contract-tracking system on a mainframe. We then deliver a Web service, and then we can deploy that through a portal and present that to a UI, to either an employee or a customer. We're building a growing library of Web service implementations to integrate our back-end systems, and we are seeing more opportunities to deal with the orchestration question: "How do I tie together multiple Web services to help automate a specific business process?" You end up reusing those Web services in different contexts.
Carter: What types of applications have been successfully deployed at CA using this approach?
LeClair: Some of the key ones that we've enabled first are our "Customer Connect" applications. These give customers a connection to CA to help manage their own environments, and that falls into two areas. One is getting information about their status as customers, so they can maintain and update their own contacts or business contacts for the different CA products they use. This has been popular with our clients.
One of the other application types is on the support side, providing Web-based access to all of our support systems. So, those are the two that are driving a lot of volume. Over time, we'll extend this infrastructure so that you can not only acquire CA products, but also get parts and software delivered to you and installed on multiple platforms through this kind of connectivity.
Back to top
|
Introduction
