How to Get the Most from SOA

Service-oriented architecture, or SOA, has moved from buzzword of the moment to a concept that has absorbed the attention of CIOs at enterprises large and small (but mainly large). According to our State of the CIO 2007, 19 percent of local respondents were already working on their SOA, 15 percent were planning to start this year and 22 percent defined it as a long-term goal.

An architecture strategy that attempts to build all the software assets in a company using the service-oriented programming methodology and then integrating them through Web services, the grand vision for SOA is to enable businesspeople to take control of modifying, mixing and matching the different applications defined as services (for example, "get customer credit record" or "find invoice") together into new process combinations of their own. The idea is to prevent the business from having to wait, twiddling their thumbs, while IT develops new applications customized to their needs. The advantages of this strategy are obvious: increased agility; an improved understanding of business processes and therefore an increased ability to make business-process improvements; faster time to market; organic IT-business alignment; and, because the services can be reused, IT is freed up to innovate. The problems are just as obvious: Building an SOA is time-consuming and hard, and it requires a great deal of patience and commitment from both IT and the business.

Andy Baer, CIO of Comcast, has developed an internal IT strategy around SOA that aligns technology to meet his company's business needs and objectives. He also oversees the integration of the IT organizations in former Time Warner and Adelphia cable systems recently acquired by Comcast. He spoke with CIO about how to maximize the benefits of SOA.

Page Break

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

Andy Baer: What you're really getting out of 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 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 or not. I think 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.

Page Break

Can you describe your enterprise architecture at Comcast?

I think of enterprise architecture [EA] as business architecture. So I don't think of technology tools; I think about billing, ordering, customer service, human resources and payroll. To me, those are the components, and understanding how I want to break down business functions into macro-level services and understanding the relationships between them is what creates my enterprise architecture. Some people think of enterprise architecture more along the lines of enterprise technical architecture, meaning what the standard middleware software package is going to be across the enterprise, for example. And yes, I have that, and yes, that also relates to SOA, but to me that's not as important as business architecture.

EA is also a road map to make sure that every project we do is in the context of the architecture vision. Our enterprise architecture identifies all the various technology components that we need to run our business, but its purpose isn't just to paint a future vision — it also attempts to eliminate redundancy across projects. So if you take two projects and put them in the context of this enterprise architecture, you may see that they are related to the same component in your enterprise architecture. So you may want to combine the projects [or stop one of them].

In companies like ours, you don't build 100 percent of what you're deploying; you're buying a lot of it. And, unlike developing the applications yourself, not every vendor is going to deliver the components you need to meet your enterprise architecture vision in the technology stack.

Can you talk a bit more about your vision for SOA?

I'll give you the big functional components. Billing is one. Provisioning — setting up cable TV in a new customer's home, for example — is another big area where we have already made quite a bit of progress. Many of our provisioning systems have been deployed in an SOA model of services, which helps us then build the composite end to end.

[Cable] network management is another focus of SOA. We're building a Web services middle tier that is going to allow us to reuse a number of network management tools in different ways. One is to link to the tools inside a portal for our customer service agents to make it easier for our agents to troubleshoot cable problems with customers. We have also exposed the tools to handhelds that our techs are going to have out in the field. And ultimately, we'll expose those tools to our customers so they can check status anytime as well.

By following this SOA model, we're building a middle tier for network management that will then be reused for multiple purposes across the company. In addition, we are moving towards a complete Web services model for all of order management — not just provisioning.

So, piece by piece we're creating macro coarse-grained services that are implemented as a composite application made up of underlying services. Those services will be incorporated into other composite applications as part of our enterprise architecture.

Page Break

So you're building the base-level components at this point.

It's the base business building blocks, correct. There are infrastructure components which underlie all these, some of which are already built or are in development. So in addition to the business components you've got technical infrastructure components — things like authentication and authorization and identity — but those are being created as part of all these other applications that we're building. We're building out the infrastructure layer to support those larger business components.

Let's talk about some of the myths and realities. When is an SOA not really worth a CIO's time and effort?

I would say that you really shouldn't be looking at revamping your architecture if you don't have a dynamic business with lots of change. Why spend the money to swap out any of your infrastructure if it's working for you? Not only is it a lot of energy to go through this exercise, it's also a relatively newer technology, so the skill sets are harder to come by and you're going to be competing for talent with organizations that are growing. The people who have these skills want to work in a growing environment because it's more fun. Companies that are static or in decline will have a harder time finding people.

Some people are challenging the idea that reuse is going to be a big benefit of SOA. Some estimates say reuse is only about 10 percent to 25 percent. Others are asking why reuse should be a strategic goal when you may find a better way to design a service the second time around.

We're already seeing reuse here. The biggest challenge to reuse, in my experience, has been governance. The reason that it's a challenge is because by nature software engineers and architects have a "not-invented-here" syndrome. Every time there's a problem to solve, they believe that they have a better way of solving it. And that using someone else's code, or using someone else's service, is not going to be as good as if they reinvented it themselves because they have a unique way of dealing with the issues.

So I think that a governance model is really important to fostering and encouraging reuse. Everyone I talk to about governance says: "Oh yeah, that's a really big problem in our organization." I would say we are working hard on it here, but I don't think that we've solved it either. We've already seen some benefits of having an architecture review board in place that reviews all our big projects and can suggest ways to reuse services.

Maybe one of the differences here is that we're growing so rapidly and there's so much work to do that people aren't worrying about whether they'd like to reinvent things because they don't have the time. If they can find something to get the project done quicker, they're reusing it. For example, the billing services we've created have already been reused four times. That's partly because we set up an architecture review board that lets people know that there are services out there that can be reused.

Page Break

What would you say are the key aspects of the architecture review board?

The review board is responsible for helping, at least at the initial stages of a project, with the service architecture. Things like: "So what should the macro services be? And how do they relate to things that already exist?" The review board also maintains the business enterprise architecture, which is never static. And they are available as internal consultants for projects to help make decisions that are architectural in nature.

The architecture review board is not just a technology organization; we've created it as a subcommittee to our product steering committee so it will be more business focused.

How does that work?

The product steering committee is comprised of all the product owners across the business and is responsible for approving all new business product-related projects. We attached the architecture review board as a subcommittee so that it would not become a technology group for technology's sake, but a technology group that's responsible for supporting business projects.

It's one of the lessons I've learned having done SOA three or four times in different organizations. The last time I did an architecture review board we did it as a technology group and it didn't work nearly as well.

Do you have an example yet of a product that's gone through this process?

Recently, we were enhancing some of the features that we want to provide for our customers in video on-demand. The project team designed an architecture that we brought to the architecture review board. The board took a look at it and found a way to cut several months off the development schedule by reusing some of the capabilities that existed within the provisioning engine and within the new billing system we put together.

Page Break

What other aspects of governance work well?

I'm still learning how to do it, but I think there are several key pieces in governance. One is to have a registry or repository of services so that you can publish and keep documentation about the services that you're building. The architecture review board is another important piece.

Another big piece is having an examples library of services that we think work particularly well. That's been almost more powerful than anything else here. People ask what a good service looks like, but the examples aren't just code, they are a library of every artefact throughout the whole lifecycle. So what does the design look like? What does a test plan look like?

Another consideration is when you're introducing a lot of middleware technology to enable SOA, you don't want every part of the company going out and figuring out how to best implement those technologies independently. You want to coordinate the configuration of your middle tier centrally, not just to support the application, but to configure it for the best performance and operability.

SOA veterans say it's difficult to determine the right level of granularity for a service — what should be included within it and what shouldn't? Can you offer examples of how you approach this?

Sure, let's take billing as an example. We have a coarse-grained service called "charging", which includes everything from billing and taxing to bill presentment. Each one of those has its own composite service.

What we're trying to do is make sure that people are consistent in how they implement services.

A fine-grained service within "charging" might be "accounts hierarchy". I'm going to let an individual team manage that service rather than taking it to the architecture review board level.

What's the ROI on all this?

The big savings is time to market. For example, in the provisioning process, the ability for us to create a new product or a new flow in the provisioning engine is measured in days and weeks rather than in months, which is how long it takes in our non-SOA-compliant application.