CA Meets IT, Integration Challenges (Continued)
Integration Insanity
Carter: Traditionally CA has grown by acquisition. What kind of challenges does that pose for you as an IT architect and manager, and how do you go about integrating all of these things without losing your mind?
LeClair: [laughter] Well, we have done a few acquisitions over the years, although not any really large ones for several years now. While CA has six of what we call "brand units," we do not organize the company into these sort of independent business units that have their own IT systems. We do an effective job of figuring out the best systems to run CA's operations, and when an acquisition happens, we have a well-defined practice of quickly converging on whatever systems the acquired company was working from and implementing a single support system. When we acquire another company, typically it has its own system for doing technical support for its customers, and we rapidly get the company migrated to and running on the same system with the rest of CA.
CA's value-add to the customer is that you've got one entity to deal with on a variety of products, you have the same interfaces no matter which product you use, and you get a lot of useful information delivered to you. Initially, we also look at the portfolio of any company we acquire. If it has a better solution in some area, then we'll use that.
Carter: How do the development and IT teams interact at CA? Do you "eat your own dog food"?
LeClair: One of the unusual things about CA is that we've changed the way we work. There used to be the development organization that developed products, and then there was IT. And like at many software companies, IT was getting essentially measured and compensated based on availability of systems and meeting service levels and that kind of thing.
This is important stuff to do, but we are an infrastructure-management company, in large measure, and we have storage and security and management. So a couple years ago, we instituted a slight alteration in the dictates of our IT shop, which is that it must use CA software if CA has a solution for anything that it wants to do. And not only do the IT folks have to use it, but they also have to put the beta releases of those products into production.
So, we go live with a huge variety of CA products on beta software, which serves an interesting purpose in that it tightens the activity between the IT and development organizations. Because [IT is] still essentially interested in providing a high service level, I think this change has helped raise the bar throughout all of the organizations because they have to be accountable to their peers: When they put a product out on beta, it must be ready to go and the last reality test before we ship the product.
So, this makes the two operations work together. It also helps to encourage the interaction between our IT organization and the product group, so they can help provide direct feedback early at the development cycle and help make the products better. I think that has helped remarkably in terms of improving the general quality of software. CA is also providing a good real-world experience for our products before our customers get them.
Carter: How do standards efforts impact your job at CA?
LeClair: We participate in all of the major standards groups. I personally happen to represent CA in the Web Services Interoperability Organization (WS-I). I'm directly involved in making sure the things we do are compliant with the evolving WS-I standards, and making sure that what we're building is Webservices-interoperable. We're involved in key standards that tie back into our products, with people on board at CA actively involved in a variety of different groups, and we focus on making sure that our products comply. And, as appropriate, our IT solution will use those and be compliant with standards as well.
Back to top
|
Maintaining Data Integrity 
