Cost vs Benefit – Occam’s Razor for the Enterprise Architect

Natural philosophers throughout history have struggled with myriad alternative theories for how the universe works. When your view of reality is incomplete, how can you possible make reliable choices between competing theories? Often, the answer to this dilemma was to apply what is now known as Occam’s Razor – choose the alternative which explains all the facts without adding unnecessary complexities. In many branches of science, philosophy and in every day life, Occam’s Razor has become a useful heuristic for choosing between alternatives.

The Enterprise Architect is often presented with myriad alternative choices when designing solutions for the business. Occam’s Razor is a useful tool here as well – don’t make a solution more complex than it needs to be.

In the case of Enterprise Architecture I think there is also a good argument for refining the Razor to the principal of Cost versus Benefit. When faced with different alternatives for a solution, pick the one where the benefit most outweighs the cost. And you can usually eliminate a host of alternatives by getting rid of those where the benefit is not justified by the cost.

One example that often crops up is when to expose some IT functionality as a re-usable service? I’m often asked by solution designers – “should I make this a service or not?” The simple answer is to look at the cost versus the benefit. Developing a Service always come with additional cost. There is additional design time cost to ensure that the Service will support all the anticipated requirements across multiple different business processes. There is additional runtime cost as we need to wrap the Service in platform neutral technologies such as SOAP and WSDL. There is additional administrative cost in monitoring and managing the Service at an enterprise level. This additional cost may not be justified if the functionality is only ever to be used in one business process and there is no reasonable justification for re-use in the future. In order to justify the additional cost to turn a point-to-point function/integration into a re-usable service, you need to have some understanding as to the additional lifetime cost that service-enablement entails and whether the value of that service to the enterprise (usually in the form of re-use) outweighs the additional cost.

Another example where the cost vs. benefit razor can be applied is in the realm of error handling for integration solutions. A common mistake is to over-complicate integration solutions by over-automating error handling. Quite often, the simplest solution is to manually handle errors when they occur. The main effort should be expended in providing a solution which will detect errors and flag them to administrators for manual resolution. It is only worth automating recovery for those errors when you know that the benefit of automation outweighs the cost. For example, if I have an error that occurs once a month and it takes someone 5 minutes effort to remediate the error, then it is probably not worth automating that fix. Alternatively if an error occurs five times a day and it takes someone 3 hours to fix each error, then that is crying out for an automated solution. The trick here is that you often don’t know the full cost vs benefit equation for errors until the integration solution is in place and working.

All this seems obvious, but it is surprising how often simple heuristics like cost vs benefit can be overlooked – especially when design decisions can be heavily influenced by fashion.

Don’t design a solution that is more expensive than the benefit it provides. 


1 comment so far ↓

#1 The Power of Later | soabloke on 05.06.09 at 10:59 am

[…] 2 means that we get a pissed off user. That may represent a high, medium or low cost to the organization depending on the value of that user. In addition there is the cost of indeterminate requests. What […]

Leave a Comment