Wow! Oracle wants to buy BEA

Isn't it a wonderful world?

A few days ago I posted that infrastructure-vendors won't win from ERP-vendors with regard to SOA. And a few days later I motivated my thoughts here and here.

And now Joe McKendrick reports that Oracle (= Siebel, PeopleSoft, Hyperion, J.D. Edwards) wants to buy BEA.

Things go quicker than I expected...

SAP TechEd - We Have SOA

Read what Jeff Schneider - who recently attended the SAP TechEd in Las Vegas - has to tell.

I felt like SAP really got it. Unfortunately, I felt like most of the people at the conference didn't.

That is exactly what I meant when I posted my rebellion articles on SOA out-of-the-box and "Boxed" SOA.

"Boxed" SOA

Joe McKendrick reacted on my article about SOA out-of-the-box.

But vendor offerings are limited to tools and templates.

Of course he is right, I am talking about tools and templates. But let me explain myself in more detail. What I mean is that SOA - in a technical sense - is currently offered by suppliers of business solutions including the standards based infrastructure as I mentioned. When I buy a modern ERP-solution I get a populated SOA infrastructure with it, based on open standards. This open standards based infrastructure can also be used for the governance of external services and processes. It is not unwise to use these integrated out-of-the-box SOA products as a starting point and as enforcers.

And about this one of Joe:

Good SOA is ultimately the product of enlightened and savvy management, smart and well-trained people, and competitive drive. And that part will never come in a box.

He is right again, but does enlightened and savvy management, smart and well-trained people, and competitive drive exclusively lead to SOA? I don't think so. That would be too easy. I think it is a prerequisite for SOA but we still must enforce SOA if we are believers... A business wise populated infrastructure with tools and templates, integrated out-of-the-box, and based on open standards will help. An unpopulated infrastructure will also help... but slower. Much, much slower!

SOA out-of-the-box

Quote from BEA:

The idea that you can buy SOA in a box is both amusing and dangerous. Thinking that you could buy a piece of software, install it, and then say you have SOA is the amusing part. The dangerous part is what might happen to your job once you install the software and people start to realize you are nowhere near having a service-oriented architecture.

And BEA continues:

The reality is that before you can implement an SOA, you’ve got to lay the groundwork: a service bus where your services will managed, a service registry for identifying services, a security framework to manage access to your services, a solid understanding of your business processes, an enterprise architecture showing your eventual goals, and most importantly, executive sponsorship for your project. Putting these pieces in place will “service enable” your enterprise and get you ready to start implementing your SOA.

BEA is not the only one who says so. And BEA, among all others, forgets the most important part along the service registry: a business events registry - which is one of the most important keys to the success of SOA. Why did they forget to mention this part? Probably because they don't offer it in their product portfolio (but I may be wrong on this one).

All true I would say. But... what about ERP-vendors like SAP? SAP offers a service bus, service registry, events registry, canonical data management, business processes, services deployments (!), business monitoring, business process management, security... out-of-the-box. Yes, of course the implementation must be tuned and configured. But it's all there, out-of-the-box. The difference between infrastucture-vendors and ERP-vendors like SAP is that the infrastructure-vendors are trying to sell infrastructure to the business whilst ERP-vendors are selling business solutions to the business. Who do you think will win?

I think mid-size companies that fully rely on ERP-solutions will be the first companies with a full-fledged SOA in place. The big enterprises relying on custom development will need much more years to reach the same level of SOA maturity. They might benefit from a kick start by building their SOA around one or more open SOA based ERP-systems that are positioned as dominant business solutions at enterprise level. If they don't, the big enterprises will all get behind on their smaller competitors with regard to vital IT-maturity within the years to come.

So the idea that you can buy SOA in a box might turn out not to be as amusing as the infrastructure-vendors want us to believe. It might even turn out to be dangerous to ignore the idea. Building an unpopulated SOA infrastructure from scratch, as the infrastructure-vendors are promoting, might in the end turn into a big mistake.

Low-Tech Approach to Understanding SOA

Dan North published a splendid article explaining SOA by describing a 1950 business scenario and then translating it into technology-agnostic SOA terms.

A PDF can be found here. In this PDF Dan comes up with a few tips:

DO

1. Have a user

• Embedded in the business (he should not be a technical person)
• Who cares about the outcome

2. Pass around forms and documents, not objects (or representations of objects)
3. Remember that calling across the network takes time
4. Use coarse-grained services rather the a lot of little calls


Don't

1. Design for what you don't need

• Does it really need to be available 99.999% of the time?
• This includes security, availability - in fact all the “-ilities”

2. "Phone home" i.e. don't make service calls to things that are available locally

• Better still, don’t expose them as services in the first place

3. Create a service if you only have one client

4. Expose your privates

• In other words, avoid putting implementation details into the message

5. Have transactions across multiple service calls

• Instead package all the calls into a single, coarse-grained service call