Skip to content

Is Java “architecture” irrelevant?

Simon Mittag says that Java Architecture is becoming irrelevant.

I am now a contractor for a large government organisation and as part of my role there, I get to participate in these workshops. Trust me, a fruitless exercise. People bickering about their favourite frameworks, why to use Axis over Spring-WS, why everyone should use maven style dependency management, maven is the devil, etc, etc.

Well, this has been a problem in Java circles for a long time now. I think we are learning to live with it. But what I don’t clearly see is its full relevance to Java “architecture”.

In my view, architecture is an independent set of constraints on the selection of the requisite frameworks; but the selection of the frameworks isn’t itself  an archiecture, nor necessarily an architectural task. In my view, achitecture is the view that says, “this is a web service” or maybe in more detail: “these are five components ‘C’ {Ca, Cb, Cc, Cd, Ce} having responsibilities ‘R’ {Ra, Rb, Rc, Rd, Rd} and they communicate via an asynchronous messaging bus in message formats ‘M’ {M1, M2, M3}”. The actual selection of the frameworks to accomplish this just should not be charged to a committee – ideally the developers should do it, with appropriate guidance from the relevant architect (who should be on the development team anyway).

Of course this proliferation of frameworks and standards to get this stuff done can lead such committees up the proverbial garden path. But, and without being privy to the full scope of the particular organisation Simon refers to, the essential problem I see here is the function of the committee – it’s just compounded by the additional issue of choice, and for some, those choices have inevitably become religious, making the said committee even more dysfunctional. Some would argue the proliferation of frameworks is something that makes Java stronger. There’s a marketplace in frameworks. But we all know about design by committee, don’t we?

That said, a lot ‘standards’ (even the JSR standards) are indeed irrelevant and out of date, as I pointed out only a few days ago.

In closing his blog entry, Simon leaves us with a question:

In closing, do you think JEE can be saved from becoming the next dinosaur?

Well, that, of course, is the million dollar question for a Java programmer isn’t it? Myself, I just prefer to get down and dirty and into the writing of the code – the business objects – that encapsulate the domain at hand. If we can’t just naturally select an uncontroversial framework to enable some segment of the desired infrastructure, then the best thing I find is to use your process, or more appropriately, your design, to just route around the controversy. But the best position is just not to be in that position anyway. Unless the chosen framework absolutely prevents you from doing something you absolutely need to do, you’re not quite in a pile of stinking do-do just yet.

And if your architecture committee is bogged down in arguing about framework selection, then I’ll tell you your real problem is is your committee, not the frameworks.


  1. Simon Mittag wrote:

    Hi Scott,

    I take your point about architecture not necessarily being framework choice. As I’ve already posted, I think being less prescriptive is actually doing more for you.

    What I meant by irrelevant Java architecture in the title is the internal state of the whole Java EE stack, both JSR and Open Source, i.e. how many MVC frameworks and XML standards does the world need?

    In a simpler environment, the developer would be free from such choice, which in most cases should be a good thing actually.

    I guess the main part I am a bit hung up with is that with problems come solutions, come generalization and standards to make things easier (or OSS alternatives). However all that happens is that these standards are being added to a huge existing pile. Nobody ever takes anything out (difficult with OSS), so while we attempt to make things easier we actually make them more difficult to understand and they begin to disagree with each other.

    This may be just the natural effects of aging though? I’m not sure.



    Friday, January 30, 2009 at 16:52 | Permalink
  2. Scot Mcphee wrote:


    Most certainly the Java EE stack is full of bloat. However I think the number of competing open source solutions to be a blessing, not a curse. I think it’s nearly always possible to find a suitable implementation fairly quickly for any given task, and the choice actually facilitates that.

    However I do share the concern that Java EE is becoming too cumbersome and tied up in ‘standardisation’ and it’s not really helping Java in the marketplace.

    Additionally I would say that many of the new language features mooted in version 7, combined with the half-baked features from version 5, are also doing real and vital damage to the language. (Annotated, generic-using autoboxed code looks more unreadable by the day). However, that is probably a discussion left for another day.

    Friday, January 30, 2009 at 17:08 | Permalink
  3. Scot Mcphee wrote:

    Also the vendors certainly aren’t helping with their super-bloato-products promising all sorts of nirvana if you’ll only swallow their $100,000 graphically-programmed kool-aid.

    Friday, January 30, 2009 at 17:10 | Permalink
  4. john smith wrote:

    Just because JEE has tons of APIs doesn’t force you to use them all. We build applications with Tomcat, Struts 1, OJB and Spring and little else. Our applications can be built fast and work. We don’t have training issues. We get the job done.

    I agree that if Sun keeps making language changes, it will harm the language. Young developers feel that if things don’t keep changing, it’s not good. Experienced developers realize that these changes aren’t necessary and saving a few characters typing in code is so minor in the whole application development process that it’s not worth it.

    Friday, January 30, 2009 at 22:50 | Permalink