Agile Architecture

Agile Architecture


Many in software industry say agile design is a hit and run sort of development or in fact “no design”. Let us know how our software architecture evolved.

Architecture history of software engineering

Software engineering is a young discipline considering to others like Civil and Mechanical. So we have adopted best practices from the other engineering disciplines such as Waterfall model and planned design or up front design.

Just like Civil or Mechanical engineering we started our software development with gathering all the requirements, as it is for building a house or a machine. Do thorough analysis and ensure no stones are turned. Architects come into the picture with their imagination and set of rules to convert the requirements into workable system. They have standard set of diagrams which depicts how to build the system, what are the components in the system and how they interact within themselves and how the system interacts with external systems.

Planned Design

Upfront or planned design has some pre-requisite.

  1. Have to get all the requirements upfront
  2. Architect must be very skillful to understand all the scenarios and foresee impediments and design for it

If there are any mismatch in the requirements or if there are any change request in the requirement, it may involve lot of time and material where we have to start from the scratch.

Software engineering paradigm shift

When it comes to the evolution of software industry, we started with a stand-alone machine with a smaller capacity of computing, moved to client-server methods, three tier architecture, N-Tier architecture and now, an X as a service.

Storing the data; initially we did it with individual machines, then moving to servers to RAIDs and now reaching the clouds.

Organizing the data also changed from flat files to DBMS, to RDBMS and later to a structured way to optimize the memory usage. Normalization to De-normalization, and moving to storing key value pairs, which is also known as No-SQL.

Even the way a software system is used has changed from storing data to suggesting back the data also presenting the stored data in different forms, platforms and mediums.

All these are because of the revolutionary improvement in the hardware front as well as the need of higher levels of performance.

In earlier days there was limited number of competing players in any software vertical. Today, this has changed so much that, taking any kind of software will have hundreds of competing counterparts. In such a market, getting the product quicker to market becomes an inevitable thing. Not only quick to market, but also the ability to adapt to the rapidly changing user requirements becomes a key thing for the success of any software company.

Rapid changes are difficult and costlier when following waterfall method. And that is where agile methodologies come to rescue.

Evolutionary Design

In the conventional method of development, the whole design is completed and then the implementation starts. If in case, during the implementation phase there needs a core change in the design, the whole design phase has to repeat and until it is finished the implementation would have to wait. This is not effective in a time intensive or cost intensive environment. Whereas, the Evolutionary Design (a.k.a Continuous Design) will facilitate the design and implementation in parallel. By doing the design and implementation together, any volume of change in design could be accommodated. This is also supplemented by the shorter delivery times for each atomic task. Every piece that is designed and developed will be quality checked then and there. Hence there is a better set up of delivering working pieces of deliverable every iteration.

Salient features of evolutionary design:

  • Defer decisions as late as possible, which allow you to substitute with alternative which the team has learned in recent experience.
  • Architects understand the system design and work along with the engineering team to make them better understand. They could use the common terminology (metaphor) to represent the system. At any point in time, the design could be re factored and simplified (for understanding) if needed.
  • Do remember this abbreviations- YAGNI and DRY
    • YAGNI – You aren’t going to need it.
      ◦   Never over do the work. Do only that is needed for the current iteration. That means, even though you know there is some task which is coming next in the future iteration, nothing extra than what is in this iteration must be taken up. Because, you never know, when and what changes come in between today and that future task.
    • DRY – Don’t Repeat Yourself.
      ◦   No task must be repeated. The design must be fool proof in such a way that, no code, or any task is repeated even once. This will make the life simpler.

Technical Debt

In an agile environment one must agree and understand that no design is perfect. The design goes through a series of modifications. This is mainly because the design not developed for a complete product. Rather, we design for nuts and bolts of the product. Hence, we may adjust the size of nuts and bolts whenever needed. Also, it applies to other pieces of work as well. In this case we may have to re-design things continuously as the product grows.

Said that, the design needs to be changed as the product grows, this must happen continuously. Failing to which will create this thing, called “Technical Debt”.

A real life example can be a credit card. If you fail to pay back the credit, the interest will start mounting. Hence, the credit must be paid on time to avoid a “Financial Debt”.

I hope this explains how “Technical Debt” happens.

A practitioner’s toolkit

We can classify tools for three different phases:

  1. Continuous Integration
  2. Test Driven Development
  3. Automation Testing
  • Continuous Integration

◦   Continuous Integration is the process used in agile environments for making sure every checked in code is working as per requirements. For this, the whole product will be broken down into modules and dependencies between the modules will be established. On an event of check-in, respective modules will be compiled, deployed and an automation testing will be executed to see the sanity of the code. Advantage the team is, a perfect forecast of a possible bad code. And save time by timely notifications of what, where and who broke the code so that it is looked into at the right time. Precisely, it will at least help the developer to revert to a working code, than to break functionality while one is debugging the code.

◦   Widely used CI tools are as follows:

▪   CruiseControl (Java/.NET/Ruby)
▪   Hudson
▪   Jenkins
▪   Anthill Pro
▪   Bamboo
▪   Microsoft Team Foundation Server
▪   Rational Team Concert
▪   More tools here:

  • Test Driven Development

◦   Test driven development is an approach where we test-fail-fix a feature. In detail, a test case/script will be written and checked into the system which will be executed at the time of build. This will end up in a failure, and the task for the developer is to fix the failure. This way, the whole team -viz. Testers and Developers will be well appraised with the features for the product. On the down side, if the developer misunderstands the feature and writes a wrong test case, then develops a wrong feature, this will not be unearthed until a manual auditing of feature happens.

  • Automation Tests

◦   As the name says, whatever manual auditing steps are done for the verification of the correct working of features, are written into test scripts which are executed by test engines. This could be run at the time of builds or at a later point.

◦   Widely used tools for Automation Testing:

▪   Fit
▪   Fitnesse
▪   Selenium
▪   Quick Test Pro
▪   Silk Test
▪   MS Test
▪   More tools at:

2 responses to “Agile Architecture”

Leave a Reply

Your email address will not be published.