SOA by definition refers to an architecture. Why is there not then a "best" architecture. As an industry we need to do more "Engineering" and less "Development". Engineering is the design of an implementation of an architecture, adhering to current accepted best practices.

When a construction project takes place for a building, there are "best" ways to do each task. The plans are laid out, the parallel tasks are run as such.

IBM is one of the most mature players in the industry, and has been around long enough to recognize a wave for what it is. SOA is a quantum leap in how we arrange our systems and transmit data. IBM is just taking a mature approach to it.

Yes, there can be a Standard SOA Stack that satisfies the bulk of the needs of most enterprises.

Will it be super simple? Probably not.
Will it be super light weight... um no.
Will IBM get there. *shakes magic 8 ball* .. you betcha.

There is a best way to establish a set of protocols and messaging standards and components of a "Standard SOA Stack". Then the architects at each company pick the parts they need for their implementation and head off to work.

Consultants are building their own tool kits. The industry is heading in this direction. IBM sees where we are going, which is exactly where we need to be, and they are taking a measured, mature approach to it.

My reading of your headline is that you have it backwards.

No, I think Dave has it exactly right - the architecture is a solution to a specific problem. To take your construction metaphor to its logical conclusion, we don't build office buildings as if they were really large bungalow houses, and we don't build warehouses as if they were really flat high rises. Different problems (business requirements) generate different architectures. Software is no different.

Will some of the vendors (such as IBM) have a big enough stack of technology that they can support almost any architecture? Probably. But given that many IT organizations are looking at SOA as a way to prevent vendor lock-in, that is not necessarily an important vendor quality to an IT organization.

I think Dave is somewhat on the correct path in that a SOA Stack is not the area to properly define. A SOA Framework would be where we should attack this problem space. Clearly the industry does not have a foundational understanding of what is/is not SOA at this time. BEA says one thing, IBM says another, Sun says yet another and so on. We do need to properly define the framework (e.g. ESB, UDDI, WSDL, XSD, SOAP) (might want to take out the last 2 so as to not confuse the issue). Does it require security, external, interface, utility, functional and/or data layers before its actually a SOA implementation?

There are currently several vendors stating that they have a SOA implementation solution, yet is it really SOA? Did they simply wrap old CORBA into a WSDL and say now we are a SOA?

There is a large need for the SOA Consortium to define an acceptable framework , not an architecture or a stack.

Good thoughts all!

Now for a few of my own...

1. In the building industry, there are many standard ways of doing things - actually more ubiquitous and more stable than in IT - but I don't think there is one best way to do it.
2. In construction, contractors and sub-contractors routinely propose alternative or better solutions for an already architected solution. It is often their technical ingenuity, and not just their management prowess, that creates extra value and generates extra profits.
3. There is plenty of room within the architecture of a building for vendors to engineer better solutions. And there are many ways to build buildings, and that's why they all look different (of course, that's the architecture)!
4. In building contracting, sub-contractors and suppliers routinely try to 'get into the specs'. It is the architect's job, at least in part, to allow an 'equivalent' product, and the key to this is to specify things loosely enough that an alternative product is possible. This is not always easy, and has been a burning problem with IT (and construction) forever. Services provide some level of solution to this - although I do not know exactly how it will turn out

I am not sure why some of the authors are picking so much on IBM. Yes, they have an infrastructure. But it is built at least in part to open standards, and does permit, at least to some degree, the deployment of .NET applications and services. What about Microsoft's approach? Or BEA or others? Each and every vendor could make a legitimate claim for a level of openness to the world outside their technology, and could also be criticized for a level of 'closed-ness' and self-interest.

SOA does offer some 'elegance' that previously was missing in knitting together solutions across the enterprise, seamlessly, and without regard to underlying technology - but, like anything man-made, it falls short of perfection in its implementation. But it is still a great solution!

And let's be realistic: even an SOA consortium would have tremendous vendor influences. Who would participate - and fund it? People from Sun, and Microsoft (maybe!), IBM, BEA, etc! This is like trying to make life fair; it's an elusive, but a noble objective which we should all go for.
_____________________

John Reiling, PMP, PE, MBA
Project Management Training Online
AcroVision Business Systems

Dave has a point. SOA is about agility, flexibility and heterogeneity. Will IBM, BEA, MS, Oracle or any one be able to build up a one shot solution to every problem? The mythical "Silver Bullet" . . .
SOA is not about Software but about architecture. Recently I read this somewhere and also qouted in one of my blog postings, "SOA is not what you buy, but it is what you do"
My job and personal alignments bend heavily towards open source technologies and over a period of time I have learnt that on problem will have million solution, you have to narrow down to the solution which is most appropriate to the problem surroundings in that case. Just a case of Open source ESB solutions, which one do you choose?
To give a over simplified example, if I have a large legacy and JBI support in ESB can be helpful I will choose OpenESB/ServiceMix, but if I am implementing a SOA architecture from zero with a small organisation which is more inclined towards processing and speed, I will pretty well end up using Synapse. Sometime if very tight integration between different components is desirable, I will definitely recommend a proprietary stack containing most desirable features and then pick up whatever is missing.
What is important is knowing the solutions and using the most appropriate one to solve the problem at hand.