I’ve been wrestling with an issue at work and thought I’d publish some results.  I’ve run this by a few peers, and needless to say am exercising the great irresponsilbe freedom afforded by having one’s own blog, I’m publishing the work to the wider world before my peers tell me I’m an idiot.

I was recently asked by a client to revisit the assumption we had made to build a framework from scratch, and to determine whether this was in fact the best course.  The counter proposal was to develop services independently, make/buy a set of libraries used by services to satisfy cross cutting concerns, and if a framework is truly needed, buy BizTalk or Tibco or something similar.  The argument centered on the cost of developing the framework and the benefit that framework could provide in reducing service development costs.

I wrestled with this for a while, doing various costing spreadsheets, but I kept thinking about the fact that for a company selling frameworks, this works for them and their clients – for enterprises creating their own framework, it often turns into a disaster (yes, for many reasons, but the value proposition is usually the main culprit)

I did a lot of research, and found much stuff, but no central governing principle – but I think I stumbled over one (perhaps I just rediscovered it) – without further ado, here’s how I think you can turn the decision as to whether to build or buy a framework into a more classical make/buy decision.

1 - For any SOA, you can define an average cost to develop services – it matters little whether this is the initial development cost or the entire SDLC cost, the bottom line is that you can average together all your services and say that in general, a Service (S) costs (D) dollars to develop over some interval of its lifetime

2 – The cost of developing a framework can be expressed as a percentage of the cost of developing the average service.  In buy scenarios, this is usually fractional, e.g. an average service costs the organization $10K to develop, Biztalk costs $6K, therefore the cost multiple for buying BizTalk is 60%.  Conversely, in build scenarios you could argue that the framework costs 5 times (500%) of what a service costs (where that cost is estimated without benefit of having the framework), and you can say that in general, the value of the framework is that it reduces your development costs 50% (wild numbers, I know, but it makes the math easier).  In this example, you would need to create 10 services in order to recover the cost of developing the framework.

The real meat of the argument always boils down to the same thing - how much does it cost to develop the framework, what’s the efficiency benefit of having the framework, how do we make sure this is the appropriate investment -  it seems to me, after a lot of thought, that this is in fact a mechanical exercise AFTER you’ve decided a few key points

               1 -  What is the average amount you would expect to spend developing a service given you had no framework ?

               2 -  How much will your framework cost, relative to the cost of the average service in #1

               3 -  What level of efficiency do you expect your framework to give you in terms of service development cost reductions

In discussing this, the most ardent foes of a framework will usually still grant it reduces development costs by 5-10% - the most ardent supporters will not usually move beyond it reducing costs more than 30-40% - the foes will say it costs 6-10x to develop the framework as opposed to the cost of developing the average service – the friends will say 4-8x

The justification for creating any framework is that it makes overall development cheaper than development without a framework (duh) – However, this is just a variant of a make/buy problem, which means you should be able to calculate the breakeven point, i.e. the number of services you would need to develop based on the framework in order to recover the costs of the framework.  Loaded development costs, the period of the SDLC covered, etc, are all red herrings – the real deal is just how much does it cost relative to unoptimized service development and how efficient does it make you – that tells you how many services you need to develop in order to recover your costs.