Architecture – Understanding The Criteria – IV

Eclipse 3.3 in Ubuntu 7.

Image via Wikipedia

This is the 4th post in the series Architecture – Understanding The Criteria

Agile or Agility:

Is your architecture agile? Yes, it is, it can do sit-ups, bend-downs, push-ups and cartwheels. Is that agile enough for you? Oops, that sounds like its flexible!

What does agility really mean, in this context? Agility implies meeting today’s requirements and being ready or able to take on tomorrow’s requirements i.e. being able to respond quickly to unexpected and/or unknown change.

What are the components that make up an agile architecture?

Process and data modeling

Image via Wikipedia


Flexibility is key to being agile. The ability to plug and play components as features can be classified as being part of an agile architecture. The ability to generically interface with components and features and extend the existing functionality is being flexible.


The ability to extend the current functionality of the system either through plug and play features that cater to users who might want to use your system, in unanticipated and unforeseen ways and applications is definitely a must requirement for an agile architecture. The Eclipse platform is built on such an architecture.


The ability to not have to reinvent the wheel every time your customer comes up with new requirements and reuse existing components and/or code is at the core of reusability.


Components , whether COTS components or custom-built to specifications have to be integrable. The ability to integrate and integrate quickly, is what can give a firm its competitive edge.


Much as we would like to see the Big Bang theory at work i.e. at first there was nothing and there is this huge humongous piece of software that is the silver bullet that all software firms have been dreaming of, the truth is that the ability to break software into smaller pieces that both users and developers can wrap their intellect around makes for simpler development practices. It also allows for visibility into the progress of software development with users and customers having a chance to interact with the subset of product features developed. This also ensures continuous feedback and reduces the risk of the software being discarded as being unusable. This also makes for a reduced need for training on the system , with expert users coming from the user interaction team. In addition, for riskier projects, where new technology is being explored, this brings to the fore exploring of real options (ROV) where make or discard decisions are made at every stage of the development process. Also, EVA (Economic Value Added)  can be distributed over components and stages thus providing financial numbers to the fiscally inclined namely the project sponsors.

Three software development patterns mashed tog...

Image via Wikipedia


The ability to modify code or a system is usually confined to the implementation of the modules. The interfaces are changed less frequently (because of the high impact on testing especially integration testing) thus demanding rigor while defining them. But the modifiability of a system has a direct impact on its maintainability. This is especially important since most of IT spend i.e. 75-80% is towards maintenance of existing IT systems and just 20-25% is for new development. New development is where you create value for the enterprise.The ability of take byte-sized chunks out of maintenance costs will have the CFO kissing you rapturously, given you can demonstrate the value unlocked in cost savings. Anything that reduces TCO (Total Cost of Ownership) will get you a thumbs up from your CFO!

Decoupled or Loosely Coupled:

The ability to reduce dependencies between different components or systems is what makes for a loosely coupled system or decoupled architecture. Decoupling is achieved by parameterization and/or configuration either through files or database parameters. Definition of generic interfaces is also another way of achieving decoupling. Asynchronous systems built using message based architectures and/or a simulated messaging system using database tables is also another standard way of decoupling your system architecture. This also contributes to reliability.

That’s all for now, folks!

Have a great day!

Share this post :


2 thoughts on “Architecture – Understanding The Criteria – IV

  1. I suppose the testers are undeveloped business analysts which most developers tend not to be (considering their job responsibilities especially for huge applications where her/his focal point is unique to developing and maintenance of a module or two). This implies that the tester should utilise the near sizeable (expected) application knowledge at her/his disposal and suggest (vehemently at times) how the functionality ought to be. This is a help which needs to be recognized by all


Comments are closed.