Learn Software Development » Engineering

Software Design: What is meant by three tier architecture?

ashish — Tue, 21 Feb 2012 15:13:18 +0000

Three-tier architecture has been making waves for some time now ! But a lot of the people who talk about it are not aware of the details of this architecture. This article is going to try and explain this new beast called three-tier architecture. To understand the three tier system we first need to understand a more and earlier term i.e., client- server model. No doubt it is a type of computing model, and it plays the role of the distributed application among the clients and the servers. The basic role of the client server model, apart from providing a link between the client and server, is to divide the workload that exists among the servers (the computers the network that are responsible for providing resource and services to the clients) and the clients (one who initiates request from the server for resources and services and which interact with end users whereas the servers are never exposed to users).
The communication that exists between the clients and servers has been possible only because of the computer network. It is implemented on different hardware for both the client and server side. Even though the client and server might reside in different physical regions of the world, they are said to be in the same networking system. The server runs the server programs and is responsible for making available the services and resources that are requested by the clients. Because of this, a server is often called a host. There is only one way transfer of data from the server side. There is no file sharing from the client side. The client is responsible only for initiating the request. In such an architecture, the server should have a high capacity for handling multiple users at a time with heavy processing requests.
The relation between a server and a client is defined by the characteristics of that particular client server model. There are many web applications that implement the client server model in their architecture like:
1. Web access applications
2. Data base access applications and
3. Email
The client server model has been possible because of the presence of a strong network. It is not only software applications, but even many protocols also make use of the client server model like:
1. Telnet
2. DNS
3. SMTP
4. HTTP
Now let us get some details on the three-tier architecture. It consists of three layers and these layers are also called tiers.
1. 1st tier: Client front end: This end is responsible for generating the requests for the resources and the services.
2. 2nd tier: Business logic: Business logic is nothing but the protocols implemented during the processing of the requests. They can be implemented on both the client side as well as the server side. When it is implemented in server the server is called fat server. Similarly when it is implemented on the client side it is called fat client.
3. 3rd tier: Data base back end: This end is responsible for holding the data and responding back to the client side i.e., providing the service requested for.
Nowadays most web applications are using this three-tier architecture. The communication between the server and the client is established through the application programming interface or API. In a three-tier architecture, separate servers are used for the application and the data base. The middle tier is placed between the client and the server so as to control the excess burden on the server. Therefore it forms an intermediate junction between the client and the server and controls the incoming requests and the processed out going requests. Three-tier architecture is a means to enforce the separation between the 2 layers. Three-tier architecture has proved to be a cutting edge in networking technology as it has made the communication faster and more reliable, enabling the building of better and stronger web applications, capable of handling huge requests.

Computer Architecture, Fifth Edition	Computer Organization and Design	Digital Design and Computer Architecture

How does the Scrum team decrease the difference between Capacity and Velocity (contd..) ?

ashish — Mon, 20 Dec 2010 19:08:30 +0000

I have been writing a series of posts that talk about how to improve the Velocity of a Scrum team, through getting rid of various items that can reduce the Velocity of the team, as well as steps that can improve the efficiency of the team (How to improve the Velocity of the scrum team). In this post, I talk about some of the dependencies that can cause problems in the efficiency of a team, along with examples of how the efficiency gets reduced.
We were working on a product which used some components provided by an external third party, and these were integral components. We could not avoid using these components since they provided us a functionality that was required for our product to work, and we did not have the time or the budget to produce these components ourselves (and it would not have made sense since we did not want to get into the business of assigning resources and supporting the functionality that this component provides).
However, we did know that we had a dependency and which could have some impact on our product schedules. We planned for tasks that entailed incorporating the component, dedicated the required amount of time and effort to integrate and fix any integration related bugs, and so on. Further, we had some team members who had experience in this area, and asked them to work through the required estimates for these tasks.
So, we were all set, and believed that integration this component would be a breeze. However, when we integrated this component, there seemed to be a problem. We usually would get a few bugs that were related to integration and some impact on our product, but in this case, there seemed to be a major problem. The integration resulted in a product that was far more shaky, and as a result, we had a lot more bugs suddenly found that seemed to be much more than what was normal. The tasks related to integration of the component took far more time, since there needed to be a large amount of time being spent on investigation and coordination with the vendor, and of course, the resultant bugs that were far more numerous.
It took us 2 more people dedicated to an extra week just to do another integration of the component after the bug fixes, and this had an incredible effect, since with a 6 member team, a large amount of work that was planned for that Sprint did not get completed, and this led to an unhappy Product Owner and senior management. The only solace for us was, that due to this impact, we were able to generate sufficient pressure to force the vendor to adopt a more thorough QE cycle; but for us, the amount of Story Points completed in this cycle were far less than what we had expected; this also set the ground for a far more interesting and detailed retrospective.

Problems with a Scrum process in terms of being able to solve dependencies on other teams

ashish — Fri, 02 Apr 2010 17:37:50 +0000

A scrum based method of development enumerates that a team works on features on the basis of Sprint cycles, and takes up feature definition close to the actual time period of the Sprint. What this means is that for a typical team that used to work on a Waterfall model whereby the features to be done in the entire cycle were decided in the beginning of the cycle, working on a Scrum cycle is a distinct change whereby the features that can be done by in the entire period of development cannot be defined at the start of the period. What this means is that if the team is working on a total time period of their version development (say for version 7.0) running from Jan to October 2010, and they have decided that their Sprint cycles are one month each, then in Jan 2010, it is difficult to define the total list of features in January 2010.
One practical example is when teams are dependent on each for their features. Consider the case which happened to our team, whereby we were working on a cycle that ended near November 2010. For some of our features that we were implementing starting approximately in March 2010, we needed the other team to deliver a core piece of technology just before we started the feature work (so our target was to receive the technology from the other team by end of Feb 2010); and such inter-dependencies between teams is fairly common in large software companies.
In the normal case, what would happen is that before we started our development work around December 2009, we would have contacted the other team and got a commitment from the team about their being able to provide this technology to us by end of Feb 2009. However, around sometime late last year, the team moved to using Scrum as a development methodology, and so when we went to them with the request for giving a commitment of support in December 2009, we were told that under their Scrum model, they would not be working on this feature till near the end of Jan 2010, and it is only then that they would start to get into feature definition, estimation, as well as final prioritization of the list of features. This caused a large number of problems to us since we were not able to commit to our features because of the dependency not being confirmed.
Such an approach causes problems in the case of companies where feature teams interact with each other for inter-dependencies (fairly common with different teams developing their core components which can then be used by other teams – this is an efficient system of dependencies). To solve this, teams will need to make some changes to their implementation of Scrum, whereby for teams that depend on them, they will have to do some initial level of working out their feature lists right at the beginning, and then provide the required level of commitment.

Advantages of using Scrum (contd..)

ashish — Thu, 29 Oct 2009 10:02:27 +0000

A couple of posts back, I had mentioned about some of the advantage of using Scrum as a project execution methodology, and this post is a continuation of that description.
- You get a person to play the role of one who ensures that the team is following the processes as they are supposed to be done, and this person is the ‘Scrum Master’. The Scrum Master is the one who looks at the processes being followed, and ensuring that people are following the rules of Scrum. The biggest problem with the enforcement of any development process is that people start deviating from that when they are under pressure. A Scrum Master watches over the entire process, and ensures that people are following the rules and practices.
- Since one of the expectations from a Scrum cycle is that the software should be working at the end of the cycle, there are improvements in the quality of the deliverables
- Typical feedback from teams that are implementing Scrum (after the first couple of Sprints, when the team has settled down and ironed out some of the kinks from the system) is that Scrum increases the predictability of work, reduces the times when they are working in an all-out deadline induced panic reaction
- You would be surprised as to how much a short 15-20 minute daily meeting can help in avoiding those long 1-2 hour meetings where the entire team would sit and discuss a feature threadbare, including those features which you would not end up implementing.
- A meeting with Dev and QE in the normal processes can be tense since people try to cover their own asses first; however, when you put them together in a Scrum kind of meeting on a regular basis, they can get far more involved in the feature and less about covering for themselves
- As you get more face to face communication in a short daily meeting, the formality that comes through an email response (where there may be many more people in the meeting) reduces to a large degree, and the discussion can happen onto more relevant points
- In Scrum meetings, dev and QE from other features get an idea as to what is going on in other features (use stories), and so they are able to quickly jump in if there is an emergent need
- How many times have you seen that the team is working on a feature, and they go to their manager for a decision, and that is to be expected, since in the normal development cycle, the team really does not have much empowerment. However, in a Scrum type model, the team can quickly take decisions and then inform people once this has happened
- The project manager and leads spend less time on preparing stuff such as status reports (and collecting information for a status report is an activity by itself). You can spend time in more useful areas.

As in the first part, the benefits that I can outline will spill over into a 3rd post.

Learning about scrum through a video

ashish — Tue, 27 Oct 2009 13:52:02 +0000

Scrum is a project management technique, one of the Agile development technologies. It is a fairly more recent technology, and has been increasingly adopted by more companies. There is a concept that scrum is meant for smaller teams, but it is erroneously thought that larger products cannot be built with scrum. For a scrum team, the size needs to be optimal (and I have found that 8-10 members are optimal for such teams in my experience), and so a larger product team can be broken down into smaller scrum teams. However, scrum seems so different from waterfall (even though waterfall is a development methodology) that people who are using Scrum really should have proper training. You need to learn about the different terms such as backlog, Sprint, burn-down charts, daily scrums, and learn the meaning of what a scrum master, what a Sprint team does, and how the teams integrate to form a much closer team.

SCRUM in Under 10 Minutes (HD)