It’s JADR (Just Another Damm Registry)

As the amount of SOA technology out there continues to multiply, so do the number of ways that the technology vendors persists artifacts for the design, development, abstraction, or governance tools. Typically, this means a registry, and the word from those building SOAs is that there are too many registries out there. Indeed, they are stating: “Just Another Damm Registry,” or JADR for short.

While the number of JADRs is not the problem, the fact that there is no clear standard or integration mechanism between the registries is clearly a problem. Services defined within a services modeling tool have to be redefined within the development tools, and redefined yet again within the governance tool. You get the pattern here.

Of course the “Super SOA Stack” guys are pointing out the fact that they own most of the platform, so integration won’t be an issue. However, nothing could be further from the case in the real world. Truth-be-told the acquisitions in recent years have yet to deliver clear integration within the technology sets. Thus, you’re really dealing with the same issues as you would if you purchased the technology from separate vendors. So, don’t be fooled.

So, what can be done? First and foremost, vendors need to come together on a common registry, and repository for that matter. Or, perhaps provide integration mechanisms between them. There have been many attempts to do this over the years, nothing that has been hugely successful. SOA vendors, despite preaching standards, tend to have a “not invited here attitude,” and thus most registries are proprietary. I understand that everyone has APIs, perhaps services, but all that really provides is a potential for a solution, not a solution unto itself. Moreover, the end user community needs to push back on the vendors that don’t provide registry integration.

I’m sure you have a few JADRs in your life. Now is the time to figure out how you normalize that number over time.