Web 3.0 ?

Many of are still grappling with Web 2.0 and most of the traditional companies are still in Web 1.0. But this post published on Tech Crunch is already making headway into Web 3.0.

We need to stop walking fast and need to run to catch up with this new way of life.

Can software component creation be industrialized ?

One of the best examples of industrialization in this century includes car manufacturing, and invention of assembly lines.  Each parts of the car gets  manufactured somewhere else and finally gets assembled at one place. The parts are made with such a perfection that even robots can put together various parts in no time.  You might be wondering, yeah I know this and everybody knows this fact, how is this related to this software architecture blog ?   Okay, here is what I wanted to ask, can the software be developed in a similar manner as a car gets manufactured ?  i.e. various components can be designed and developed at various places, and shipped to one location. Some automated tools can in turn assemble these components to build an application. Finally a final test can be done by the QA team before releasing the product.  I believe it is difficult to implement this idea in a software industry keeping our current understanding and knowledge in mind, however it is not impossible.  Here is an article that provides more insight into the topic I am discussing.

Loosely coupled, reusable and Replaceable components

I am sure as software developers we know the importance of designing and developing reusable and loosely coupled components. Recently in the XP discussion forum I came across a discussion on the topic of "Building Agile applications using replaceable components". It drew my attention and followed the thread to understand where it was heading. Basically the author challenges the basic assumption behind "loosely coupled components". Instead of giving my version of the details, I would let his article speak about the thoughts.

Here are couple of links from the author(Raju's) webpage explaining loosely coupled, replaceable components.

Hierarchy of swappable modules

Loose coupling and SOA

How to build an application using replaceable components

Also this article challenges the assumption that Java could be used to build loosely coupled, replaceable components.

Steps to remember during tradeoff analysis

It is important for all software architects to be aware of conducting the tradeoff analysis on the "Non Functional Requirements" (NFRs). It is better to have a handy tradeoff guide available during the design phase.
The tradeoff guide could be built either based on one's own experience or by taking help from other architects/resources. It would be good, if the guide covers most of the architecture principles and the non functional requirements (also called -ilities)

I would recommend following steps while doing tradeoff analysis

• Understand the customer's requirement and convert it into SMART objective
• Prioritize the requirements (NFRs) by having continuous collaboration with the customer
  
• Finally, using the tradeoff analysis guide, recommend the final design and educate the customer about the impact of the design on the priorities.
  

Open Source is not free

All of us know that the Open source softwares(OSS) are available free of cost to download, modify, distribute and even sell this to our customers and make money.

Many companies wants to use OSS in their product development/projects thinking that they could save money by choosing OSS. In reality, choosing the right OSS helps companies in saving money, and at the same time the wrong ones would incur cost to them.

Check this article out to know why OSS is not free !!

Premature Optimization and the evil

Right from the day I have started designing applications, I have been hearing people quoting the famous words,specifically dealing with "performance".

Premature optimization is root of all evil - Sir Tony Hoare (popularized by Donald Knuth)

As we aware, the words like "Premature", "Optimization" and "evil" these are generic terms and open for interpretations with no SMART objective associated with them. Developer to PM to architects, each interprets the above quote in their own way and, sometimes using it to their own advantage as and when needed.

let me share my perspective of the above quote. "Premature optimization" has two important hidden pointers. First one, the "time/period" i.e. how much "premature" is acceptable. The second pointer is "quantity" i.e. how much "optimization" is necessary.

Let me start with the second pointer "Optimization". Optimization of any application could be done at various stages. During the design stage, implementation and pre release. So, what stage is ideal to do performance optimization ? Or, should it be done continuously ?

My experience shows that following steps are needed during performance optimization

• performance criteria needs to be well understood at the beginning of the project,
  
• it should be explained to all team members(means testers included)
• Good design and coding guidelines(ex: proper use of String Vs StringBuffer, use of sets, hashmaps, etc) around performance needs to be created and taught to the development team
  
• Each component/module needs to be designed to satisfy the ground rule created at the beginning around performance, and excess tuning needs to be avoided.
  
• Check points at regular intervals should be created and performance testing should be done
  

Summary of my understanding around premature optimization quote is,

• Optimizing design,code is a continuous process happening throughout the development cycle.
  
• excess application optimization at the beginning of the project should be avoided

My thoughts mentioned above are also reflected pretty much in this artice, and the author has gone in depth and has given a good explanation around premature optimization.

Patterns to improve performance in J2EE Applications

Precisejava provides a list of patterns that would improve performance in J2EE applications. The author explains each of the patterns with good examples and reason behind improved performance.

Amazon web services goes down

It is unbelievable but true ! Amazon Web Services suffered a major outage this morning, affecting the thousands of Websites that rely on its storage (S3) and cloud computing (EC2) services. Here is the whole story

When I first got introduced to S3 and saw the demo of the concept with the high availability architecture behind S3, I felt this is the thing of the future. Now, I am thinking, we still have a long way to go while building highly scalable and available applications.

101 design pattern tips

This site has a consolidated list of 101 design patterns. The author has put a lot of effort in organizing the patterns into different groups (GOF + others). Upon clicking on each of the patterns, it provides the motivation, mechanics with an example.

Encapsulation need not be informaton hiding

Encapsulation and information hiding are the most mis-used word while describing a component based architecture. Encapsulation refers to the bundling of data with the methods that operate on that data. Often that definition is misconstrued to mean that the data is somehow hidden. In Java, one could have encapsulated data that is not hidden at all.

More information about why Encapsulation is not information hiding is explained here very clearly.

On a similar note, following principles go hand in hand very closely:

1. Encapsulation
2. Modular design
3. Information hiding
4. Isolation
5. Separation of concerns