You are currently browsing the tag archive for the ‘Architecture Design’ tag.

I still remembered clearly of one of my job interviews. The interviewer was a development manager and I was applying for the position of a Software Architect. We had some random talks just to break the ice. Then, out of blue, he asked me, “So, you are an Architect. Would you please tell me what the most important features of a good software architecture are?” A millions of ideas were flying around in my mind. My answer on the spot was “Simplicity and maintainability” since I have been in charge of maintaining and continuous development of an application for years before the interview. Most of my frustrations have been the results of the initial designs not considering the future extensions of both the functions and the scalability of the system.

After the interview, I have been pondering around this question again and again and found that there is no single good answer to that question. It really depends on the circumstances.

A good architecture design should at least consider the following three groups of features:

Group 1: Functional

  • Functionality
  • Usability

Group 2: Non-Functional

  • Flexibility/Extendibility
  • Maintainability/Simplicity
  • Scalability
  • Robustness
  • Availability
  • Performance
  • Security

Group 3: Project level

  • Cost efficiency
  • Time to the market

The non-functional features are most neglected ones, especially in the inception phrase. The clients and the business users usually focus on functions and when they can get it with how much cost. Usually, they won’t think of non-functional specs like availability or scalability at the beginning.

However, neglecting those non-functional aspects of the architecture can have dire consequences after the application is deployed and up running. It usually will cost 10 times as much in maintenance to reverse the mistakes made in the initial design.

To add more complexities, some of the features are against each other, e.g.

  • Flexibility vs. Maintainability
  • Scalability vs. Performance
  • Security vs. Usability
  • Robustness vs. Flexibility

Essentially you cannot design a system that’s perfect in all aspects since one aspect’s gain may come at the cost of the other aspect.

So, a good software architect should keep all the above aspects in mind when designing a software product. He must strike a balance among those aspects to achieve the optimized result.

But, how to walk on the thin line?

Here are some tips:

  • Understand requirements: Extend beyond the functional aspects to non-functional aspects.
  • Reasonably project/predict the future: Imagine how this application will be deployed, who will use it and what the usage patterns are. How fast the product may sell in the market?
  • Build in the flexibility but not too much: If the future is hard to predict, at least give yourself some leeway to build some flexibilities to handle the uncertainty. But, don’t overdo. Architects tends to design too many abstract layers just for flexibility. Do try to suppress that urge and maintain a good sense of simplicity in the design.
  • Continuous improvement: Circumstances change all the time. Nobody can precisely predict the future. So, do revisit the design periodically based on the ever-changing reality.

I always consider software architecture design is a work of art. It requires not only technical knowledge and skills but also a sensitive mind to capture the reality and reflect that in the design. A software architect is always walking on a thin line trying to achieve the balance among competing forces. So, a well-designed piece of software product is well worth appreciation and respect, just like any master pieces we saw in a museum.

As I mentioned in my last post, software frameworks are so deeply embedded into our lives as software architects and software developers. So, when I was assigned the task to develop a web application to automate the tedious manual tasks for the technical support team, my first reaction to such an challenging business requirement is asking myself the question, “What framework should I use?”. If nothing comes up, I will say to myself, “Aha, my chance comes” and will happy to roll up my sleeves to build one.

I guess all enthusiastic programmers are alike. Otherwise, we won’t see so many open source frameworks out there in Sourceforge, Java-Source and Apache. People just like to write more and more frameworks and secretly (or openly) hope that one day the framework will be as popular as Struts or Spring.

In fact, writing frameworks can bring many substantial benefits to the project:

Read the rest of this entry »

Framework is everywhere in our every day life as a software architect or a software developer. Struts, Spring, Hibernate, Axis, jBPM, just to throw out a few popular names in a Java developer’s world.

We choose the right framework, we learn the framework, we adjust the framework to suit our needs, we suffer from the bad design of a framework, or, what the hell, we design our own framework! It invades our vocabulary, “What’s your MVC framework?”, “Do you use Spring or EJB?”, “Have you migrated from Toplink to Hibernate for your persistence layer yet?”. We think (and even dream) in frameworks cause they are so fundamental to our work, no matter we like or hate them.

But, why do we use framework at all? Can we live without any frameworks? What are the benefits and pitfalls? When should we use framework and when should avoid it?

We seldom stop and ask ourselves these hard and fundamental questions. Now, it’s the time.

Read the rest of this entry »

July 2017
« Dec    

Blog Stats

  • 59,710 hits