Java Architecture? One size fits all.

by Paul Browne

No matter what your system does , be it insurance , banking , online travel booking or telecoms, the chances are it does the following things:
  • Gets information from users over the web
  • Does some business processing on that information
  • Saves the information in a database.
At a conservative estimate , about 99% of Enterprise systems would fall into this category.

If so, why do you need an architect , when you can use our 'one size fits all' architecture diagram (below)?! Most non-trivial systems, regardless of the language they are written in (be it Java, .Net , or your language of choice) follow the pattern seen in this diagram.

3 Tier Enterprise Diagram viewable on this blogpost

There are 3 Pieces to the Solution:
  • Web Browser (for the user / client).
  • Web and Application Server - carry out business logic.
  • Database Back End - to store data and ensure data integrity.

Within the Application Server (the middle bit above, which as Java Architects is the bit we are interested in), there are a further 3 tiers

  • A Presentation tier (or layer), which is mainly about talking to the user (it gets and sends requests to the web browser).
  • A Service layer , which is mainly about talking to back end such as databases, legacy systems (such as mainframes) and XML-Web services that we may use.
  • A Business layer, the 'meat' of the sandwich, where the 'Value add' is in terms of business processing and validation.

For each of these layers , your priority in building them are slightly different.
  • The Presentation layer is the bit the user sees. You want it to be fast and give a good impression to the client. Underneath, use a standard framework (link: pick your framework here) and then customize the look and feel.
  • The Service layer you want to work fast and well (e.g. no data faults), but then then forget about. Unless things go wrong, no user is going to complement you on the quality of database persistence! Use standard libraries for the entire layer.
  • Unless your company is a clone or franchise, the business layer in the system is going to be completely different. Aside from the user-interface , concentrate most of your project effort here as this is the core of what system does. We've written quite a bit about how to increase the value-add of the business layer (link to O'Reilly Technical Articles)

Do you agree? Would your '1-page-use-anywhere' architecture be different?

More blogposts on Technology in Plain English.


2006-05-08 03:14:53
As an architect you hopefully have more things to do than just draw diagrams like that.

I agree that the general principle applies to all solutions that don't require any multi server scaling.

IMO the architect involves picking the actual technologies to be plugged into your model, as well as figuring out what additions to the model are needed.

Legacy system interfacing ?
Scheduled reporting ?

Also you are assuming an awful lot about the task at hand. It seems that you expect enterprisises to only want webified versions of old administrative systems.

Zhong Yang
2006-05-08 07:04:32
"about 99% of Enterprise systems" ?
What's your definition of an Enterprise System?
An enterprise usually has more than one customer facing channel, not just the web. I am sure your system can provide 99% availability, that's too low for an enterprise? How does your system provide 99.999% availability? .....I can go on and on. Your diagram can be a starting point, but I hope you will not present it to your clients.
Paul Browne
2006-05-08 07:16:13
I wrote the post in a provocative manner to get a reaction, so I'll read your comment in the same way :-)

Yes, I drew this diagram about 5 years ago , and used it (with variations) at about 7 different projects. So I got a lot of value out of my one day's work!

This solution has been proven to work for multi-server-scaling as well. You can either run the Web apps in paralell (if your problem lends itself to that approach), and /or upgrade some of the Business Agent's to EJB and use multiple servers in the mid tier. There may be more sophisticated ways of doing this, but if it is simple , and works , you would have a harder time justifying the alternatives.

This 'Upgrade the Agent to EJB' is in line with your comment about the Architect 'picking the actual technologies to be plugged into the model'. The 80-20 rule applies here - if we can make the standard 80% easy (as per the diagram), we can concentrate on the 20% that is the real value add of the project.

Yes I'm assuming a lot about the task at hand. The real purpose of this post is to remind Java Architects that our job is to give simple solutions that work.

Paul Browne
2006-05-08 07:22:31
Zhong Yang,

Every enterprise system is different, so the answers to your questions is : What does the customer want?

What if your customer says : '99% availability is ok if I can get it for $100,000. 99.9% would be nice , but I'm not going to pay $ 1 Million for it!'

Different Customer Facing channels are easy with the '1-page-architecture' - replace the web tier with the client (GUI , Web Service , Command line , scheduler , reporting system etc etc) of your choice.

Most of the business clients I have shown this too were pretty happy to have everything explained in one simple page. The technical people would normally like more detail , but usually about 1 or 2 specific areas.

Just to be provocative: If you can't explain something in one page, do you really know what you are talking about?


Zhong Yang
2006-05-08 15:46:04
I print my one page on a HP Design Jet plotter :)
I don't believe there's "one size fit all" architecture. But there are many enterprise architecture design patterns that people can reuse. I am not smart enough to put them on one page. But with a few extra pages, Martin Fowler put together something here
Martin only presented the patterns, I think what you are talking about here is to create ready to use solutions using the enterprise architecture patterns. You topic is provocative for sure.
I have my one page enterprise web architecture too. But with 2 extra layers. One is a content caching layer in front of your presentation layer. The other one is a data caching layer that sits underneath your business layer. For high volume sites, those are essential.

*To make it look like that I know what I am talking about, I probably would also copy the "Core Java EE Paterns: Patterns index page".

2006-05-12 01:38:00
How is 99% a conservative estimate?
2006-10-12 01:49:41


2006-10-12 01:53:34

Bye music lyrics
2006-10-12 01:56:10

G'night music lyrics
2006-10-12 01:56:31
Hi all!