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. 数据挖掘研究院
