'Enough with WOA, stick to SOA,' say IT architects -- I say drop WOA and SOA

Mike Meehan at SearchSOA.com has done some homework on the use of Web Oriented Architecture (WOA), and the IT folks in the field are fed up. Enough with the labels, they seem to be saying.

And they raise excellent points. I for one am by no means wed to the "WOA" nomenclature. Several other industry analysts recently told me as much -- "WOA is not the right term" -- during a dinner at the IBM Impact event earlier this month.

So what really counts is the concept of not waiting for legacy-abstracted, middleware-driven, investments-heavy SOA before seeking wider berth for more easily available and ecumenical services-based productivity. WOA is about lightweight and externally and internally originating standards-based services and independent data being used now, not after an internal SOA infrastructure is ready (and for some that's five years).

You know the drill: Build it and the services will come, so ramp up on that registry/repository, BPEL engine, scalable middleware beyond EAI, SOAP and XML appliances, additional performance management tier, ESB, federated ESB, data services tier (and another 15 acronyms there), SCA/SDO support, Windows Communication Foundation hooks, and so on.

All of these can be powerful and necessary, but there are multiple tracks to services and business processes flexibility. And some of them are ready now, are cheap and even free, and they are driving a lot of innovation in the field. And some do not require all that much input from IT.

So, true, WOA, isn't an architecture, it's a webby style of apps and integration, of mashups and open APIs, of using REST and RIA clients, all from a variety of Internet sources. It's integration as a service, too. These can all be composited, accessed and managed by an enterprise's internal SOA, or not. The services can come from a cloud, public or private.

These webby assets could just as well come together as portals, standalone Web apps, SaaS, or RIA front ends for composited ecology services that support extended enterprise processes. The point is there's no need to wait.

So WOA as a term does help break out of the box in terms of thinking about SOA as more than "the long journey" that can pay off in years after taking years to develop. Some vendors would have you believe that SOA only happens after a PO is issued for their products.

I also think there's more grassroots political support for webby apps/services inside of sales, marketing, procurement, and line of business departments in many enterprises. They don't know they want SOA, but they may know they want what they see on the Web, and from startups, and from their personal use. They want to use tools they can understand, that help them reach customers and suppliers, by gaining productivity by doing a Web search and signing up to build or access a useful service.

We are now, and this week in particular at the Web 2.0 Expo, seeing rapid ramp-up of services hybrids -- of public/private clouds, services ecologies, internal and external hosting, social enterprise media tools, mashups in myriad forms, integration of services regardless of origins or types of aggregation.

You can today begin a business online and scale it without an IT department, or an on-premises datacenter. You just can.

These concepts are different from what most think of SOA. And if all of this is SOA, then SOA loses it's meaning. By meaning too much, SOA means nothing. And SOA as a term has never been easy for a lot of people to get comfortable with, in the first place.

The fact is that the definitions of and distinctions between applications, platforms, services, tools, clouds, portals, integration, middleware are -- all up for grabs. IT as a concept is up for grabs. The shifts in the software arena at that disruptive. It's why Microsoft is seeking to buy Yahoo, and not Oracle.

I'll bet if Mike Meehan interviewed some sales executives, marketing managers, business analysts, entrepreneurs, and human resources directors -- they might say they cotton to WOA and what it means, more than to SOA and what they don't yet understand it to mean.

This is my point: SOA as nomenclature is not cutting it outside of the IT department. And perhaps some other phrases and/or value propositions would better describe than WOA the innovation now taking place.

Perhaps we need to drop any reference to architecture, and reference the payoffs -- better online work done quickly and cheaply. Perhaps we should call is SWA -- services without architecture, and be done with enterprise architecture all together (as Dave Linthicum boldly suggested recently).

Perhaps it's best not to call what's going on anything at all, and just do it. And that includes dumping "SOA" as a name. So I'm for dropping WOA, but let's be really honest and drop "SOA" too.