A novel idea: SOA teams talking to each other

Most companies have multiple teams for various phases of IT and SOA projects, and sometimes, if conditions are right, these teams actually talk to each other. 

Fellow ZDNet blogger Dana Gardner provides fresh insights into perhaps the biggest obstacle to SOA development and deployment: teams just don't talk to each other. "It sure looks right now from what we see of SOA pilots, and the complexity that sprouts from only a handful of services, that SOA will not scale effectively unless groups of people who previously had nothing to do with one another make like Mr. Spock and assume the Mind Meld position."

SOA is inherently an enterprise initiative, providing services that can be shared and reused across business boundaries. The folks at Mindreef have been studying this issue for some time, and have come out with a collaborative platform that they say will support repositories and inputs from various people involved in the SOA process -- architects, developers, testers, and end-users alike.

The other week, I had the opportunity to do a Q&A session with Mindreef's founders, Frank Grossman and Jim Moskun, about these challenges. (Q&A posted here at Webservices.Org). Mindreef's new platform, Coral, evokes images of colorful life forms, all interdependent in a great chain of life that creates a safe, sheltered lagoon. In an SOA archipelago, team members are interdependent upon one another as well.

“As customers move beyond single Web service deployments into meaningful SOAs, one of their primary challenges is to break down organizational silos and communicate effectively across disparate teams,” said Grossman. “XML is a good language for developing services, but not for communicating with people.”

Grossman adds that "People whose jobs are in governance, testing, diagnostic, and support need to communicate in some way. They need to be able to ask, ‘here’s a scenario that I’m working on, and can you look at it as well?’ You need to be able to look at the same scenario. Responses such as ‘hey, I’m in .NET, here’s my .NET log of a problem,’ or, ‘I called you, and your service failed, so it’s your problem’ really tug at the flexibility that people are investing in. If you can’t solve those types of problems through communications, then that flexibility investment disappears quickly."