Share via

More than server side integration...

  • Article

In all of the integration marketing buzz, I think someone forgot about integration on the desktop and in the presentation layer, or is that not important anymore?  What is the future of integration technologies like automation and portals?

In an IT world driven by sparkling marketing tag lines, and three letter acronymns of the day (ESB, SOA, MDA, WS*,...), we often forget the tools we use to actually display or deliver something to the target customer.  The next time you are asked to deliver an integration strategy, I urge you to remember the desktop and the price the shared resources on the desktop will have to pay if you ignore this very important integration point.

Point #1: - The crowded desktop

When we finish defining all our web services, messages, queues and other related infrastructure don't forget we have figure a way to deliver this information to the desktop.  I have seen call centers where 10+ or more apps are required to stay open just to do business (and this does not include any additional applications the end user may open up from time, to time or reports).  The point here is that all packages will not fit into your server side integration strategy, so be prepared with a desktop integration strategy.  In many cases this form of integration will be implemented using automation or messaging across AppDomains (hmmm) or some other approach.

Point #2 - All right there on the web page (what else do you want)

There will always be one person on the design or requirements team, that knows what everybody needs to see on the desktop or home page of the portal.   While we may have talked to a few representives of the business or our end customers, we will never get this right for everybody.  The answer to point #1 is not a portal for all solutions.  However I advocate flexibility in our user interface presentations (think personalization here).  When creating the integration strategy for the desktop or the portal just make it clear up front people need the ability to consume the information right their current job function.  There is also a need to allow people to change this presentation view or create multiple views as they change roles.

Conclusions

Leverage the platform on the desktop and allow personalization in your web sites/portals especially line of business sites.  Think about delivering line of business functionality into portlets, and web parts if you are a .NET developer.  Look at Office as delivery tool for line of business applications with solutions such as Visual Studio Tools for Office (VSTO).  This will help reduce deployment cost, the need to create customized user interfaces, and provide the ability to leverage the desktop in effort to automate client side applications.  Finally think about leveraging forms technologies such as InfoPath or some other form tool of choice instead of building "quick" ASP.NET or WinForm applications to perform simple read/update/insert tasks or consuming web services, to reduce development time. 

ASP.NET 2.0 and the portal framework technologies will find make building web parts main stream.  I have been waiting for this one a long time.  The ability to provide line of business applications or views in an ala cart like view, allowing the target customer to consume the information in a manner most useful to they way they work.  My MSN has had this feature for sometime now, give it a spin by logging on with any passport enabled e-mail address.

The point here is to focus on the real business problem when creating an integration strategy.  The real business problem here is to provide seamless access to information, just rember in a sea of buzz words don't forget about the desktop solution, because at the end of the day, you can have all the web services, and WS-* goo you want.  The user does not see your ESB, SOA, or EI-EI-O, they only see the presentation layer.

Here are some things to consider when building a platform for integration on the desktop

Happy coding...