Suggestion for a changed view of basic application architecture

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

But as much as I like the SOA idea, I think many, many developers are so far away from the concept in their thinking, in their applications, it will be very hard to get them hooked. Even after 8 years of MTS/COM+ the concept of an Application Server has not taken hold in the (German) developer community. An ad hoc poll among some 100 developers in a session at the recent German DevDays showed: only 5-10% knew what COM+ was, and none (!) used it in their application.

And even if I´m optimistic, I´d say, only maybe 30% of Microsoft oriented developers have a grasp of COM+. And maybe just 10% of them actually use COM+.

Given, that not all projects need COM+ or Web services or .NET Remoting, surely many more than todays would profit from those technologies. But developers don´t even give them a try.

Why? Because their view of the basic application architecture is still rooted in the 1980ies. They think, their applications are whatever they see on screen. For them the frontend is the application. (Even though, they are using objects and are building some components.)

This like locating your self right behind your eyes in your head. But that´s just one view of the world. Other times have been and other cultures are thinking differently. And it´s even changing in the western world. More holistic views are appearing. A person is not just it´s brain. There is no homunculus in your head.

But how we view the world determines how we interact with it. Thinking of our selves as sitting behind our eyes and steering a body separated from us models our whole world from interaction with other people to medicine etc.

So I think, our view of how applications should be architected does the same for our perception and use of technologies.

The current "canonical" idea of an application architecture, the dominant meme so to speak ;-), looks like this, I´d say:

Current "canonical" application architecture picture.

Frontends are on top (or on the left), the BL is in the middle ("middleware"), and on the opposite side sits the data access layer (invisible for the frontends). This sounds plausible, looks ok, and is not even wrong. (As it is not wrong to locate at least major parts of our self within our heads.)

But this view of a basic application architecture still suggests, it´s good to start with frontends. Frontends are important. Frontends are hosts for BL. etc.

But this is only a limited view. It causes the 1980ies thinking to continue. Application servers don´t seem necessary. Hey, why use COM+ oder even a .NET Remoting console application when I can host the BL in my frontend. And if I can do that, why rigorously think about a service facade in front of my BL. Plus: What is BL anyway?

My opinion is: Unless we change the basic picture of how applications should look, the majority of developers will not change their thinking. They will not adapt (quickly enough) to Web services or any other kind of services. And that will make life more difficult for them in the future.

Thus I propose to aggressively promote a modified picture of an basic application architecture:

Suggested "canonical" application architecture picture.

It contains the same players, the same terminology, but moved around the boxes. Seems a small change, but I think it´s an important one.

The Businesslogic now sits in the middle and on top! And I replaced the somewhat fuzzy term "Businesslogic" with "Application". The BL is (!) the application. It´s the heart of what a programm is supposed to do.

All other stuff is nice to have, so to speak ;-) Frontends are nice to have, but not necessary for a particular BL (or application). An application could be started by just loading it into a host (Applicaiton Server).

Resources are not necessary either. An application could just communicate with frontends and keep state in memory. (Memory is no resource worth mentioning in this picture as are databases, TCP connections, the file system. For resources a special API is needed; memory you access thru objects.)

So an application should be just this thing in the middle and on top. Nothing more, nothing less.

Most of the times, though, it is not selfsufficient. It´s no monk meditating in a cave, not eating, not drinking, not speaking. An application needs to interact with the world.

Applications most often want to access resources. And they might want to communicate with other applications.

Although an application could perfectly well just churn on data from resources and be driven by some internal rules, sometimes it´s necessary to trigger it from the outside. Or you want to take a look at its current state of processing.

Only then come frontends into play. I think they should be degraded from primary focus of development to just triggers of events in the application. Frontends trigger processing, they send events to the application and receive data about its state. Sometime this can be accomplished by a scheduled a WSH script, sometimes an elaborate GUI is necessary.

But in any case, the frontend is just an "add-on" to the application.

Only if we change the weights within the commonly promoted picture of application architectures in this way, I think we can effectively change how developers view Application Servers, (Web) services and the like.

Thanks to Christian Weyer and Markus Baulig for giving me the chance to refine my thinking about this idea in conversations with them.