You are currently browsing the monthly archive for December 2009.


Ever since project management was introduced to IT field, our lives as software development professionals have been scheduled around Projects. We literately are living with Projects. After we are done with one project, the next one comes. Or even better, the next one comes before the previous one finishes. If we are not doing a project, we must be busy planning for the next project. While we are so buried in the coming and going projects, it’s a good chance that we have missed the whole picture.


So, what’s a Project any way?

The official definition by Project Management Institution: A project is a temporary endeavor undertaken to create a unique product, service or result.

A project has the following characteristics:

  • Temporary
  • Have definite beginning and end
  • Create unique product or service
  • Have objective that indicate completion
  • Progressive Elaboration

By nature, a project is a temporary endeavor. Ultimately, it’s just the “means” not the goal. It takes us from one place to another. But, it’s the journey, not the destiny.


What’s the destiny, then? What’s the core? What’s the not-so-temporary thing in our work?

That’s the Product or more specifically, the Software Application, in software/IT industry.

A Product Development Team is responsible to create and continuously improve a software application that serves some meaningful business purposes.

A product/software application has its own life cycle:

  • Initial creation: from non-exist to the first Production release
  • Continuous improvements: as long as a product has users, it requires continuously maintenance (bug fixes) and improvements (new features)
  • Termination: just as anything concrete, a product may die, meaning users cease to use it. It maybe because the company goes out of business or simply because it’s replaced with another better Product.

The Projects happen in between a Product’s life cycle. We may have projects to initially design the database and the architecture. There maybe other maintenance projects to adding new features or doing refactory for the existing architecture. A formal termination/transition project may exist just to transfer the data out the phrasing out application to the new application.

Next time, when we think of the projects we are doing now, we can also think about the Product behinds it and where in the lifecycle of that Production this project fits in. That will help us better understand the goals of the current project.


Matter of fact, when we think deeper, handing out the application to the users is hardly the only thing we do. We also spend a lot of our time doing the following:

  • Deploy, Configure and Host the application
  • Technical Support
  • Document/Training
  • Manage the capacity
  • Manage the availability
  • Manage the service level
  • Manage the security
  • Manage the business continuity (disaster recovery)

In short, we provide a full spectrum of IT services to our users. And users actually evaluate us by all the services we provide not just by the Product (software application) we deliver.

So, it’s time to think what kind of Services we would like to provide to our business users. Then determine what kind of Products we need to deliver. Eventually, we will get to the Projects we need to accomplish to deliver the Product and/or the Service.

After all, it’s the IT Services we delivered that matters to our users, not the projects we are working on. Projects are just the tool we use to organize our work in order to provide better Services.

Jumping out of the boxes of the Projects, we will eventually find a wild wide world of Services, waiting for us to explore!


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.

December 2009
« Nov   Jan »

Blog Stats

  • 60,349 hits