Non Functional requirements driving technology choice

With the slue of new technologies out of Microsoft over the past 2 years,
WCF, WWF, WPF, Silverlight, LINQ, Entity Framework, ADO.NET Data Services, MVC Framework, ASP AJAX etc... It is becoming increasingly confusing for developers to figure out what technologies to use, and how and where to apply them.

The danger facing many new projects is to fall into the trap of using a technology because it is new, rather than a good fit to the requirements of the problem at hand.

I always start with the non functional requirements before making any decision about the implementation technology.

Application architecture results from the balancing of functional and the non-functional requirements applicable to the system. Non-functional requirements (restrictions and constraints) serve the purpose of limiting the number of potential solutions that will satisfy a set of functional requirements.

Functional requirements are the behaviour that the owner of the system would like to emerge from the development process. All architectures exhibit emergent behaviour. If the emergent behaviours are not specified / managed in the form of non-functional requirements, the developers will choose them on behalf of business, leading to misalignment.

Architecture is applied at two levels:
·The application architecture addresses the software components of the actual application.
·The systems architecture addresses the physical (hardware) and logical distribution of components across the network environment.

The non-functional aspects that I usually consider when formulating architecture

Simplicity - number one non functional

Security – this requirement in my opinion is not an option, the five pillars of Authentication, Authorisation, Integrity, Confidentiality, and Non-repudiation need to be catered for in any application you design.

Performance – here I am looking at things like number of online transactions, batch runs and if applicable the throughput from a users perspective. The last one is quite important as to a user of any system with a front end, this is all that matters, this requirement often allows you to factor the system to cater for the different expectations that will be imposed in the system by its users.

Maintainability - The ease with which code can be understood and changed, the aspect of maintainability should be pervasive throughout any architecture you design, any item must be created with the eye towards maintaining it.

Integrity - Ability to detect and manage invalid data coming in to system and the imposition of complete transactions or rollbacks.

Extensibility - Ease with which new features can be added to the code, not the same as maintainability, things like composite applications work really well here.

Flexibility - Ease with which the software can be deployed in different environments.

Scalability - Ability of the system to grow with the organisation without code changes, increase in number of users, increase in number of transactions.

As you would have noticed, many of these requirements are in direct opposition of each other; in conjunction to this there is a price to pay for achieving any of them fully.

As a software architect the responsibility is on you to attempt to balance these conflicting forces and find the best alignment to fit the system specifications.
It is also your task to align technology risks with the appetite for risk of the organisation.

By evaluating the system against these non functional requirements first I find that my options of implementation technology usually get reduced into a manageable set.