Thursday, October 12, 2006



Once upon a time, a young programmer was hired by a subsidiary of a large multinational company.
The environment was new and stimulating, projects were interesting, coworkers and the boss were nice and polite and, last but not least, there where gorgeus girls everywhere.
The young programmer did his best efforts to pass through the test period and made a number of fairly interesting things. The first project worked out was amazing. The international headquarter released an application to monitor customer's sell-out; that is, to monitor how much goods sold to retailers was actually sold to the end users. He quite hacked the international db structure and created a more efficient data-load procedure.
He proudly released the application to few end-users, and the news regarding the new system adoption escalated toward the headquarter. On the other side, the system rollout required a huge amount of T-SQL coding, was hard to test and to maintain but, who cared? It worked very well.
Time passed and the young programmer moved from project to project, always quite successful and was awarded with more responsibility. Actually, he became a project manager; he coded less but still dealt with all the small systems he created over the years. He disseminated within the company a number of stand-alone applications which addressed a number of business needs.
He did not know that catastrophe was behind the corner.
A time come when the foreign headquarter proposed a new datawarehouse. It was really powerful and a real improvement if compared with the old and semi-amateurish dw that was in place at that time. Unluckily, the old dw was the source of all the internal stovepipe application built by the young programmer.
He spent countless hours to make them back to work, rewriting the interfaces directly from the central system.

Probably you heard this war story many times in your career. Probably you've heard a lot about breaking down the walls among applications.

I learned the hard way that this is a central issue within a business environment. Many of us, as developers, often forget this lesson.
In my experience, developing a specific solution to address a specific business need must be accomplished keeping an eye to the environment where the application lives. Almost each application requires a data feed from other systems and may require feeding data elsewhere.

The best integration level, normally, is achieved through a consistent choice of the platform.
Microsoft environment is designed to natively integrate. For example, it's very easy to connect to data sources in excel, use VBA to manipulate them, publish the data in html format to a SharePoint site etc.
SAP has tight integration level, and, with the coming Mendocino, Office integration will be further improved.
But the platform matters to a different level. Simply pick one and stick to it. Microsoft, Oracle, SAP, whatever, each one of them has pros and cons, but in the medium-long run sticking to one will spare money and headaches.

2005 buzzword was SOA (Service Oriented Architecture). Someone sold it as the panacea to all the integration issues. It is not. It’s a sensible way to improve the heterogeneous system integration but it’s quite hard to develop and maintain. It is a good choice when real-time integration is required but does not solve everything.

Think of this the next time someone asks you to develop the next siloed application.


Post a Comment

Links to this post:

Create a Link

<< Home