Two Most Common SOA Mistakes

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.

Woohoo! I Can Now Access Your Crap Data More Easily

With the growing popularity of enterprise mashups, more and more organizations are starting to service-enable their data sources, i.e. building web services on top of their data sources to enable access to their data. Unfortunately, most of them are not addressing their underlying data problems first before doing so. I've written about this before, talking about the need for an SOA data strategy. It still amazes me to see how many people out there still think that by slapping web services on top of their databases, amazing things will happen and their problems will be solved. All that will happen is that this will bring all their crappy data up front and center on some flashy AJAX-based mashup application. We've seen this before in the past with BI and reporting applications that used some of the more traditional data integration technologies. After the BI app is built, the end user realizes that she still can't do any real analysis because the data is crap.

soa, enterprise mashups, data strategy

SOA Data Strategy Article

Just a follow-up to an earlier post about SOA Data Strategy. The article we wrote is now available on the SOA Web Services Journal here.

soa

SOA Data Strategy

Typically when organizations are thinking about migrating to an SOA, the data environment is not one of the top things on their mind. They are more focused on modeling their business processes and figuring out how to create reusable services out of them. That is rather unfortunate because the data plays a big part in driving the proper execution of those business processes. Additionally, the data environment of the typical large organization has a lot of issues that will only become more problematic in an SOA environment due to the more real-time and integrated nature of SOA-based applications. In some cases, trying to move to an SOA without first addressing the data issues is akin to trying to build a high-rise on top of a landfill--you're trying to build a complex structure on top of a weak foundation.

A couple of colleagues and I are writing an article for the June issue of SOA Web Services Journal that talks about creating a data strategy for an SOA to ensure that you have a proper data environment before jumping into your SOA transformation. This strategy addresses issues such as data governance, enterprise data models and standards, security, data quality, and data services. Keep an eye out for it. There's a lot of useful information in there. A lot of it is based on experiences from projects our firm's done with the large government agencies. I will post a link to the article here when they make it available online.

SOA, data integration