Architecture & Technology

Software architecture is technology agnostic. For example, if you say your architecture uses message communication, it really doesn't matter if the technology mapping would be a SoniqMQ JMS or Microsoft's .NET with MSMQ or a C++ API to Tibco Rendezvous.

Fine, end of post! .... But wait. (please excuse me while I murder Shakespeare)...

To (technology) map or not to map. That is the question. Whether 'tis nobler in the mind to suffer the slings and arrows of outrageous fortune...to map, to map perchance to mis-map -ay there's the rub.

Indeed, all is well-until you make a technology choice that is misaligned with the architecture direction you took results in viscosity that makes it hard for the developers to do the right thing--the end result of that would be either you have the developers sweating to make things work or they will just cut corners and circumvent the architecture.

For example, I was working on a system where we decided on an SOA. We were trying to evaluate different options for a service bus when management decided we should use an existing asset--which happened to be a distributed-objects framework. We tried to explain that there's a technology mismatch, but it wasn't until four iterations later (4 months) of suffering from the ill-effects of this choice that we managed to demonstrate that new requirements for survivability and availability of the system were extremely complicated and costly to implement using that technology. Finally we were allowed to replace it.

My advice is that once you decide on an architectural direction--take a look at your technology options and vice versa; that is, take a look back at the architecture and evaluate what are the implications of your choices.

Posted by Arnon Rotem-Gal-Oz at 08:51 AM  Permalink