Yet Another Try at Integrating Disparate Systems
First, I admit everyone in this industry has sung this song. It always seems to get way off key before we even reach the chorus! Why do I think this time will be different?
.NET works in three ways here. First, you can bridge disparate systems even when neither knows about the other, by writing a layer between them — and actually keep up with changes to those systems without introducing a death-spiral of increasing complexity. Second, the programming model is extremely simple, not just in being language independent but in hiding almost all of the communications complexity, thus increasing the likelihood that a given IT staff will succeed. Third, any new systems created via .NET intrinsically should be able to interact in an "intelligent" manner.
Again, this isn't a panacea, but I do think that this time we'll at least make it to the chorus of the tune before it becomes painful on the ears.
I promised two examples from the real world. I'm not going to mention names because these aren't full-blown case studies.
First, an airline wanted to include a particular car rental agency in its online travel offerings. The airline was UNIX/CORBA, the rental agency Windows. The rental company needed to implement a system in six months or less, and they needed it to have long-range potential instead of being a one-off. Thus they weren't enthused about the airline's direction, a direct socket connection.
The rental company quickly built a .NET SOAP/XML tool to convert requests and responses between the airline's system and their own. The benefits to the rental company were the speed with which they built the application, the ability to marshal IT developers with different backgrounds because of the simplicity of the .NET tools, and the creation of an interface to their systems that they can now map to other airlines independent of the airline's technology base.
This seems almost trivial — other than the usual difficulties inherent in two large corporations negotiating the melding of working data systems. I've been here, and I've found that most of these systems both take far longer than this one and break down the first time something changes. Such projects make ideal "starter projects" for .NET. The problem space is well known, allowing you to concentrate on the solution. In other words, you don't need to boil the ocean with your first .NET app.
The other example is a government unit that needed to create a portal for citizens to interact with the government, such as filling in tax forms. The unit was given three months to deploy the first online services (registration and enrollment), coordinating among three different agencies. The deadline was tied to the end of the tax year; thus any slip was effectively a year's slip.
The IT team and their consultant partners used BizTalk Server to create middleware that allows XML-enabled electronic forms to be submitted via a variety of channels and sent to different organizations. All the interfaces — Web site, portal, digital TV, kiosk — send XML to the middleware, where business rules determine where and how the data is routed. As needed, the software transforms the data into various formats used by the target systems.
This one's a bit more complex, and as noted they had some help. The consultants were led by folks from Microsoft Consulting Services, which I think gave them a leg up on building a large and high-visibility project with new technology — .NET technology wasn't completely new to MCS. Nonetheless, .NET let them pull this off in short order, and it's a great basis for the ongoing work.
Here are the conclusions I would draw from these examples.
A great place to get started with .NET is in translating data among systems.
.NET is real; there are mission-critical and financial-impact systems running today.
Integrate; don't rip-and-replace (unless it's sorely broken). Focus on adding business value and improving the time-to-value equation.
Either limit your scope for the first project, or get effective outside help.
The last two bullets should be givens for any project in any technology, in my view.
The obvious caveat is that I work for Microsoft; that said, I've been around awhile, I know what works, and I won't suggest things that don't work.