I'm at the InfoWorld SOA Executive Forum today. I'm running a panel on Services and Contracts later this morning. San Jose is rainy, but warm. It's actually kind of pleasant. The room is packed. Apparently they were turning people away. That's a result of two things, I think: (a) a general uptick in tech spending and (b) a feeling among IT folks that SOA (via Web services) is going to be an important part of their IT strategy.
There are two tracks at the conference today, a business track and a technology track. The keynotes are similarly bifurcated. First up is Toby Redshaw, VP of IT Strategy at Motorola. Toby was employee 50 at Fedex and road that rocketship (65% CAGR) for 15 years.
Toby asks the questions. "What happens if you are 25% less efficient in IT than your direct competitor?" Don't know? Then ask your self the question: "What happens if you are 25% less efficient in customer acquisition and retention or supply chain?" Those questions are related and will be more so in the future.
There are some good parts of SOA:
- rapid delivery of projects because development shifts to composing applications.
- projects are built top-down from existing processes (i.e. prototyped) rather than a complex technical specification.
There's some bad:
- incomplete and evolving standards slow adoption
- concerns from loosely coupled architectures
- performance concerns from loose coupling
- directories (UDDI) have been slow to appear and that makes re-use difficult
There's some ugly: Web services management and security is the most pressing need
Some lessons learned:
- Start soon--its a long journey. Technology is not overly complex on the surface, but can be complicated to execute.
- This is a big change, so you need serious change management.
Here are the layers:
- Data layer: legacy apps
- Integration layer: EII, EIA, etc.
- Business logic layer: Web services based business objects
- Orchestration layer: composite application and workflow
- Presentation layer: portals, Web apps, thick clients
The orchestration layer has split into two parts: business process modeling and business activity monitoring (BAM). BAM allows companies to be proactive in a realtime sense rather than reactive.
Motorola has 180 services utilizing an SOA framework with new project opportunities identified each week. They are refining their SOA architecture with maturing orchestration, nomenclature, and governance guidelines. They are creating an ROI model. They have an adoption strategy with guidelines and best practices.
They have deployed 175 BAM monitors spanning Siebel to Oracle, Web channel to Siebel, and Siebel to Oracle EAI integration. Each BAM projects averages 50 rules.
Why is UDDI important? Its the directory. You need a Yellow Pages to find services. You need one of these. Don't let directory projects proliferate. Set one up and make everyone use it. Motorola uses Systinet's UDDI server.
Motorola does $5 billion per year in online sales. One of the services they built was a credit card service that everyone in the company could use. Motorola also built things like a warranty service. Toby gave 5 or 6 other examples of services they've built. Note that these aren't Web applications, but Web services that people who build Web applications can use as building blocks.
"Small agile kills big slow. Big agile is just scary..." Motorola wants to be big and agile. If you haven't started on SOA, you're in reverse. While this is conceptually simple, its a big set of changes. You need to build the infrastructure or you end up with meta-spaghetti. Change the way you buy and consume software. Find partners and phone a friend.
