Last night I spoke at the Metro Toronto .NET Users Group on Interop between J2EE and .NET apps, using a variety of techniques but especially Web Services. There was a bit of code, but really the emphasis was on philosophy, the kind of “big picture” approaches you can take to make interop happen. I mentioned more than once that it's important to know what exactly you mean by interop and what it is that you want your two (or three, or more) applications to be able to do together. The sorts of projects that really don't work are the ones that start “how can we use BizTalk in our firm?”. Start with a business problem, and if it looks like BizTalk will make it possible to solve the problem, then go from there, but don't pick the solution and then go looking for a problem.

This came back around in the post-presentation questions and chat, and we got to talking about the importance of requirements. I'm hip deep in a project where we spent months just settling the requirements, but as a result the project has moved forward into code after spending years (before I came on board) getting about halfway through design and then stopping and starting over. For Enterprise work (and these interop issues are generally Enterprise) there is simply no substitute for real solid business requirements that are completely nailed down before anyone starts designing, followed by a properly thought through design. I don't go through all that for three day projects, putting together a little Sharepoint web part or some Windows Service that sends email at night about additions to the database today, but I sure go through it for anything that needs more than one programmer or that will take more than a month.

I was reminded of a funny article I read a while back called Agile Bridge Building, which mocks Agile Software Development by dissing bridge design in favour of showing the client Working Wood as soon as possible. Basically, you stick a log out into the river and right away you've started to build your bridge. This process naturally produces requirements, since now we have consensus that the log should actually reach all the way to the other side of the river! Why waste a lot of time in meetings trying to develop this requirement in advance? Once there's working wood, a genuine prototype, the stakeholders can quickly agree on what's important. And all without the hassles of paying someone for requirements and design. There's more, so I recommend you read the whole article. And to be honest, if I lived in the woods and was sick of wading through a small stream to get to the far side of my property, I probably would apply Agile Bridge Building to the problem, just as I don't particularly design every speck of software I write. But I'm glad the folks who built the bridges I drove over today designed them first, and I'm glad I know how to gather requirements, get consensus on functionality, and design the big projects I code before I code them.

Kate