Reaping the Big Business Benefits of SOA

Reaping the Big Business Benefits of Service Oriented Architecture SOA By Christopher Koch

July 02, 2007 — CIO — In an exclusive interview with CIO, Andy Baer, CIO of Comcast, talks with Christopher Koch about maximizing the benefits of service-oriented architecture (SOA), including reusing assets and cutting time to market. His expertise stems from developing the internal IT strategy that aligns technology to meet overall business needs and objectives, including oversight of the company's customer care, billing and ordering systems; data centers; desktops; internal telephony; and other corporate systems. He also oversees the integration of the IT organizations in former Time Warner and Adelphia cable systems recently acquired by Comcast.

Christopher Koch, CIO: What do you see as the primary business reason for doing an SOA?

Andy Baer: What you're really getting out of service-oriented architecture SOA are a couple of really big business benefits. You're getting reuse of a lot of the assets which you're spending money to develop. So you're getting much more value out of the dollar that you're investing in technology because you're able to use things more easily. That's number one.

Second, you're getting quicker time to market. Because you're able to assemble components more easily, you can extend those components more easily so that as the business changes, you're able to react more rapidly to those changes in the business.

I can give you some specific examples here at Comcast. For example, we have two billing systems-60 percent of customers are billed on one and 40 percent are on the other-mostly as a result of our acquisition of AT&T Broadband. We had applications that needed access to the billing system; developers had to write the same APIs [Application Programming Interfaces] twice to access each of the billing systems.

One of the first things we did was to create what we call a billing services mediation layer. Now the developers write the APIs once, to the service layer, rather than to each billing system. That saves money, but it also gives my staff the opportunity to add functionality into the Web services layer themselves without having to go to my billing vendors, which is a lot more cost-effective and a lot more timely.

And, if at some point in time I need to change anything with my back-end billing systems, I can do it without having to change the other applications that link to it because they are connected to the service layer rather than directly to the billing systems.

How do you distinguish between SOA and enterprise architecture?

I don't believe that service-oriented architecture SOA is enterprise architecture. SOA is an enabling technology, but it's not enterprise architecture. You need to have a vision of your business and describe your business in an enterprise architecture, which can be implemented by a Web services SOA service-oriented architecture or not. I think service-oriented architecture SOA is an enabling technology for that enterprise architecture, but it isn't by itself enterprise architecture. Enterprise architecture is required regardless of whether you implement that by SOA or not.

Source: http://www.cio.com