I know it’s not a new article or concept but, for software architects, it is likely worth reading, re-reading, and re-reading. In the spirit of architecting an application to implement the latest buzz-words, SOA and WebServices, I have seen a number of projects that create Application Servers to try and localize business logic. More often than not you end up creating a performance nightmare (ok; it works, and quickly, in unit tests… now load test it with 10 000 records of actual data) that you end up having to reconcile with your users (often back-loaded on a project causing developers to curse the name of the architect behind closed doors). In other cases you may fall into the trap of having to create state-full services that end up causing the exact problem you were trying to solve with the Application Server, scaling out when processing becomes a burden (just try and implement your own object pool or scalable application cache. Call me when just that component of your application runs bug-free). Fowler’s "First Law of Distributed Object Oriented Design: Don’t distribute your objects" is so vitally important to creating a good architecture. Just like anti-patterns, and knowing when NOT to implement a design pattern, it is becoming increasingly important to realize that you should only implement SOA (however you are defining it within the context of your application), Web Services or any other distributed model, when it actually fits the requirements of the application.