Ralf's Sudelbücher

In the past days I tried to explain, what I think has to change in our application architecture message for the majority of developers now. My main point is: We need to change how we depict the parts of an application (i.e. frontend, businesslogic and backend). We don´t need to introduce new technologies/concepts, but just shift the implicit/explicit emphasize on existing ones.

Knives back in our boots I like Clemens' new post quite bit. Or even: I agree with his solutions for the scenarios depicted.

However, I know few developers who are going to build such kind of systems within the next 10 years. Or to be honest: I know none.

That doesn´t mean, I think there are none, but only makes a statement about the 5000+ developers I "touch" each year.

As useful and necessary Clemens´ solutions are, I don´t think, we can motivate those 5000+ developers to adapt them anytime soon. Plus, I still doubt they make sense for all of them. At least as long as the technology to implement them is not here and easy to use. (Always remember COM+: A good technology and sound concepts below it do not guarantee broad success and adoption of the ideas!)

This is why I still cling to the notion of in-proc resource components. Or maybe I should call them light weight services? ;-)

Anyway, I don´t see Clemens and me that far apart in our views. We´re just looking at applications of different scale. This becomes clear, when I say, that Clemens´ "data services" are treated as separate applications in my architectural picture. Just because some component delivers data, I don´t think it can only be a resource component. If it´s big enough (or independent/autonomous enough) sure it can be made into an application of its own. SQL Server for example is an application of its own - but my application should communicate with it thru a resource component wrapping an abstraction layer around its services.

Well, well, fellow German RD Clemens Vasters obviously found some time to read my blog between his job as a (probably fulltime) "architecture consultant" and writing "more code on a monthly basis than some full-time application developers"; so in his blog entry he honors me with some mentions of my recent "discoveries".

If you´ve been following my thoughts on changing our view of the application architecture (of business apps), then you might have gotten the impression, I´m very firm in my views and want everything to be governed by clear rules not to be broken.

Yesterday I drilled down into my new view on application architecture to explain, how I think frontends and application should communicate.

In my last blog entry I suggested a new view on basic application architecture (at least for "business applications"). The purpose: to change the patterns in which developers think, so concepts like Application Server no longer are deemed esoteric tools for only a few.

Web services were yesterday. Today is SOA (Service Oriented Architecture). And what´s tomorrow?
The only constant about buzzwords is change.

After 5 locations of Microsoft DevDays tour throughout Germany and my talk on building a data access layer and several conversations with colleagues and attendees, I´m now convinced of the following: