1. When there are 3 or more mobile applications
2. When there are 3 or more targeted operating systems or platforms
3. When they involve the integration of 3 or more back-end systems

Leaders in this space have included Sybase iAnywhere, Antenna, Dexterra, Syclo and Spring Wireless.  Microsoft goes from a large Mobile General Store with myriad solutions to a player in this space with a MEAP solution of our own:  Visual Studio is used to build the mobile logic and UI.  Merge Replication provides occasionally-connected data synchronization between SQL Server Compact on the mobile device and SQL Server in the data center.  SQL Server Business Intelligence Development Studio is used to visually create connections to back-end systems like SAP or databases like Oracle.  Data in transit is secured via SSL or VPN, data at rest is encrypted via device encryption, SQL Server Compact, BitLocker or programmatically through the Crypto API.  Integration packages that communicate with back-end systems are encrypted and digitally signed. 

We already have the best mobile email, calendaring, and contacts product in the business where Exchange Active Sync keeps Outlook and Outlook Mobile always up to date with Exchange Server.  Server-to-device as well as peer-to-peer device notifications are facilitated through WCF Store and Forward on Exchange.  Software and patch distribution along with device settings and policy management is accompished via System Center Configuration Manager.  ISA Server provides both VPN and Reverse Proxy access to roaming applications on the Internet on any platform.

When you put this stack in place and resuse it for multiple mobile applications instead of going with point solutions, ROI savings increase as the need for POCs, Pilots and training are reduced and the need for extra client access licenses is eliminated.  That’s Gartner’s first requirement.  We hit Gartner’s second requirement by uniformly supporting 3 mobile operating systems in the form of Windows, Windows CE, and Windows Mobile.  Last but not least, our SQL Server Integration Services technology combined with dozens of connectors mean we can connect your mobile devices with almost any back-end package or database.

Yes, Microsoft does have a Mobile Enterprise Application Platform that’s already proven to scale to tens of thousands of devices and it will definitely save you time and money.

- Rob

Before I dove head first into the world of Merge Replication, I always used RDA to get my customers up and running quickly.  Mobilizing an organization’s workforce quickly and easily is what it’s all about so they can start reaping the benefits.  In addition to a speedy time to market, there’s no faster or more scalable mobile sync technology on the market anywhere. 

So why wouldn’t I always use RDA?  Here’s a quick list:

1. You’re using Identity columns.
2. You want to replicate schema changes to the client.
3. You want change tracking on both the client and server to perform diffs of each of the tables during a sync instead of re-downloading the entire table.
4. You want to automatically resolve conflicts that arise when 2 people update the same data.
5. You want referential integrity constraints to be pushed down to the client database from SQL Server.
6. You don’t want to write code to perform synchronization or filter data.

If anything on the above list applied to you, you would shift to Merge Replication because it could manage ranges of Identity columns, push down schema changes, only sync data differences, resolve conflicts and push down a database’s referential integrity constraints.  Merge requires almost no code to get started and tables and columns are filtered visually via a wizard.

So why might you choose to use RDA?  Here’s another list:

1. Your Primary Keys use GUIDs instead of Identity columns.
2. Users don’t overwrite each other’s data so you don’t need conflict resolution.  The rule of “Last in Wins” works for you.
3. While you want indexes to be pushed down, you don’t care if your local SSCE database has referential integrity constraints applied.
4. You want to wrap the changes you upload to SQL Server in a transaction so that all changes are applied or none of them are.
5. Change tracking on the client is good enough and re-downloading updated server tables doesn’t take too long.
6. You developers don’t mind writing some sync code.
7. Be able to execute SQL and Stored Procedures directly against SQL Server via IIS.
8. You’re downloading read-only data.

If your solution meets the criteria in the list above, you’re probably a good candidate for using RDA instead of Merge.  Are there any other choices out there?

Back at MEDC 2007, we announced a new data replication technology for devices called Occasionally Connected Sync that would sit somewhere between RDA and Merge.  OCS as it used to be called was renamed Sync Services for ADO.NET and then was eventually merged into the Sync Framework. 

The Sync Framework is a developer-focused technology:

1. Supports conflict resolution.
2. Change tracking on the server as well as the client so that only data differences are exchanged.
3. Peer to Peer sync in the forthcoming v2 of Sync Framework.
4. Sync with databases other than SQL Server.
5. Best suited for SSCE running on a desktop or laptop.

The clearest differentiation that the Sync Framework has over Merge is its provider model which allows it to sync with other ADO.NET databases like Oracle or DB2.  SQL Server supports built-in P2P Transactional replication and v2 of the Sync Framework will allow you to do this via WCF.  If you development team doesn’t mind writing lots of sync code and needs to support scenarios like synchronizing with other databases from SSCE on the desktop, then the Sync Framework might be the way to go for you.  I wouldn’t yet recommend the Sync Framework for device sync since its wire protocol is currently based on the DataSet which may cause out of memory errors on Windows phones with limited working sets.

So where does this leave RDA?

The reason I’m writing this blog post is because time and time again I run into customer sync scenarios that don’t always need the power of Merge or the extra flexibility of the Sync Framework.  Most field service applications follow the same kind of pattern:

1. Lots of download-only lookup/reference tables that aren’t changed by the user.
2. Tables that are pushed down to the device that tell a user where to go and what to do.
3. Tables (sometimes empty) that are used to capture data from the user in the field that are upload-only.

These kinds of schemas don’t require conflict resolvers or server change tracking and are therefore well suited for RDA. 

What’s the big benefit of using RDA if a sync scenario meets its criteria?

1. You won’t modify SQL Server’s schema with GUIDs and Triggers.
2. You won’t degrade the performance of SQL Server by having it track changes and maintain extra metadata.
3. You will have the fastest and most scalable sync solution with least amount of hardware.
4. Time to market is shorter.

The big takeaway here is that I want you to consider your sync solution carefully before choosing a technology.  If your customer’s needs are met by RDA, then you should use it and reap the benefits of developing and deploying a simpler solution with fewer moving parts.

Remember Occam’s Razor.

-Rob