SOA & WOA Magazine

Two of the most common mistakes I've seen by inexperienced people trying to implement SOA are trying to make everything a service and building a huge data model and trying to force everyone to use it.


First of all, not every capability needs to or should be exposed as a service. There are overhead and security risks with exposing something as a service. If the capability is an internal capability that isn't used by anything outside your system, then don't make it a service. Another way to look at it is if it's a capability that isn't used or shared beyond the boundaries of your organization, then again it probably doesn't make much sense to create a service out of it. Of course there can always be exceptions, but you're better off by starting with those capabilities that are used beyond your system and organizational boundaries.

The second mistake is committed by those who spend months (or years) building huge, really detailed data models and accompanying XML schemas for their domains and then require anybody building services in that domain to use those schemas. Don't get me wrong, having common logical data models is a good thing and having some common schemas based on those models is also a good thing. The problem is that these guys are building these things like they're building relational database models, with little flexibility for customization and extension. Building data models and schemas for services is not the same as building a relational model for a system, even a very large system. It takes a very different approach guys. Take a look at NIEM and ebXML's Core Components, they were designed from the get go to support extension and customization. Their models and schemas are designed to be modular so that you can compose them into structures that match the specific needs of your service, yet they are all still derived from the same "core" such that you get the common understanding across all the services that use them. There's a lot more to talk about with this particular issue. I'll discuss more in a follow-up post.