Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

The full Java life: What does a software architect really do all day?

For the architect who engages, this work is anything but abstract

  • Print
  • Feedback

Page 2 of 5

But you can only go so far by making better tools. I had to start thinking on a bigger scale. When you start playing in this bigger world, you again need to push the boundaries. Maybe a SQL database isn't necessary. Maybe waiting for a response from that service isn't the best use of time. Maybe Java doesn't cut it anymore.

Okay, that last point is a bit contentious, but it is a question that I have asked. But simply asking these questions isn't the real job of an architect. Even designing an absolutely brilliant architecture isn't enough. You need to be able show others how to get there, step by step. An architect needs to be grounded in the real world, experiencing the problems that come from what they have designed. This takes both technical and social effort.

Matt Heusser: What technologies are you working with now?

Bruce Brouwer: Not too long ago I decided to fill out my LinkedIn profile, listing all the technologies that I actually use. During that effort, I learned that LinkedIn has a limit. I don't say that to brag, I think that is a problem. There are just too many things that you need to know to be a good developer in today's world. We need to do better at constraining the list of tools that we use to do our job.

Largely, what I use is Java and Spring. What I have been recently working on is designing the future of web application development at GFS. GFS has been developing web applications using Java EE from the time before there were frameworks like Struts or JSF. Now there are some new ideas that challenge these server-side web frameworks, like SOFEA and responsive design. Yes, we could shoe-horn these ideas into the current Struts 2 infrastructure that we have, but it is time to make a real break between the UI and the back end. This way we will be better positioned to respond to the pace of change in the web UI layer without having to make such drastic changes in the service layer.

"Now there are some new ideas that challenge server-side web frameworks, like SOFEA and responsive design. Yes, we could shoehorn these ideas into the current Struts 2 infrastructure, but it is time to make a real break between the UI and the back end."

For this new web UI, I have almost a completely new tool suite: Angular and Twitter Bootstrap, and of course jQuery. What I am pursuing is to build the entire UI from static resources. None of the UI will rely on the server generating any dynamic UI content. It needs to work in a plain Apache Web Server; no PHP, no Perl, nothing.

As for the service layer, GFS has an enormous Java legacy. And for the most part, it's actually pretty good. GFS has pursued a service-oriented architecture for years, utilizing Spring POJOs. Services are at the core of SOFEA. JSON is the data transport of choice these days, and Spring MVC makes it easy to expose these POJOs via JSON. So SOFEA is actually a really good fit for GFS.

The challenging part, though, has been that vision of making that web UI truly static. To make a good web app that is fast requires some other tools. I am using Compass for managing CSS. For JavaScript I am using the Google Closure compiler, which has the awesome feature of source maps. Throw in some other requirements of cache busting and making it easy to develop and all of a sudden you need a complete build solution for something that ends up becoming just a bunch of text files.

  • Print
  • Feedback

Resources

The full Java life: Career interviews with working Java developers on JavaWorld: