Enterprise integration of disparate systems

Question

We're about to embark on a fairly large integration effort to kill off a bunch of Access and Sql Server databases and get everything into one coherent enterprise system. There are also a number of other systems (accounting, CRM, payroll, MS Exchange) that hold critical data that we need to integrate (use for data validation in other systems), report on and otherwise expose. It is likely that some of these systems will change in the next few years, so we need to isolate our systems to be ready for change.

Ideally we would be able to expose our forms in a consistent manner across as many of our our systems as possible without having to re-develop them for each system. We are currently targeting SharePoint (2007 and soon 2010), Office (2007 and soon 2010 - Word, Excel, PowerPoint and Outlook), Reporting Services, .Net console applications, .Net Windows applications, shell extensions, and with the possibility of exposing some functionality on mobile devices (BlackBerries currently, maybe iPhones later) and via our website.

We're moving development to Visual Studio 2010 (from 2005) ahead of migrating to SharePoint 2010 and Office 2010. Given that most of our development is presently targeted to the .Net framework (mostly in C#) it seems logical to stick with this unless there is some compelling reason to switch frameworks/platform for some aspects.

We're thinking of your standard Database->Data Integration layer->Business Objects Layer->Web Services (or REST) layer->Client Application plus doing our own client application with WPF (or something else?) forms that can also be exposed in the MS systems (SharePoint, Office, Windows).

So, we don't want much, just everything :) Basically we need to isolate ourselves from database and systems changes, create an API that can be used throughout our systems and then make this functionality available in our client applications.

I'm very keen to get pointers from anyone who has tips on how to pull this off. Should we look at the Enterprise Library as a place to start or roll our own? Is REST with ASP.Net MVC2 a better solution than Web Services for a system like this? Will WPF deliver forms re-use or is there something better?

Answer 1

I recommend a single composite application for your line-of-business app. Then there is no need for "forms reuse", the views are all there and integrated together. All your data-access can go through a single reusable layer and all 3rd party apps communicate with your system via techniques of SOA.

Microsoft's Patterns and Practices group provides a few frameworks for developing a single extensible, pluggable, modular application that can be deployed through a single deployment mechanism. If you have complete control over the platform of your end users (Windows) I recommend WPF using Prism and if you don't, I recommend Silverlight using Prism. If you haven't moved to WPF/Silverlight technology yet, you can develop a good Windows Forms composite application with the Unity components from Prism or SCSF, which is much more developed for WinForms. (Note: WPF can host WinForms controls and WinForms can host WPF controls, so you can create a hybrid solution with existing components as you move toward a complete and cohesive enterprise system.) Beware that SCSF/CAB and Prism both leverage some well-known design patterns, so you'll have to get your team familiar with the fundamentals of OO and design patterns.

As for the mobile solution, I think you can develop WPF views for Windows Mobile, therein allowing you to reuse the app with different views on mobile devices.

WCF is hands down the best SOA framework for doing inter-application communication in .NET.

If you have workflow, approval chains or document routing needs, then use WF. You can even integrate workflow editors into the composite application so end users can modify and update workflows as business needs change - all without calling you.

If you're not already using an ORM, then I'd recommend nHibernate. Don't develop your own data access layer for integration with RDBMS, it's foolish; see here.

Look into using ClickOnce for deployment of this application; it's got built-in support for allowing your app to detect and auto-install updates.