Overcoming IT Siloes on the Road to SOA Success

Loraine Lawson

An IT developer friend of mine recently shared that, after nearly 10 years of employment with the same company, he's finally learning what it is his coworkers do all day.

 

This surprised me, since I know he's in cubicle farms with them and that, occasionally, they do go out for lunch.

 

"What do you mean? Don't you know what they do? You all are sitting right across from one another, you're all developers, you're the only people in the whole suite together? Hasn't what you do everyday come up in conversation at least once in the past 10 years?" I said.

 

"No."

 

We're not talking just small details, here. Obviously, they know generally what the other programmers do -- one person helps payroll, another works with the call center.


 

We're talking, literally, if one person had to be hospitalized, the rest of them - including the manager - would not be able to fill in for that person -- even if it involved their weekly payroll.

 

I'll grant you, this is a small company -- but it's not that small. There are probably easily a thousand employees working for this government agency.

 

I'm hoping and, frankly, assuming, that most organizations aren't quite that dysfunctional. Still, even if your developers are 25 percent more talkative and social than the ones in my friend's workplace, you can see how organizational issues within IT could be a big barrier for successful service-oriented architecture.

 

SOA requires developers to know what other developers are doing -- hence, you have repositories and registries. But even with these technology solutions, how the IT organization interacts internally and with the business is a common problem for SOA implementations, according to Eric Roch.

 

Roch, the chief technologist and National Practice Director for SOA with Perficient, examined how organizational issues impact SOA in a recent IT Toolbox blog post. He pointed out that IT divisions are typically organized in siloes, with managers and a staff supporting specific business function and the related systems. As a result, when these IT people build services, the services generally reflect this structure:

...when an IT functional group creates a service, it generally applies to their silo-ed view of systems. Or, given this limited view, they don't create functionality as a service, but bury the functionality in the silo-ed application with no interface at all.

You don't have to be a programmer or an architect to know that's not good.

 

Generally, articles about this type of problem just tell you to start a SOA Competency Center and move on, but Roch goes further. He suggests you give your SOA Competency Center a healthy jump-start and solve the silo problem by forming a cross-functional SOA Steering Committee.

 

This committee should include the leader of your SOA initiative, an enterprise architect, plus a lead architect from each functional-application systems. If you don't have all those architects, at least you can send someone from each silo.

 

He also outlines what type of things your SOA Steering Committee can do to make sure the silos don't spread to your SOA. Good stuff.

 

On a side note, last week, I wrote about Oracle's new Data Integration Suite. In a Q&A published this week, SearchOracle.com asked Bill Swanton, VP of AMR Research, point blank what he thinks about the new offering. It's a good interview. In addition to covering what this new product means for Oracle and its competitors, the article discusses MDM and data integration.



Add Comment      Leave a comment on this blog post
Feb 15, 2008 2:20 AM Rob Eamon Rob Eamon  says:
"when an IT functional group creates a service, it generally applies to their silo-ed view of systems. Or, given this limited view, they dont create functionality as a service, but bury the functionality in the silo-ed application with no interface at all.You dont have to be a programmer or an architect to know thats not good."IMO, without additional information, we have no idea whether or not it is good. Exposing everything as a service isn't always necessary. Adding functionality to an application doesn't always have to be shared.Do developers drive the overall IT landscape? Why do you expect that a programmer on the payroll system should know what a programmer on the call center system is doing?These are higher level problems to be addressed by managers, analysts and architects, not developers. An enterprise view of things is not really the job of the average developer.A centralized SOA group, in and of itself, isn't the right answer IMO. An EA group, with a possible SOA group within, is more appropriate--there is more to the IT landscape than services. Reply
Feb 15, 2008 2:53 AM Rob Eamon Rob Eamon  says:
"SOA requires developers to know what other developers are doing "No it doesn't. A developer needs to know the service(s) to use for the assigned task. If services don't exist, or if the developer is creating a new service, then a design team needs to establish the service contract/specs.Service-oriented development doesn't require any more or less communication than prior practices. Reply
Feb 8, 2010 9:15 AM taitai taitai  says:

good post, I verylike ed hardy clothesGucci handbags

Find a great range of Ed Hardy products. Ed Hardy Women's Ellerise Lowrise Sneaker Ed Hardy Women's

Reply

Post a comment

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

null
null

 

Subscribe to our Newsletters

Sign up now and get the best business technology insights direct to your inbox.