Mark Carges: How are Companies Using SOA


The technology track keynote is from Mark Carges, CTO of BEA Systems. BEA and InfoWorld did a study of SOA. They found that only 28% of companies have adopted SOA. About half of those were pilot projects. Only 8% have some kind of enterprise-wide approach (which puts what Toby just described in the state-of-the-art). Early adopters are making SOA a priority. Of those doing something, 14% things is a critical priority in the next 12 months, but over 60% put it in the critical or high priority category over the next 3-5 years.

SOA is an attribute and architectural approach than a project in and of itself.

The pain points identified in the study are architecture flexibility, integrating legacy apps, business partner integration, customer service initiatives, and employee self-service. One interesting point: if you build a service to replace 13 siloed serviced around the enterprise, how do you pay for it? How do you service it? How do you set service levels? Moving to an SOA puts IT in the business of creating products.

Another interesting data point from the study: managers tend to think their company is "half way there" in SOA. Technical folks are more likely to say "haven't started" or "just starting." The positive spin on this is that managers are seeing benefits just from the first few projects, to they're bullish.

SOAs evolve from simple Web services that expose data and actions to composite apps that create business processes, all the way to full-service infrastructures that service the enterprise's IT needs.

The tendency in pilots is to build point-to-point Web services. The services are directly connected and tightly coupled. The security, service levels, exceptions handling, and so on are built into the code. This makes the service difficult to re-purpose and re-use. The service infrastructure provides these services to all of the Web services that you deploy.

The following table is modeled on something Mark put up. There's nothing here that you probably haven't thought about before, but it's interesting to see it all together:

EfficientAgile
Controlin the hands of ITin the hands of users
Platform standardizedbest of breed
Datacentralizeddistributed
Driverone source of truthspeed
Example: financialsclosing with the mainframeclosing with Excel

The conclusion to draw from this table isn't "left-bad, right-good." There's a spectrum on each line and a variety of reasons to make particular choices. For example, I doubt that GM would become a more agile company by foregoing its enterprise financial package and moving everything to spreadsheets, but I'd also bet that even in the largest companies, lost of spreadsheets feed into the closing.