Yesterday, I enjoyed a great diner (a seafood plate for three) with Maarten Sikkema and Serge van den Oever from Macaw on the beach of Scheveningen in lovely weather. It was great talking to them, sharing idea's. We ended up having a good discussion about object orientation, layering, service orientation and pragmatic approaches, which kept me thinking while driving home and a great deal of today.
One thing that came to mind was a meeting that the three of us were in with Macaw's Application Services department. The problem they faced with a lot of their applications was that if they fixed a bug in one place, something else would break somewhere else. A lot of times, this wasn't noticed, leading to unhappy customers. Their proposed solution was simple, just build every page (it was about web apps at that point) to do what it needs to do and stop building all those layers in the apps and throw away all those generic components (a bit exagarated of course).
Now, I do think that is not exactly what they meant, complex pages would require a lot of code, which is unmaintainable too, specificly if some state management or event management is involved, but I do understand their point. And before I'm flamed with comments, I know that ideally an application should be fully tested before rolled out and that if some change breaks something somewhere else there is something wrong with an application design, but this is reality and the people building and maintaining those apps are well-educated professionals. So, I think they have a good point, apps need to be simpler.
It's my believe that in a lot of cases, architects choose an architectural approach before they faced the problem. Or put differently, they know the architecture and fit the problem to it, instead of fitting the architecture to the problem. The choice they make is largely influenced by the hype of that moment. A lot of architects that start new projects these days will know they will be using Services, without even looking into the problem at hand. A year ago they would all introduce a process layer, a business layer and a data layer, even for the simplest application. And of course, the data layer needed to be generated, using some object to relational mapping tool (sounds familiar?). One of the main problems with following hypes is that architects and developers are both pretty new to subject, making them step into a lot of all possible pitfall around.
Don't get me wrong, I do think that every technology mentioned before has had a great positive effect on application architecture and development. But there is no generic architecture, there is only architectural best practices. I heard it a couple of times on the Tech-Ed, David Chappell said it for sure and I think Juwal Lowy did too. In the end, the customer wants to earn more money, and they can only do that if a solution supports a business opportunity, a business will never directly earn more money through a great architecture. I think that every solution needs another design and potentially could need another technology. That would mean that an Enterprise Architecture should support a large deal of flexibility. Standardizing on application technology (e.g. .NET) and application architecture (e.g. 3-tier) does not fit in that vision, instead it would complicate that. It's here where I think Service Orientation kicks in. Service Orientation allows Enterprise Architects to set guidelines that makes sure interoperability and information exchange needs are met, without requiring Apps to choose a specific technology or architecture.
Does that mean that your next webapp needs to be fully service oriented? Depends, if it's an discussion board, most likely not, if it's an trading partner portal, you should at least consider it.
O, and I do think I'm one of those hype-following architects/developers, I'm actually anxiously waiting to do a project involving Service Orientation, but I promise I will try to practice what I preach ;-).