RE: Architectural Hedges
Craig Stuntz recently posed the question of how to build hedges into our products and processes.
If I understand the problem correctly what we want is a way to mitigate the risk of choosing the wrong technology or technique. This is to say if we do choose the wrong technology or technique (for whatever reason) how do we recover and change direction with a minimal amount of fuss and cost.
I think the biggest guiding princple we have for this is Deferred Implmentation. Deferred Implementation demands implementation agnosticism from the client code. We’ll use the User Repository code from the post Keep you code lazy and ignorant as an example. When we wrote the code that needed to look up a user by the user name the client code was ignorant of how the data got there. This was good because it meant we could focus on the business logic of logging in and leave the details of how retrieve user information for later. All we needed to supply was an API for the client code to use. Later, in the next post, we wrote the code to retrieve the user data using an ADO connection to a SQL database. The truth is we could have used any storage medium like an XML file or web service. Either way the client code didn’t change because of the implementation details in the User Repository. Doing this created a hedge in both the barrier sense and the risk mitigation sense.
TDD played a big role in getting to the deferred implementation of the User Repository. We were able to quickly put together a test bed for our ideas and keep it to be sure we didn’t inadvertently break anything. TDD also gave us a formula for the incremental improvement of the code.
TDD by itself didn’t get the job done. We needed to be conscious of separation of concerns, not mixing object creation with business logic and design patterns that help us solve these sorts of problems.
I hope this addressed the question Craig posed. If not, I hope this was at least informative.
Choosing the wrong technology is one kind of risk. Changing business conditions is a different kind. Both are important.
Anyway, I appreciate your reply, and comments on my blog are fixed now.
Thanks Craig. Could you give an example of changing business conditions?
Sure. My company produces software for customers whose operations are frequently funded by government programs. Many states are required to keep balanced budgets, and when their tax revenues fall, as now, they may change the level of funding, or the requirements for getting this funding. This might mean that the software has to change to meet these new requirements, or it might mean that we get fewer customers from one state, and more customers from a different state.
Alternately, there might be a change in the business producing the software, itself. It might merge with another company, and have to integrate its own systems or its products. So another kind of architectural hedge is to plan for systems integration, since that seems to be an constant trend even without corporate mergers.
I think separation of concerns produces the biggest gain here.
Lets look at system integration first. Say your company (A) is buying my company (B) to pair my company’s data mining front end with your company’s distributed database back end. If my company has done a good job of isolating our data access layer then we “only” have write a new data access layer to interface with your company’s back end; we don’t have to change any other part of the system. This is good because it reduces the work load and because we don’t have to change that wonderful front end which is the reason your company is buying mine.
Now for changing requirements. Keeping the product as modular as is practical and isolating dependencies helps here. Lets say my data mining product is being funded by a third party who decides that they can’t spend the money on labor for a GUI. If we’ve kept the business logic out of the GUI (something for which we Delphi developers are collectively guilty) then we can easily shift gears and ship using a command line interface.
The bottom line is more monolithic our products are the harder it is to respond to change.
What about this research. I must say this topic is very interesting for writing a research paper.
Wow! Thanks for the great informative post.
I think the above article is informative for all concerned people. For me the Informations are really really useful.
Great post, you are working great on this blog, i just want to say you that just keep it up.
Lets say my data mining product is being funded by a third party who decides that they can’t spend the money on labor for a GUI. If we’ve kept the business logic out of the GUI (something for which we Delphi developers are collectively guilty) then we can easily shift gears and ship using a command line interface.
Very good post. I have been searching for this post since many days. Now I have implemented the same for my site.
It’s such a difficult question, and you deal with it so easy!
it’s amazing how some people cope easily with such a difficult problems!
cool n amaizing
very very gud post you have
I have been searching for this post since many days. Now I have implemented the same for my site
some people cope easily with such a difficult problems
we can easily shift gears and ship using a command line interface.
i just want to say you that just keep it up.
If we’ve kept the business logic out of the GUI then what should we do ??
nice blog
nice blog
If you need to get an admission in a school, college or a university or call upon any help in any kind of job, so don’t get anxious. Get ideas about your creation by using custom essay service. I don’t think that there is anything immoral in using writing services.
charm bracelets
I came accross your blog and have been reading along.
For this matter, once I discussed with one of my friends, not only about the content you talked about, but also to how to improve and develop, but no results. So I am deeply moved by what you said today.
Good article, thanks to the author to share.welcome come to
http://www.footballworldcupjerseys.com.
An amazing machine, you deserve to 1. These fantastic shoes can be a brilliant and attractive. Enjoy and of itself.