Pekka's post about the new MS technologies got me thinking: Why are we developers so interested in our technology stack?

New technologies and tools may enable entirely new things, but more often they are just incremental enhancements that make some things easier. For instance, Dublin will provide a ready hosting environment for WF workflows, but you can already host workflows in IIS, for instance. Of course helpful tools are great, but if you focus too much on the tools available, you may lose sight of what really matters: the end user.

All too often have we heard stories of SOA projects where you first buy an expensive ESB (or some other tool) and then try to model and automate all your business processes at once using this tool - and end up with an expensive failure.

I agree with Scott Bellware: Productivity comes from design rather than tools. I see this as especially true in integration, because no two customers are similar: some have highly defined processes and perhaps a well thought-out SOA strategy, others just want to automate file transfers. No one tool can cater to all situations. You really need to understand the user's need and provide the best possible design to match it - preferably starting small, with only one or two use cases with highest ROI.

When you do this, you may often find that you don't need that many tools, and the current frameworks and development tools are quite: starting with a simple WCF web service with a well thought-out interface and message queues or databases for persistence is easy, and may very well be all that is needed. Furthermore, if you keep your overall design simple and also adhere to good design principles, like SOLID, the small solution will likely be more maintainable than if you would have built it using BizTalk or some ESB solution. This is vital especially in integration, because the whole point is to make change easy as business processes and other needs evolve.

Pekka also discusses the case where you would benefit from a tool - but only in the future: e.g. you could use BizTalk's adapters in the future, when you will likely need to push updates to SAP, but there is no need for it now. This is always a tricky situation; my take is that unless you really need the tool now, wait - you ain't gonna need it.

It's best to wait as long as possible with design decisions: your design may evolve as you create more services, the customer business processes may (and likely will) change, new backend systems will come up etc. It's true that you may not be able to justify the purchase of a tool later on, but then it just shows the tool is not valuable enough for your situation.

I agree with Pekka's closing that architecture and design is important. It is much more important than tools. Because change is inevitable, focus on the design and make it as simple and changeable as possible. You and your customer will be much happier.