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.

Mix Essentials 2008

I attended the Mix Essentials at Monte casino yesterday, a big thanks to the organizers for a great venue and for organizing Brad Abrams.

South African developers have been a bit deprived in getting to meet the legends of the business, I was fortunate to meet Juval Lowe last year at Dariel Solutions WCF Master Class, and with Brad coming out this year things are definitely looking up.

Silverlight was the focus of the event, and it looks great, and it has good tool support in the form of Blend. Would I use it? Maybe, as a developer the touchy feely artistic side of UI development has never really got me excited, but I understand that the UX is all that a user sees and it can make or break any application.

I think the success of this platform will depend on its uptake in the designer community who already has a large investment in Flash. I as a developer will not be moving my web apps to Silverlight soon, but I can see myself incorporating pieces of Silverlight into ASP AJAX sites where a bit of bling is needed.

Good news is that ASP.NET AJAX is here to stay; Silverlight for now is aimed at RIA’s (Rich Internet Applications). The contracts to build such applications usually go to advertising agencies and graphic designers, not hard core development houses.

Dev shops need to know about Silverlight, and its capabilities and can leverage it to add to the UX of their offerings, but I do not see it replacing ASP.NET AJAX for line of business applications just yet.

I followed the developer track, and really nothing earth shattering was on show, Brad demoed ASP AJAX which we have been using for years now, nice that it has been built into VS 2008, but you still need to get the toolkit for all the latest controls.

This is becoming a mature platform, there are lots of great controls, and optimizations available.
MVC framework is a great project to watch in the future I feel that it is still a bit immature as it is today, but it is a great idea. The routing engine is clever and having the ability to use URL mapping rules to handle both incoming and outgoing URL scenarios adds a lot of flexibility to application code.

It means that if we want to later change the URL structure of our application (for example: rename /Products to /Catalog), we could do so by modifying one set of mapping rules at the application level - and not require changing any code within our Controllers or View templates.

Brad hinted that versions of MVC for WPF and Win Forms are in the pipeline. Could he be alluding to the WPF Composite client project, a rebuild of CAB for WPF?

Dynamic Data was on show, this seems like the BLINQ project renamed, it currently only works with LINQ to SQL, but Entity framework will follow soon. It is fully customizable and could be a great time saver in certain projects.

Why your architecture needs to be like a VW beetle

Driving to work one morning I was behind an old VW Beetle, one of those originals form the 60’s, proudly emblazoned on the back was the bumper sticker “Old beetles never die”, of course this got me thinking, why don’t old Beetles die, most modern cars end up in a scrap heap 20 years after production, ok, in Africa we tend to squeeze a bit more life out of them, but here was an oldie, and one of many you can still see still driving around as reliable as it was 30 years ago when it rolled off the production line.

So why has the VW Beetle proved so resilient, I think it solved a definite need at the time, a cheap car that was reliable and functional, it was constructed out of simple components that were easy to manufacture, copy and maintain. Along with this its design was based on sound mechanical principles and concepts.

The Beetle by virtue of its design is easy to maintain, the owner being able to perform most basic functions without the need of a specialist mechanic.

So, how does any of this relate to software design?
I believe that the currently popular Agile processes for the design and construction of software have been very good at addressing the quality aspect of software construction, but have quite often been misinterpreted by practitioners when it comes to addressing design issues.

All other engineering disciplines place a strong focus on the design and modeling aspects of the construction process especially in the initial stages; perhaps software designers are becoming too separated from the other engineering disciplines as a reaction to the explosion in complexity within our domain of knowledge. We as developers and designers need to remember that design and upfront system decomposition will pay dividends; the tricky part is finding the right balance.

In the engineering around the Beetle each component has a clear purpose to the whole and its relationship to the other pieces is well defined via the way it connects to them via a set of common connections i.e. nuts, bolts, hydraulic fluid, oil etc. Pieces that perform similar functionality live together in a single component that can be replaced as a unit without replacing other dependent pieces in the process. The testing of the components can be done in a black box fashion.

But what has this to do with building good software architectures?
Well nothing is ever clear cut, I believe a good architecture would benefit from clear units of packaging these are akin to the big components of the Beetle like the fuel pump, oil filter; they should have a clear responsibility within the architecture and help to reduce complexity within the whole.

By providing the ability to work at these varying levels of abstraction one can really get to the essence of a problem without the need to get bogged down in the detail at every level. The detail comes later, as part of the implementation.

If internal components of these units of packaging and deployment are designed in a self-contained process centric manner (Poole) every piece can be easily exchangeable with other components that have the same interface.

In the design of software components the interface is the unit of reuse, not the object, (Lowy) a misconception many have in the object orientated world, reuse is achieved via the delegation of functionality not via reuse of code. Thus in modern software design the use of interfaces and interface driven design becomes really important, but we see the same thing in the Beetle, non VW oil filters fit and work just fine as they have the same interface as the original, even if they perform the filtering of oil in a completely different way.

The interface forms part of the common connection, the other being the use of a service bus to reduce the need for internal point to point connections. The service bus is like the oil or hydraulic fluid in the Beetle, it handles the connections between the internal components.

The use of a service bus helps to decouple the pieces from each other, messages are passed between the components in the form of asynchronous event topics in a publish/subscribe pattern, that allows every part to be decoupled from the other part and we do not need to span transactions or hold connections between the internal components that would ultimately cause a degradation in the performance of the system.

The service bus should also perform the routing of messages between the components so no components would have to be dependent on the knowledge of the location of another component.

Connections between the user interface like speedometer and oil gauge will and should be point to point as this is required for it to perform its duty within the constraints imposed upon it, the same holds true for software architectures.

The reduction of dependency on other parts should be driven as far down into the architecture as is reasonable, as this will lead one down the path of flexibility and testability.

The mechanical concepts that went into the design and construction of the Beetle allowed its designers to focus on the important things like meeting the needs of the public and all the requirements in the design brief.

They did not need to reinvent things like hydraulics again, a thing we seem to like doing in software design, we have a set of evolving patterns that are designed to solve certain problems, learn them, keep up to date with them and use them.

Vendors are providing some great off the self plumbing for our applications, security, synchronization, transactions, instrumentation, instancing are common requirements of all our projects we should not be recreating these solutions every time.

So that’s why your architecture can learn from a VW Beetle, simply defined working parts with common connections, pieces that can snap in and out.
No dependency on a particular brand of part via interfaces and a clear separation of concerns within the design as a whole.
Speed of production and predictability achieved by the application of custom plumbing, inherent maintainability build into the lowest level component along with ease of testing.

Why Metal Lemon?

Metal Lemon is a play on the classic saying when life gives you lemons make lemonade, well lemonade is useful, but power is even more useful , a lemon, a nail and a piece of copper can be used to make a battery, if you have enough you have the potential to power anything, so take lifes lemons and turn them into something potentially great.