During a briefing from Microsoft's xRM team, the question of how to integrate structured and unstructured data arose. If xRM (the Dynamics platform) is good at the structured stuff, and SharePoint is good at unstructured content, what's the right way to bridge the two?
Back in my Oracle days, we faced exactly the same question. At a technology level, there's no obvious answer. Bring together two development teams (the structured and unstructured specialists), and you'll first get a lot of technical-level discussions. How should security work? What API changes might be needed? How will metadata span the two kinds of information?
Unfortunately, there's no immediately obvious answer to these questions. In fact, the options are so broad, and the risk of technological quagmires so great, that the endeavor might easily grind to a halt. People ponder the options, argue over which one is best, go back and ponder some more…
At Microsoft, a clear use case accelerated this discussion. The Public Sector group developed a constituent services application for local governments that combines both SharePoint and xRM. Notice how specific the application, the Citizen Service Platform, is. Not all government, but local government. Not several government functions, but constituent services.
Undoubtedly, the Citizen Service Platform team made it clear which kinds of integrations were important, and which weren't. It's not too hard to generalize the use case to other situations. After all, we're talking about the same CRM platform that property managers and church pastors use, for different but similar purposes.
For people who are already sold on use cases as the right foundation for designing products, this might seem like a "Well, duh!" sort of observation. However, many product teams go full speed ahead with only the haziest use case, or to be honest, none at all. If their product decision-making process is too slow, or too error-prone, they might reconsider the value of a very specific use case.
[Cross-posted at The Heretech.]