It has come to my attention that there are really two kinds of SOA technology vendors out there, old school and new school - each offering very different approaches to solving the SOA problem. I'm not going to mention any particular vendors, but you guys can guess who they are.

Keep in mind, what's important here is that not any particular approach or technology is correct, but that the approaches and technologies you employ match up with your requirements and business expectations. However, it's also important to understand exactly the type of technology you're going to leverage, including its core - that's the point I'm attempting to make here.

Old-School SOA Vendors
Old-school SOA vendors are those with "legacy" integration or application development solutions that "SOA-tized" their stuff, basically adding Web services interfaces, orchestration, governance, etc. I've been here before - you're working with an existing product and existing customers, and suddenly a new wave comes along. You have to keep up, thus you add another layer onto your existing product to make it a bit more acceptable to the market, and also maintain backward compatibility with your existing customer base. It's not easy.

Thus, these guys layer on top of the existing stuff or creating another layer of abstraction, hiding the core with new interfaces, management layers, and perhaps a repository. Some of the common characteristics of old-school SOA are:

• The need for their underlying and legacy core technology in order for their SOA technology to function. This is a sure sign that there are dependencies on the older coretech. This is not bad unto itself, but could cause performance issues as you work down to the core from the abstraction and back again. You'll find that some of the existing vendors do this, but some do not, so make sure to try before you buy.
• The product cannot deal with coupling, only cohesion. This means that the SOA solution relies on an asynchronous messing system for internal communications - in other words information-oriented integration - and can't deal with behavior or service-oriented integration. Thus, reusing service through this type of infrastructure can be problematic, if not impossible.
• The need for backward compatibility with an existing base of users. Again, this is not a bad thing necessarily, but if your SOA product is trying to maintain a portion of itself as a proprietary subsystem, that could limit development going forward.

The downside is that you could have an archaic product at the core, and it may not handle the new ways in which we're aligning systems today, at the service level and not at the information level alone.

New-School SOA Vendors
New-school SOA vendors are those with new products. Typically they are start-ups with fewer than 100 or so customers. They don't need to SOA-tize their products because they are typically built from the ground up with SOA in mind, doing both service- and information-based integration. However, there are advantages to starting with a new canvas, and some drawbacks as well.

The upside to new school is that you're getting a product that's built specifically for the application to an SOA. Moreover, these new guys typically solve a particular portion of the problem, such providing just the registry, development environment, or federated identity. They don't offer "all-in-one SOA solutions," which is good. To date, I've not seen a product that can do it all. The downside is that you're dealing with a new company that is going to change a lot in the next few years, in good ways and bad ways.

Conclusion
So, which school should graduate from? At the end of the day, it's really a matter of your problem domain and the problems you're looking to solve, that's for certain. However, I can say that the new school products have more applicability for the SOA space since they are specifically designed for that purpose. The old school products just seem like quick reinventions, many of which are limited by the existing core product. When building an SOA, you don't want limitations - it's hard enough as is.