Loving SOA Too Much

I recently had a conversation with Gordon van Huizen, “Strategic Technology Advisor” at Sonic Software (I think an STA is a CTO with more time to sit under the proverbial apple tree and think deep thoughts).

Gordon is a smart guy who’s well-regarded in the SOA space, and during our conversation he mentioned that Sonic had a customer with what must be a relatively new problem: one of its spanking new services was being overused.

Now this glass can be either half full or half empty. The company was undoubtedly tickled that people found the service so useful that they wanted to take advantage of it. But the situation also raised some issues that the customer needed to address.

You see, they had quietly released the service to five development teams to let them give it a try. But when the customer did an audit on the service sometime later, they discovered that almost three dozen applications in multiple business units were calling on the service. 

Why is this a problem? Well, as van Huizen pointed out, it indicated a security problem to start. It also could be a political problem, as certain groups in the organization had funded the service, but now other groups were using it–potentially causing prioritization issues and hurt feelings. The rapid, unauthorized adoption also raised the specter of “rogue services” within the enterprise: services built and published on the sly but without proper oversight to guarantee that toes go unstepped upon and deployment policies get followed. Can you say “SarbOx violation”? I thought you could.

Van Huizen used this anecdote as a lead in for a pitch about the company’s Actional service management tool, but it does raise some interesting questions. As services become easier to deploy, do they also become huge security and compliance holes? SOA could, like Visicalc and wifi access points in the past–become yet another technology that initially spirals beyond IT’s control and has to be dragged kicking and screaming back to the fold.

Granted, it’s a development technology, so your average end user isn’t likely to put up a service on her laptop and start serving it throughout the enterprise. But developers–at least the best ones–are both lazy and dumb, thus their willingness to ask stupid questions in pursuit of time-saving answers. And if putting up a small, “hidden” service will get the sales team off their backs, why not?

It’ll be up to CIOs and their development managers to explain exactly why not–and in terms that don’t leave room for interpretation. The service-based organization has the potential to be more open, flexible, and fast-moving than ever before possible. But like sports cars, all that power and performance can also get you wrapped around a tree faster than ever.

Governance–from the initial architectural development stages through post-deployment monitoring–will become increasingly critical as services themselves become more critical. And establishing that governance early–thus embedding necessary policies and mindsets when things are relatively simply–is the best path to avoid headline-making mistakes in the future.

If you love something, set it free. If it turns around and bites your hand off, maybe you should have adopted a guinea pig instead.