LOGIN | REGISTER NOW | SUBSCRIBE
 
 
News on Monday
more>>
SharePoint Tech Report
more>>


   

 
 
Download Current Issue
ISSUE 3/15/2010 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?


 
blogs tab
Windows Phone 7 will not support HTML 5
Windows Phone 7 will not support HTML 5.
03/15/2010 05:51 PM EST

ASP.NET MVC 2 Ships
ASP.NET MVC 2 has shipped.
03/12/2010 10:26 AM EST

Microsoft plans 'open' Silverlight analytics framework
Microsoft is going to announce a multipurpose analytics framework for Silverlight at MIX.
03/11/2010 09:51 AM EST

 

Events calendar tab
SHARE
3/14/2010 to 3/18/2010
Seattle, Wa.
SHARE

Cloud Connect
3/15/2010 to 3/18/2010
Santa Clara, Calif.
TechWeb

Microsoft MIX10
3/15/2010 to 3/17/2010
Las Vegas
Microsoft

SharePointPro Summit & Expo
3/16/2010 to 3/19/2010
Las Vegas
Penton Media

TheServerSide Java Symposium
3/17/2010 to 3/19/2010
Las Vegas
TechTarget


 
print Printable version 
Most Read Latest News Blog Resources
Mono brings .NET to Android
At Microsoft MIX, Mono will unveil the ability to port .NET applications to the Android op...

Guest View: The half-agile path leads nowhere
While businesses are taking on agile and adopting its practices, an incomplete implementat...

Even with its success, .NET causes some consternation
Despite its popularity, the developer community believes that .NET isn't being fully serve...

Digg!  Digg
Reddit  Reddit
Slashdot  Slashdot
Share on facebook  Facebook
Share on Twitter  Twitter

David S. Linthicum: Roles Shift in SOA World


By David S. Linthicum
December 1, 2007 — 
Lately, a number of debates have erupted around who does what when it comes to building and operating a SOA. It’s a turf battle really. For instance, who controls the data services? The database administrator (DBA) or the developers? Who controls SOA security? Who controls services management? You get the idea.

Truth-be-told, traditional IT roles and responsibilities can be turned on their head when one takes into account the special needs of SOA. Consider these facts:

• SOAs are widely distributed.

• SOAs are loosely coupled.

• SOAs deal with things that are autonomous.

• SOAs deal with IT assets you may not own or control.

• SOAs deal with abstracted data.

So, while the demarcation lines were easy to draw, today they are not that cut and dried, and indeed may not be functional in the world of SOA. For the best analysis of the changing nature of roles and responsibilities, let’s break SOA up into five categories: Data, Service, Process, Policy and Security.

Data
DBAs have clear responsibility within the traditional enterprise: the database. However, within the world of SOAs, many databases are abstracted into virtual databases that exist only in middleware, re-representing the source physical schema as something that’s much more logical to the SOA. So, does the DBA control the abstraction layer as well?

Moreover, we have the notion of data services, or the externalization of data, bound to behavior, delivered as a true service. Since you interact with the database, does the DBA control that? Or, perhaps the developers who built those services?

While best practices are emerging, it does seem logical that the person or persons who maintain the database also maintain the database interfaces as well, with data abstraction being one of those things. Data abstraction is, in essence, a schema configuration layer between the physical database and the service. However, things do get a bit cloudy when it comes to data services. Typically, developers have built them, and thus could be the best people to maintain them…hopefully working with the DBA. Of course, many DBAs are claiming control of data services.

Service
While this seems like a no-brainer, with developers controlling the design, development and testing of services, many argue that the role of the developer is too low-level to control such an important enterprise asset. Many enterprises create new positions such as the services czar (I’m not kidding), who is someone who controls the life cycle of the services.

Further complicating this is the fact that many services are built on top of existing interfaces to legacy systems. So another question emerges, much like the data issues presented previously: Do those who maintain the legacy assets also control the services exposed from those systems, or do developers take over at that point? This is still a much-debated issue.

Process
The control of business processes is clearly in the domain of the “business analysts,” or that’s the argument. However, business analysts have little interest, or skill, in creating, deploying and testing a business process layer. As such, there are specialists in business process or orchestration who are appearing in many enterprises to work with the business analysts to create, test and deploy processes that exist within a SOA. While process and orchestration tools are clearly being sold as tools for the business analysts, there needs to be someone else in that mix who is more technically focused to actually do the work—somebody else you need to hire.

Policy
SOA governance is important, and policies are the way we control access to services that span many heterogeneous systems. Since service policies are something new,many are grabbing at the role of creating and maintaining policies within a SOA.

Typically there are two arguments. First, that policy is really security, and thus should be in the domain of the security administrator. Second, that this is really about policy, and not security, so we need to create a SOA governance administration position, somebody who will create and maintain policies around services.

Clearly, policies are way out of the domain of the security team. They are just about control and usage, and not about access. Thus, you indeed need to place the management policies in the domain of SOA governance and a SOA governance specialist in charge of polices.

Security
While security will clearly be in the domain of the existing security team, many are finding that the federated nature of SOA and the use of the identity management approach to security can be a bit of a reach for the existing security staff. While it makes sense that they indeed maintain the security infrastructure of the SOA, it also makes sense that they hire or retain staffers to do identity management right.

The Debate Will Continue
What’s clear here is that the debate around roles and responsibilities surrounding the existence of a SOA is going to go on for a while as people look to acquire turf, and the normal office politics begins to show its ugly head. However, this should be less about turf and politics and more about functional understanding and strategic importance. You may have to change your thinking around roles and responsibilities, but that’s a good thing if you ask me.

David S. Linthicum is a managing partner at ZapThink. Reach him at david@zapthink.com.


Share this link: http://www.sdtimes.com/link/31381
 

Add comment


Name*
Email*  
Country     


  • Comment
  • Preview
Loading