Layers/Tiers: One More Time
<a href="http://soa-eda.blogspot.com/2008/03/about-layers-and-tiers.html">Jack Van Hoof has a different view </a>than I regarding the <a href="http://www.ddj.com/blog/architectblog/archives/2008/02/the_layered_arc.html">difference between Tiers and Layers</a>. </p>
![](https://eu-images.contentstack.com/v3/assets/blt69509c9116440be8/bltc0182b2356ae8eed/64b83949410a1b4c0bd7459b/IW_generic_image.png?width=1280&auto=webp&quality=95&format=jpg&disable=upscale)
Jack Van Hoof has a different view than I regarding the difference between Tiers and Layers.
I am not sure I agree with his view, but it still provides an interesting read. I think the main difference between our respective views is that Jack takes a look from the enterprise-architecture angle which gives him layers like:
Technical infrastructure; OS, directory Services etc.
Application infrastructure; Apps, Portals, DBMSs
Application Landscape; SOA, EDA
Bushiness Processes; BPM
Jack uses the term "tier" for layers within the same level of abstraction. For instance, he gives the following examples:
E.g. the layer of business services may be arranged in the tiers: front-office, mid-office and back-office. At the next lower layer, the application layer, services may be arranged in the tiers: UI, business logic and data persistency. The interaction of services between two tiers may be bidirectional (but may also be constrained to unidirectional).
The perspective I have (or at least try to maintain in this blog) is the solution/product line architecture -- basically living within Jack's application layers. So in my view I want to know and differentiate between the difference of having a UI and business logic live on the same machine vs. having them distributed in the world. So I guess in the end both perspectives need to have their place and the problem is (like often is the case) overloaded terms.
About the Author(s)
You May Also Like