The latest expert opinions, articles, and guides for the Java professional.

3 elements of software architecture that developers [should] dream about


Software architecture isn’t something that all developers like, but nonetheless it’s really important. Wikipedia’s explanation of the term is as follows:

Architecture (Latin architectura, from the Greek ἀρχιτέκτων – arkhitekton, from ἀρχι- “chief” and τέκτων “builder, carpenter, mason”) is both the process and product of planning, designing, and construction, usually of buildings and other physical structures. Architectural works, in the material form of buildings, are often perceived as cultural symbols and as works of art.

Interesting. Architecture is about building, designing something, and the result of that is intended to be a “work of art”. Have you ever thought of your work as art? No? Maybe you should.

As a Java developer, I think a lot about the architecture of my projects and I always try to choose an architecture that is scalable. I want the architecture of my packages to be able to scale globally with different services and actors. And all of this got me started thinking about some of the basic elements of software architecture that developers should embrace and learn more about. Mainly, we can break it down to this:

  1. You should use REST architecture to make your apps easy to write, access and update
  2. You should remember that there is no single database to rule them all–blend NoSQL and relational databases for different needs
  3. You should keep in mind that your next app’s front-end must be “anywhere-enabled”, in all formats for all devices.

Why using REST architecture makes things better

We hear a lot about the Internet of Things (IoT) these days–even Java’s Daddy James Gosling talked about this at JavaOne 2013. The idea is that every device, machine or tool you use–or even a person–could potentially have a unique ID that is interconnected to the web and anything else you like.

For me, we are facing a time when we have to think about the future and make software in the IoT-way. To do that, the role our servers play should be changed and simplified. The current, classical approach for Java EE apps is that we our web & EJB parts running on an application server (non-Java devs, deploy web and business parts to an app server). In my mind this is really old school. What if you would like to create a mobile or desktop version of the same app? Are you supposed to rewrite everything?

So in light of this, I strongly believe that our web services/business should be REST oriented. Why? Easy to write, easy to access and easy to update. Some may think “REST isn’t secure enough”, but they are being foolish–you can implement a simple security system where accessing services uses a token that is checked in order to ensure it is valid and that the user can access services. Twitter does it, Parleys, LinkedIn and many more. The implementation is yours and it is a real nice solution. Not THE ONLY solution, but A solution.

Why is REST easy to write? Because writing web services require you to write a spec for what the service accepts, which codes it returns, what is the response format and so on. Once you have this, you simply have to implement it. Looking at web services you often have a response using JSON (I’ll explain later why that’s useful).

Why is REST easy to access? Because it is a basic HTTP request, and HTTP requests can be made from mobile apps, desktop apps, web apps and any other type of app you like. Easy!

Why easy to update? If your spec changes, you can create a service with new parameters, deprecate the other and you’re done. Or change the implementation of the web service; the end user won’t be affected because they don’t know the implementation. This is the service-oriented way.

Managing all that data with NoSQL and relational databases

Data Warehouse. Two words that everybody knows. Every single application, not matter how big or small, has to deal with data storage for app preferences/settings, business data, geo-localization data, and so on. Look at companies like Twitter or LinkedIn. Can you imagine the huge amount of data they have to manage? How to store all of this?

My thoughts are NoSQL–although I think that relational databases are great for some needs–as it brings solutions to specific needs. I strongly believe in polyglotism and think that we should all explore the possibility to mix multiple technologies. Why only have relational databases? Why only have an NoSQL datastore? If each one has it benefits, take them and mix them for your needs.

We can compare this to software development in general, where you have developers and product owners. Each role has a skill set, and you mix them together to get an awesome  product. We could think about data storage in the same way.

This brings me back to JSON. Personally, I like using mongoDB and Couchbase as document-oriented datastores, with data stored in the JSON format. This is a real nice thing because your REST responses could be the response of your datastore. As well as the request.

For example, if a client makes a request of this form for searching articles:

	“query” : {
		“keywords” : [ “RebelLabs”, “Thierry Wasylczenko”, “Geek” ]

The server can interpret it and return a response of this form:

	“articles” : [
			“title” : “I love RebelLabs”,
			“author” : “Thierry WASYLCZENKO”,
			“link” : “”
			“title” : “Thierry WASYLCZENKO : brand new author”,
			“author” : “Oliver White”,
			“link” : “”

So you if your datastore stores data in JSON, the interaction between the client and the server could be easier than converting the result to JSON format if it comes from a relational database. So this could be a nice advantage.

Your front-end needs to be everywhere

Look around you: we often have a web app, mobile app and desktop app for a single service, like Dropbox, Evernote or Google Drive. The times where you have a single app version siloed away from another version are over.

In response to users demanding to access their data and apps everywhere, we saw the massive uptake of mobile apps. The evolution of more powerful smartphones cannot be ignored either–you need a mobile app for your product.Think about it yourself: would you really want to find yourself in that extreme situation where you have to access a document on a train to answer an email from your boss, because if you don’t, you’ll be fired!

I strongly believe in desktop apps, and as I’ve written about before, in the Java world we have JavaFX for making this happen. This doesn’t mean that I am not aware of all those trendy web technologies like HTML5 and so on, and those are great.

But IMHO, desktop apps aren’t dead at all–just look at how Apple does a great job merging the development platform for iOS (mobile devices) and OSX (desktops). We must maintain fusion between mobile and desktop application, and it’s just as important to consider the development of desktop app for your product. Again, look at Dropbox. I can’t imagine not having a desktop app for transferring my files. It is the same approach for Evernote or Google Drive. I agree these are a certain kind of services but they aren’t exceptions in my mind.

Keep dreaming up new architectures (Inception style)

When I dream about software architecture, it is based on polyglotism with NoSQL and JSON for the data storage, a secure REST API to access my data and having multiple front-ends available for the same app. The appropriate software architecture is the cornerstone of a good product, and it’s intriguing to consider the effects of how different architectures influence the way your app behaves and grows. Enjoy the dream!

You can get in touch with me in the comments section below, or on Twitter @twasyl or @ZeroTurnaround.

Responses (2)

  1. Avatar  


    January 29, 2014 @ 11:21 am

    Hey guy, let’s talk about WOA, which is the next step of your post ;)

  2. Avatar  


    February 15, 2014 @ 9:15 pm

    Nice article. You guys need to proof read before publishing. Hard to read with lot of grammatical errors.

RSS feed for comments on this post.

Leave a comment