Robert works in financial services and has spent many years creating and maintaining trading systems. He knows far too much about low latency data systems and garbage collection than is good for anyone. If you find yourself in a pub with him then do NOT mention phrases like "mark and sweep" or "memory profiling" as you'll be stuck there for hours and, might, be forced to break an ashtray over your own head to get away from him.
Reference Architectures
Architectural Test-Runs
Some major architectural decisions, for a reasonable sized project, will be made before the coding starts e.g. using an Enterprise Service Bus, data access methods, transaction handling etc. Your ability to achieve your non-functional requirements will depend greatly on these decisions and most will involve a trade off e.g. latency vs throughput or reliability vs performance.
Some of the trade offs will be obvious (or appear to be) but many will not e.g. how much latency does sending a request to a grid introduce? There is also the chance that your chosen technologies will not work together (maybe they refuse to work with the same database or operating system). Sometimes technologies just don't work as advertised - throughput figures are often misleading.
This is where a reference or proof of concept architecture can help. A reference architecture should contain the following:
- All the major pieces of software
- All the types of hardware
- All the hardware/software layers e.g. DB server, application server etc as separate machines (virtualisation can help)
- A simple use case that exercises all the pieces of software and hardware.
You are trying to test the major flow of the system so you can keep business logic to a minimum.
We are trying to prove that the architectural design is capable of delivering the NFRs. This doesn't guarantee that your performance won't degrade as the system is fleshed out but if it doesn't work on a simplified system, the full system has no chance.
Also take the opportunity to identify were you should capture metrics. If you fail to achieve the NFRs externally you'll want to discover where in your system you are having issues. Including metric points from the start makes this much easier.
The initial, internal metrics you gather will also serve as a useful base for comparison. As you add more business logic you will probably see your performance decrease. If you regularly collect metrics you can spot when and where this occurs.
In summary, in the same way that you should test your code early and often, you should do the same with your architecture.
Re: Reference Architectures
In a similar manner to tactical solutions, in my experience it is difficult to prevent the prototype from morphing into the production code. However, in your post you imply that that the prototype should remain and be referred to during construction. This seems a sound practice to recommend. Particularly on an iteratively developed application - keeping the prototype for extension in subsequent build cycles strikes me as very valuable.
If you invest time in a worthwhile reference architecture, how difficult is it to keep it as a reference? Do teams lose discipline and run with the prototype? Do you have to watch for copy-pasters just borrowing the (not necessarily prod quality) prototype code? I am interested in anyone's experiences of working with a reference architecture that remains distinct from the released application.
