SOA versus component design

Scott Belware published a very interesting article on theserverside.net. Driven by several discussions and presentations at Microsoft’s TechEd in Orlando in June, he discusses today’s difficulties in application architecture, which is drifting between modern SOA ideas and the RAD tooling reality. I share many of his critical thoughts.
Let’s look at an example: Visual Studio .NET is a really powerful development environment with lots of powerful features, but doesn’t guide developers towards solid design decisions.
Many of the decoupling lessons learnt from the good old COM history seem to be lost in modern .NET development. Many .NET developers aren’t even aware of the possibilities and responsibilities that lie in the use of .NET assemblies as a modern component model. It was never as easy as today to create component based applications, using interfaces to decouple implementations, following best practices from Test Driven Development (TDD).
It was so much harder to create the very same effect using COM interfaces, C++ and ATL in the late 90s. The benefit was that though we had to design interfaces in IDL and express shared data types in strange type systems (beware of VARIANT and BSTR), we knew the component boundaries! These boundaries were so extremely and painfully visible, that it became one of the main reasons why Microsoft created .NET. But now that those problems are gone, nobody seems to be interested in components any more. Everybody talks about services.
I think most designers and application architects should take a step back: Design your applications using strictly separated components. Use small and distinct interfaces to establish controlled communication between these components. Define and model an application specific layered architecture that goes beyond those physical deployment tiers that can be found in many articles. The result will be an application that consists of many components which you can develop and test concurrently, understand and maintain more easily.
These applications and their components will be first class citizens in the SOA future of your enterprise, because it will be fairly easy to create coarse grained service interfaces on top of these well defined components.
What I want to say: SOA will not completely change the world of a component developer. It’s just the next evolutionary step to use well designed components in a bigger scenario. Don’t forget the lessons learnt from the days when component design was the modern art. SOA won’t change those principles – but it will change the remote access to your components.

Risks behind the SOA hype

Hi all,
I just published my first critical article about the SOA hype in the German IT magazine "Computerwoche", which can be found here - caution: it's written in German.
I thought that this event should finally be the trigger to open my own blog and share my personal thoughts on architecture, model driven development and software factories with the rest of the world. Hopefully somebody out there is interested...