Who's in charge of SOA? You might think it would be the enterprise architect, but, according to David Linthicum, well-known SOA authority and managing partner at ZapThink, that's not what's happening.
Enterprise architects often lack the organizational and budgetary authority to guide the development of any architecture, much less a service-oriented architecture, Linthicum explained in a recent podcast. As a result, there's no central control and the architecture is growing haphazardly. Predictably enough, this lack of planning is creating problems.
Assuming you're not trying to build a MOA - mess-oriented architecture -- perhaps it's time to look at who's manning the SOA shop.
Linthicum has been hitting this topic hard recently over at InfoWorld's SOA Center. His take is that SOA needs an enforcer, someone who can "teach, enforce, control and make sure everything stays on the level" as you build your SOA. This isn't about technology; it's about management:
"The core problem is that most Service Oriented Architecture issues are not technology problems. At their essence, they are people issues."
In addition to the podcast, he's written about this issue in posts such as, "Why Enterprise Architects Continue to Fall Short with SOA...and Enterprise Architecture," "Do you have the Political Will for SOA?" and, my personal favorite, "Do you Have a DSG (Dumb SOA Guy) Issue?"
Mike Kavis, a blogger at IT Toolbox, responded to Linthicum's posts with a list of traits a SOA enforcer would need. His list includes, of course, a conceptual understanding of SOA, but also political clout and those tricky skills -- ever in short supply within IT - of aligning technology with business and dealing with people.
Todd Biske, an enterprise architect and blogger, recently tackled a related management question on his blog, Outside the Box.
Biske raises a more tactical question -- though with strong strategic implications -- of who's managing services.
He started the discussion with this post on the Service Lifecycle Management cycle, in which he proposed companies create a new role: service managers to manage, monitor and market the service:
"My recommendation is to align service management along functional domains. A service manager will likely manage multiple services, simply because there will be services that change frequently and some that change infrequently, so having one manager per service won't make for an even distribution of work. The one thing to avoid, however, is to have the same person managing both the service and the consumer of a service."
In a more recent post, he responded to a question about who within an organization would be qualified to be a service manager (okay, I confess - it was from me).
Surprisingly, he doesn't necessarily see that role housed in IT.
"At its core, the service manager is a relationship manager- managing the interactions with all of the service consumers. What makes this interesting is when you think about exposing services externally. Using the concept of relationship management, it is very unlikely that the service manager would be someone from IT, rather, it's probably someone from a business unit that "owns" the relationship with partners. At the same time, it's also very unlikely that business is structured in such a way to support internal service management."
He also explains what it would mean to market a service and why that's important:
"The real point that needs to be made is that a service manager can not take the field of dreams approach of simply building it, putting some information into the repository, and then hoping consumers find it. They have to hit the pavement and go talk to people."
Clearly, you can't move to something as significant as SOA without assigning roles and creating an institutionalized chain of authority. For those well into SOA, it's time to give this issue some serious thought. Those just getting started will want to keep an eye on this topic and, hopefully, you'll be able to benefit from the early adopters as they figure out how best to manage SOA.