At the time, the Redmondinos made a bunch of promises about how the Dynamics line (consisting of Dynamics GP based on Great Plains, Dynamics NV based on Navision, and Dynamics SL based on Solomon) would eventually become integrated onto a single codebase and "fleshed out" with a variety of workflow-oriented plug-ins -- or Snap-Ins, as Redmond calls them. Well, dance around the maypole a few months early because as of last week, the snapping in has begun.
The first two Snap-Ins might make you giggle: Microsoft actually spent dev time coming up with a Timesheet Management and a Vacation Management Snap-In. So for those of us not managing these tasks quite happily with Excel or a shared calendar, rejoice! You've now got a snap-in. But rather than giggling at their seemingly lightweight nature, you'd do better to pay some attention to how they're implemented.
Both Timesheet and Vacation allow users to submit data to a central store using Outlook. That means the Office suite is routing user data to multiple back-end server platforms, not simply Exchange. Under Vacation, for example, Outlook routes the request to the appropriate supervisor within the Office front end, and upon approval, it displays this result to the original user while simultaneously updating that user's information in Dynamics.
Redmond gets heavier right after these with a Business Data Lookup Snap-In designed for Dynamics AX as well as Dynamics CRM. These allow users to call up Office applications inside Dynamics task windows -- wheels within wheels, Microsoft apps within Microsoft apps. This functionality lets users, while in Dynamics, call up record-associated documents, copy data back and forth and even attach or delete document records from Dynamics records. Pretty cool, and something that users have been requesting for quite some time.
So is this revolutionary? Unfortunately, I don't see it that way. Microsoft's addition of Snap to the Dynamics line amounts to a custom plug-in architecture that .Net developers can use to build custom applications based on Dynamics and Office. Good, but hardly simple enough to combat competitors such as Notes/Domino.
I'm also concerned about Microsoft's beginning this on the front end. From a marketing standpoint, this approach certainly makes sense: Get Dynamics users excited and even dependent on custom apps built on this Snap architecture, then begin the longer and more painful process of merging the back-office server platforms into one product. Although it's certainly technically feasible to do this without affecting the slew of Snap applications that might be in existence by then, Redmond's track record in this department isn't stellar.
Sure, we consulting types are inwardly grinning. Worst case, we've got a new custom application architecture to sell. Best case, we can sell it twice and blame the rewrite on Microsoft. But from a journalist's perspective, all my little this-is-going-to-bite-us-in-the-booty alarm bells are going off. But then again, hey, I'm a long-time snark.
If you want to play with the Snap apps and draw your own conclusions you may be temporarily out of luck. Microsoft intends to give this code away as part of the CodeGallery on its .Net developer community site, but the linkwasn't active at the time of this writing. Chec k my SMB IT blog for the link, as well as screen shots of the Snap plug-ins, as soon as they become available.