Cheers, I'm Pekka and I work as a Enterprise Integration Architect at Frends. One major part of my role is creating tangible value to the customers in their wide variety of integration challenges; how to transform business requirements into technical implementations: processes, patterns and workflows. Also I work with our International Operations and keep up with the latest Microsoft technology events.
 
The joint blogging effort with all our architecture group members was actually a great idea - we all have a bit different angle and personal interests but still we all share the same passion for creating the best ever integration solutions for the end customers. I'm not going to go very deep in technology in my blog posts - I think there's a lot of great bloggers’ i.e. in geekswithblogs who do just that - I'm going to write more general gibberish about my experiences in the integration jungle. So hopefully we are able to share some of our insights to all the other architects without artefacts out there.
 
Typically integration problems are technically not very challenging - move data from point A to system B or create some set of SOA services that fulfill the requirements X, Y and Z. From my experience nearly all problems arise from the lack of communication between multiple stakeholders within the projects. Like any agile methodology out there the basis of successful integration project is communication between all the players and the ability to hear what others are actually saying. More specifically using agile methods in integration projects is a whole new topic itself and I'm not going to discuss it in this post.
 
According to several studies and surveys typical information technology project has quite poor change to excel the expectations; either budgetary or schedule. Custom-development projects where integration is its own niche area have the highest risk to overrun the costs and/or time frame. The larger projects have higher risk of failure so the good old 'divide and conquer' algorithm works well also when managing and planning integration projects. Gather all the requirements then plan the high level architecture well and then break it up to little pieces and get things rolling.
 
Multi-vendor project environments bring their own complexity as well which has to be managed by the end customer at least in some extent. I've seen too many cases where end customer has clear business requirements but no desire to control the development phase of the solution - roles and responsibilities for different project vendors just float in the air and everyone starts doing something. Lack of information flow and control is one big reason for overrunning project schedules. Of course it is natural for all vendors to implement the easiest solution and assume that other partners are solving the trickier problems. And when finally project reaches the end-to-end testing phase implemented process may lack some key features because no one has had the responsibility to solve the problems and design a proper solution for it.
 
The other extent is over thinking: brainstorming after brainstorming without any decisions. Maybe after a fifth workshop most use cases and basic patterns have been discussed and evaluated over and over again and still no decisions have been made. It's a fact that requirements and specifications can and will change and there's always some part that needs improvements or additions. Still at some points there's a need to get things going but still prepare for changes. I've seen all the different variations of integration projects from doing without thinking to thinking without doing.
 
Integration projects; like any other issue where there's no absolute right or wrong answer; are a lot about balancing between what and how. What is actually required to do and what are the nice to have features that might need a lot of additional investments. Sometimes requirement documents tend to get so big that originating reasons why the integration was so important almost vanish. In this case usually less is more - as a general rule I would say: Parse out the absolutely essential requirements; then use some effort on high-level design because mistakes here can mean serious money. Do not spend too much time on low level specifications, design and implement a small piece of the process as fast as it's reasonable. Use the experience gained from the first small step; improve the needed parts and move on to the next piece. Nothing is nearly as valuable as the lessons learnt from actual running solution even if it's a small piece of the complete scenario. And always try to think ahead to the future and plan how to handle the solution life-cycle.
 
It's not a shame to ask and make questions. It's more of a stupidity to believe that all the others share exactly same thoughts than you do. Our VP, International Operations once told me that do not assume anything or you make an ass out of u and me. We in Finland have a saying 'vääntää rautalangasta' - direct translation 'to twist from wire' - which means 'to explain in very simple terms'. Both of these are a pretty good advice for all the integration workers and other stakeholders in the integration ecosystem. Don't get overcomplicated and use the tools and technologies where they're meant to be used.