Usually the feeling that the gods and the forces of nature habitually conspire against us is a product of confirmation bias - we forget all the times that woes come as single spies, because the times they come in battalions are so much more memorable.
It's important to be aware that this is not always the case. You are not paranoid when the bastards really are out to get you.
In particular, in many circumstances, maybe even the case of a washing machine, the underlying problem can be one of capacity - capacity problems are difficult to detect because they are intermittent at first, and then, finally, and spectacularly, catastrophic.
There are, in fact, a few cognitive biases involved in producing such things as 'Murphy's law' and 'Sod's Law'. We find things more important if they happen to us. We like to have a reason for things happening, and though the theory that the world is against us is an unlikely one, it is, at least, a theory, so we prefer it to accepting that happenstance is usually a good reason for coincidences.
We also are very poor at judging the probability of things happening. Often, what seems a very unlikely event, is, when you consider the size of the population, and the time over which it could happen, actually something that's almost certain to happen somewhere at least a few times a decade.
How can we then distinguish those events that signal a preventable catastrophe from those that are merely isolated events?
Unfortunately, the simple answer is, that we can't. The reason that our brains are so inclined to so many fallacies is because we live in an uncertain world, and a collection of heuristics that work fairly well, most of the time, is worth having, and using, even though it also leads us into such errors.
The more complicated answer is that events that are connected to one, or a small number, of related causes, that are a consequence of a mismatch between demand and capacity, have some characteristics that allows you to spot them against the camouflage of background noise.
These are that capacity related problems cause events that are:
- Intermittent.
- Apparently unrelated, but often coincident with a specific time of day, week or month.
- Progressive. Strange things happen once or twice a week, but then more often, once or twice a day
- Responsive to intervention. You may try to fix a symptom, and find they go away for a while
- More serious over time. Before the final catastrophe, you'll have one or two more serious events than usual
You'll notice that these characteristics fit a number of naturally occurring events - avalanches, earthquakes and volcanoes being examples. That's not an accident, these events are also capacity related - stresses build up over time, with minor event cascades (there are often a series of small earthquakes before a volcanic eruption, for example).
What can we do about this unpredictability?
When you see the relationship with natural events, you'll see what we actually do. Firstly, we need to anticipate where such a problem might occur, then see how serious it is (we're less concerned with volcanoes under the sea, far from any land, than volcanoes near towns, for example), and then put monitoring in place.
We need to design the monitoring carefully, to make sure that the metrics we use make sense, are connected with the likely capacity problem, and are measuring the system itself.
Then we need to measure the trends. Not just trends that are obviously leading to a catastrophe, but all trends. Then we need to correlate these trends with each other, project where they are tending towards, and find out what is causing the trends. Then we can put measures in place to reverse the trend, or, if that isn't possible, increase the capacity we have to deal with it, or, if that isn't possible, find a way to mitigate the risk of a meltdown.
Measuring trends is a more subtle matter than it might seem. It's often not the most obvious trend, in the main demand, that's the danger. Smaller, deviations at periods of quiet demand, or on the shoulders of a demand peak, are often the warnings.
The analysis required to detect such off-peak trends isn't that difficult to do from a mathematical point of view, but it does mean that you need to design your thresholds in a more sophisticated way than simply a maximum or minimum, based on a percentage of historical demand.
Sunday, 8 May 2016
Tuesday, 26 April 2016
Open Source Project Proposal: Ada Transport Level Security (TLS) module [Draft]
The Problem
The security of web-sites underpins much of the world's on-line economy. Breaches to it, and potential flaws in implementations of it, are a substantial risk to many organisations, in many countries.
There has already been a famous vulnerability found, and repaired, in the OpenSSL implementation, but there are many closed-source implementations that may still have similar, or more severe, vulnerabilities, or that may be compromised in other ways.
One of the reasons for these vulnerabilities has been the implementation of the solutions to TLS in languages such as c, which is an inherently insecure language, and a language that it is difficult to prove, verify or to correct.
The Proposal
To establish a team, or Ada and security experts, to produce a TLS solution, written in Ada for, in the first instance, servers. This solution would provide an API that could be used with, for example, Apache.
Once this solution had been tested, proved and deployed successfully, the solution would be extended to the client side, so that browsers, such as Firefox could use it.
Funding
The proposal depends on the team being paid for the work, and for enhancements also to be paid.
Long term funding would come from income. The produce would have dual-licensing. Free open source to individuals, and open source projects, such as Mozilla, but commercial licensing to organisations such as Apple.
The Requirements
The project, to be a success must comply with these requirements
- Satisfy TLS 1.2 and 1.3
- Be designed to provide general transport layer security
- Be compatible with existing TLS apis
- Ensure highly secure design
- Establish a method to verify a server is running a particular version
- Ensure code is easy to maintain
- Use Ada not just as the language, but as an example of good, secure, reliable and fast open source Ada
Provisional timeline
Funding applications: May-August 2016
Team Recruitment: September 2016
Design: September-October 2016
Coding: November-December-January 2016
Testing: February-March 2017
Beta with customers: April-May 2017
Full Release: September 2017
Next Steps
Please comment on this blog if you have any suggestions for improvements to this draft, or write to peter.brooks@service-governance.org
Wednesday, 16 March 2016
Good corporate citizenship - and 'The Myth of Maximizing Shareholder Value' - and Service Governance
Here's an important article, on governance, The Myth of Maximizing Shareholder Value - unfortunately the page doesn't allow replies, so I've put the points in this short blog entry.
Governance thinking, even in the US, is moving. When we are providing consultancy to organisations, we need to be aware of this shift, and, as discussed in 'Collaborative Consultancy' able to make judgements about our ethical accountability to the organisation, its stakeholders, and to ourselves.
Some of the ideas, being based on US law, are not directly applicable everywhere, but the overall argument is, and it's crucial to the future.
The article stops short of a full description of the solution - which is fair enough, as it's seeking to illustrate the problem.
Outside the US, governance thinking has understood this for some time. The law in the UK, South Africa, and other places that have accepted the thinking found in the Cadbury Report, and the King Commission, is that Corporations are required to be good corporate citizens. Their duty is indeed not to maximise profit for shareholders, rather, their duty is to deliver value to all their stakeholders (and, of course, shareholders are a stakeholder, and returns are important to them).
Corporate governance, requiring that corporations deliver value to their stakeholders is a powerful principle, particularly when enforced through a 'comply or explain' method (not ticking boxes on a pro-forma 'have you complied with X' sheet).
What it means is that corporations have to understand who their stakeholders are - the inhabitants of Bhopal were stakeholders in Union Carbide, as they found out, most horribly. If Union Carbide had known that they were stakeholders, and known that it had a corporate duty, to make sure that there was no negligence at that site that could lead to such a disaster, then history would have been very different.
They then have to understand how their vision, mission and charter can deliver value appropriately to all their stakeholders.
Part of the difficulty, particularly for those who have only been aware of profit as a value, is understanding what stakeholder value is, and how to govern it.
A method, Service Governance, using existing best practice frameworks as a basis, exists to help identify stakeholder value, and govern that value, using the paradigm of a 'service' and governing the organisation through a service portfolio, optimising the value / cost ratio, for stakeholder value.
There's more on Service Governance here:
Adopting Service Governance - Governing Portfolio Value for Sound Corporate Citizenship
There is an example of Service Governance working, a short video, on the web-site www.service-governance.org
Adopting Service Governance - a short introduction (Video)
There are also blogs, discussing service governance here:
Governance thinking, even in the US, is moving. When we are providing consultancy to organisations, we need to be aware of this shift, and, as discussed in 'Collaborative Consultancy' able to make judgements about our ethical accountability to the organisation, its stakeholders, and to ourselves.
Some of the ideas, being based on US law, are not directly applicable everywhere, but the overall argument is, and it's crucial to the future.
The article stops short of a full description of the solution - which is fair enough, as it's seeking to illustrate the problem.
Outside the US, governance thinking has understood this for some time. The law in the UK, South Africa, and other places that have accepted the thinking found in the Cadbury Report, and the King Commission, is that Corporations are required to be good corporate citizens. Their duty is indeed not to maximise profit for shareholders, rather, their duty is to deliver value to all their stakeholders (and, of course, shareholders are a stakeholder, and returns are important to them).
Corporate governance, requiring that corporations deliver value to their stakeholders is a powerful principle, particularly when enforced through a 'comply or explain' method (not ticking boxes on a pro-forma 'have you complied with X' sheet).
What it means is that corporations have to understand who their stakeholders are - the inhabitants of Bhopal were stakeholders in Union Carbide, as they found out, most horribly. If Union Carbide had known that they were stakeholders, and known that it had a corporate duty, to make sure that there was no negligence at that site that could lead to such a disaster, then history would have been very different.
They then have to understand how their vision, mission and charter can deliver value appropriately to all their stakeholders.
Part of the difficulty, particularly for those who have only been aware of profit as a value, is understanding what stakeholder value is, and how to govern it.
A method, Service Governance, using existing best practice frameworks as a basis, exists to help identify stakeholder value, and govern that value, using the paradigm of a 'service' and governing the organisation through a service portfolio, optimising the value / cost ratio, for stakeholder value.
There's more on Service Governance here:
Adopting Service Governance - Governing Portfolio Value for Sound Corporate Citizenship
There is an example of Service Governance working, a short video, on the web-site www.service-governance.org
Adopting Service Governance - a short introduction (Video)
There are also blogs, discussing service governance here:
Wednesday, 24 February 2016
Centaurs: Organisational Change Management and horse riding.
Centaurs: Organisational Change Management & horse riding.
Part of the problem with organisational change is perception. People see it as something you do, like driving a car, or riding a bicycle. It isn't, though, like that, it's more like riding a horse.
If the horse wants to make a dash for home, or throw you into the ditch, that's what it'll do.
You have to help the horse see things your way, and agree to go where you want it to go, and you have to be aware that horses get tired, and need feeding, because, if you don't feed them, rest them, and give them time to play, they become sullen, resentful, uncooperative and, eventually, die.
It's also best not to walk behind a horse - with organisations it isn't alway obvious where the behind is. [though you might guess]
If you wish to be good at organisational change, you need the equivalent of riding lessons - and, if you've learned to ride a horse, you'll know that riding lessons involve lots, and lots of practice.
You also learn that you can't ride a horse on autopilot. You have to be one the horse and aware of it's every twitch and mood. You have to be fully engaged with the horse - with top riders, the horse and the rider seem to be one creature, with one mind.
Some believe that that is where the myth of the centaur came from - seeing horses ridden so that they looked like one creature, part horse, and part man.
That's the aim. To be like that, when you work to change an organisation.
Sunday, 15 February 2015
Dishonesty, sharp practice and good Corporate Citizenship
One important part of service governance, and most modern thinking about governance under 'comply or explain' is that a company should work to be a good 'corporate citizen'.
Is sharp practice against good corporate citizenship?
Clearly much 'sharp practice' is not illegal, but legality is not the only test of being a good corporate citizen.
Think of this example. You've probably encountered it. A supplier of a fairly intangible thing such as air time or data download sells it in bundles.
So far so good. There's nothing wrong with bundling things up and selling them in bundles for convenience. It'd be really painful if spaghetti wasn't sold in bundles.
But you pay for spaghetti in arrears - you get the bundle of spaghetti, then you pay for it.
With one of these intangibles you have to pay in advance.
Also, spaghetti takes a long time, several years, to go off, so, if you buy too much, it just takes longer to use it.
Bundles of things like air time, though, never have to 'go off'. In fact, they can't 'go off'. If you bought a minute of air time in 1995 it would have been a lot more expensive than now, but, there's no reason why the company you bought it from, if it still existed, shouldn't honour your purchase and give you the minute today.
But these bundles are given an artificial 'expiry date' after which they won't be honoured - often as short a time as a month.
If you run out of a bundle, then you can buy another one.
This is where the problem starts. Not all bundles are equal. Sometimes there's a minimum bundle size and small bundles cost more than big ones. Sometimes there's a much more expensive flat rate that you have to pay if your bundle runs out.
What is going on here is the basis of the sharp practice. Companies who sell like this are not wanting to sell the commodity fairly. They actually want to cheat their customers out of either money or the commodity (which is money). It works like this:
1. If you're a small user, you buy the smallest bundle - but you don't use all of it. So it 'expires'. That is the company steals the remainder from you. That's theft in the common law sense - because you signed a contract agreeing that they could 'expire' it on you, it isn't counted as theft because you signed up to be robbed.
2. If you are a large user, you buy a big bundle to get the discount, but, if you go over that usage, because you have to buy in advance, you have to pay the flat rate - which is often many times higher than the lower rate.
The selling company is actually gambling with you. It is hoping that either you won't consume all of what you've bought, so they can steal it, or that you will consume more than you estimate, so they can charge you a punitive rate.
The companies would say that this is not dishonest, as the lawyer would say, because the contract allows for exactly this form of cheating.
It is, though, sharp practice. Instead of selling the commodity to make money, the company is making money on our inability to predict our consumption accurately.
Is it fair to penalise people for having uneven patterns of consumption?
Should a company that's a good corporate citizen be ripping off its customers because they have difficulty predicting their usage?
The argument that companies bring to continue the practice is that 'everybody else does it'. Is that a good argument against acting responsibly towards your customers?
Let's say that one company broke ranks and said, you can by the commodity from us for one single price, let's say X per unit. It doesn't matter if you consume 10 units or 1000 units, it's the same price.
That price would be easy for it to work out. It would simply take the total income today and divide it by the total units.
Would that company do better or worse?
It would attract more small users - they'd have less to pay.
Would it attract more big users? I think it would. As a big user, you'd prefer to pay a known rate, perhaps a bit bigger than the apparently tempting bundle price, but less than the far too expensive flat rate.
If you, as a customer, had a choice between an honest flat-rate company, and one that used sharp practice against its customers, wouldn't you choose the good corporate citizen yourself?
Is there any big company out there prepared to try this and make the results known?
If so, please try it. Maybe it could usher in a new era of good corporate citizenship.
If not - wouldn't that let us know just how much is made from the penalising of customers for not predicting the future? Might that not then be a good reason to press for legislation to make this rip-off illegal?
Is sharp practice against good corporate citizenship?
Clearly much 'sharp practice' is not illegal, but legality is not the only test of being a good corporate citizen.
Think of this example. You've probably encountered it. A supplier of a fairly intangible thing such as air time or data download sells it in bundles.
So far so good. There's nothing wrong with bundling things up and selling them in bundles for convenience. It'd be really painful if spaghetti wasn't sold in bundles.
But you pay for spaghetti in arrears - you get the bundle of spaghetti, then you pay for it.
With one of these intangibles you have to pay in advance.
Also, spaghetti takes a long time, several years, to go off, so, if you buy too much, it just takes longer to use it.
Bundles of things like air time, though, never have to 'go off'. In fact, they can't 'go off'. If you bought a minute of air time in 1995 it would have been a lot more expensive than now, but, there's no reason why the company you bought it from, if it still existed, shouldn't honour your purchase and give you the minute today.
But these bundles are given an artificial 'expiry date' after which they won't be honoured - often as short a time as a month.
If you run out of a bundle, then you can buy another one.
This is where the problem starts. Not all bundles are equal. Sometimes there's a minimum bundle size and small bundles cost more than big ones. Sometimes there's a much more expensive flat rate that you have to pay if your bundle runs out.
What is going on here is the basis of the sharp practice. Companies who sell like this are not wanting to sell the commodity fairly. They actually want to cheat their customers out of either money or the commodity (which is money). It works like this:
1. If you're a small user, you buy the smallest bundle - but you don't use all of it. So it 'expires'. That is the company steals the remainder from you. That's theft in the common law sense - because you signed a contract agreeing that they could 'expire' it on you, it isn't counted as theft because you signed up to be robbed.
2. If you are a large user, you buy a big bundle to get the discount, but, if you go over that usage, because you have to buy in advance, you have to pay the flat rate - which is often many times higher than the lower rate.
The selling company is actually gambling with you. It is hoping that either you won't consume all of what you've bought, so they can steal it, or that you will consume more than you estimate, so they can charge you a punitive rate.
The companies would say that this is not dishonest, as the lawyer would say, because the contract allows for exactly this form of cheating.
It is, though, sharp practice. Instead of selling the commodity to make money, the company is making money on our inability to predict our consumption accurately.
Is it fair to penalise people for having uneven patterns of consumption?
Should a company that's a good corporate citizen be ripping off its customers because they have difficulty predicting their usage?
The argument that companies bring to continue the practice is that 'everybody else does it'. Is that a good argument against acting responsibly towards your customers?
Let's say that one company broke ranks and said, you can by the commodity from us for one single price, let's say X per unit. It doesn't matter if you consume 10 units or 1000 units, it's the same price.
That price would be easy for it to work out. It would simply take the total income today and divide it by the total units.
Would that company do better or worse?
It would attract more small users - they'd have less to pay.
Would it attract more big users? I think it would. As a big user, you'd prefer to pay a known rate, perhaps a bit bigger than the apparently tempting bundle price, but less than the far too expensive flat rate.
If you, as a customer, had a choice between an honest flat-rate company, and one that used sharp practice against its customers, wouldn't you choose the good corporate citizen yourself?
Is there any big company out there prepared to try this and make the results known?
If so, please try it. Maybe it could usher in a new era of good corporate citizenship.
If not - wouldn't that let us know just how much is made from the penalising of customers for not predicting the future? Might that not then be a good reason to press for legislation to make this rip-off illegal?
Wednesday, 17 September 2014
Analysing business processes - suggestions for the Business Analysis of workflow
There was a question about how to do a workflow analysis on the facebook group Back2ITSM and I thought that it might have more general interest for anybody needing to get involved with that sort of thing.
That's presupposing that there is a flow that's repeatable - which may, or may not, be the case.
If you're meaning a 'time & motion' study, or 'workflow analysis', there are a few different ways of looking at what needs to be done.
Time & Motion studies were all the rage in the '70s, my brother had a vac job doing them for Tongaat sugar company. They've now been subsumed under what's now called 'LEAN'. They're renamed 'method and time' studies. It's all, essentially, observation using clipboards and stop watches, or the modern equivalent, and ignoring findings in physics that suggest that measurement of something alters the thing measured.
There certainly is value in establishing what the flow is, if only to establish where there are wasteful loops that establish nothing, but have been traditional - like the finding, one day, in the British Army, that one of the chaps in an artillery battery was there to hold the horses, decades after the horses had ceased to be there.
One way of speeding up the discovery is to get the names and positions of all the people who authorise things (you'll be doing this for a bureaucratic company, sans doubt) and then interview them about their jobs - you can ask them about all the things they authorise, but the only important piece of intelligence is whether they've ever rejected anything - if they haven't then their authorisation is redundant and you've found a wasteful loop.
If you want to then document the flow of work that's evolved in an organisation over, perhaps, several decades, your best tool is probably something like SPICE - an electronic circuit diagram tool, very good at documenting rat's nests.
The tool that I use for a first approximation to such diagrams, in real life, is the most excellent 'dot' language, used to produce directed graphs - it's free (of course, as good stuff so often is) and you can learn about it and get to a download site from here:
https://en.wikipedia.org/wiki/Graphviz
Everybody, I assumed, knew about this magnificently easy to use and powerful tool - but I've encountered lots of people who've only been exposed to the famous WeaklingGesture product from the evil empire and cannot believe that I can produce a good looking, fairly complex diagram in three or four minutes.
I often use my 'dot' files with Omnigraffle, because it's very good for the later stages.
If you're wanting to be more analytical and have flasher, more 'from the expert' looking pictures, then lots of people use UML that, like COBOL is meant to be as easy for managers to understand as techies - [hollow laugh]
I'd recommend, instead, using BPMN, which is less like a circuit diagram and much easier to work with - as well as being considerably more expressive. You can get free tools for it, but I happen to use something called 'Visual Paradigm' that's quite expensive, but works pretty well - as long as you don't expect any miracles from the support team in Hong Kong - http://www.visual-paradigm.com/whats-new/ get the free download and try it for a few days to see if it's your thing. The free tools are just as good, in many ways, but I didn't get on well with the X11 interface.
If you want to really get down to the nitty gritty - and I'd recommend leaving this until phase III when you're finally getting to understand things and have made some improvements, then the Open Group's Archi is free and very good (as long as you're not using it for anything commercial, in which case it's furiously expensive). http://www.archimatetool.com
I've attached a picture of the Adaptive Service Model (takingserviceforward.org/wiki ) that was produced in Archi to give the idea.
Oh, and don't believe any documents or diagrams that you're given that are claimed to explain the process, but smell like something ready for the British Museum rare documents team.
That's presupposing that there is a flow that's repeatable - which may, or may not, be the case.
If you're meaning a 'time & motion' study, or 'workflow analysis', there are a few different ways of looking at what needs to be done.
Time & Motion studies were all the rage in the '70s, my brother had a vac job doing them for Tongaat sugar company. They've now been subsumed under what's now called 'LEAN'. They're renamed 'method and time' studies. It's all, essentially, observation using clipboards and stop watches, or the modern equivalent, and ignoring findings in physics that suggest that measurement of something alters the thing measured.
There certainly is value in establishing what the flow is, if only to establish where there are wasteful loops that establish nothing, but have been traditional - like the finding, one day, in the British Army, that one of the chaps in an artillery battery was there to hold the horses, decades after the horses had ceased to be there.
One way of speeding up the discovery is to get the names and positions of all the people who authorise things (you'll be doing this for a bureaucratic company, sans doubt) and then interview them about their jobs - you can ask them about all the things they authorise, but the only important piece of intelligence is whether they've ever rejected anything - if they haven't then their authorisation is redundant and you've found a wasteful loop.
If you want to then document the flow of work that's evolved in an organisation over, perhaps, several decades, your best tool is probably something like SPICE - an electronic circuit diagram tool, very good at documenting rat's nests.
The tool that I use for a first approximation to such diagrams, in real life, is the most excellent 'dot' language, used to produce directed graphs - it's free (of course, as good stuff so often is) and you can learn about it and get to a download site from here:
https://en.wikipedia.org/wiki/Graphviz
Everybody, I assumed, knew about this magnificently easy to use and powerful tool - but I've encountered lots of people who've only been exposed to the famous WeaklingGesture product from the evil empire and cannot believe that I can produce a good looking, fairly complex diagram in three or four minutes.
I often use my 'dot' files with Omnigraffle, because it's very good for the later stages.
If you're wanting to be more analytical and have flasher, more 'from the expert' looking pictures, then lots of people use UML that, like COBOL is meant to be as easy for managers to understand as techies - [hollow laugh]
I'd recommend, instead, using BPMN, which is less like a circuit diagram and much easier to work with - as well as being considerably more expressive. You can get free tools for it, but I happen to use something called 'Visual Paradigm' that's quite expensive, but works pretty well - as long as you don't expect any miracles from the support team in Hong Kong - http://www.visual-paradigm.com/whats-new/ get the free download and try it for a few days to see if it's your thing. The free tools are just as good, in many ways, but I didn't get on well with the X11 interface.
If you want to really get down to the nitty gritty - and I'd recommend leaving this until phase III when you're finally getting to understand things and have made some improvements, then the Open Group's Archi is free and very good (as long as you're not using it for anything commercial, in which case it's furiously expensive). http://www.archimatetool.com
I've attached a picture of the Adaptive Service Model (takingserviceforward.org/wiki ) that was produced in Archi to give the idea.
Oh, and don't believe any documents or diagrams that you're given that are claimed to explain the process, but smell like something ready for the British Museum rare documents team.
Labels:
asm,
ba,
bpmn,
dot,
graphviz,
omnigraffle,
spice,
uml,
visual-paradigm
Tuesday, 19 August 2014
What is the value of nothing?
Is it true that nothing is actually free? I'm not sure - literally nothing, a vacuum, costs quite a bit to make - you can get it free in space, but travelling there costs quite a bit. So you can find costs that you may have to pay for anything, but forget sophistry.
If you have a choice of whether to use a 'free' piece of software,
The real secret is to make sure that the cost is not one of your requirements. Cost on its own doesn't mean anything. Is a Rolls-Royce expensive? (no, it's a lot cheaper than a lear jet). What's important is the TCO - the Achilles heel of many cloud services is that you have to keep paying for them in five years time, when software you've bought has had four years in which to amortise the initial cost.
Even more important is the value/cost ratio. Developing your own solution may seem extremely expensive compared to buying an off-the-peg software package, but, if you base your development on a rock-solid open-source platform, then the fact that your software has been developed exactly to fit your requirements should make it better than any generic offering. So your cost/value ratio, in the long term, means that your TCO is tiny.
If you have a choice of whether to use a 'free' piece of software,
The real secret is to make sure that the cost is not one of your requirements. Cost on its own doesn't mean anything. Is a Rolls-Royce expensive? (no, it's a lot cheaper than a lear jet). What's important is the TCO - the Achilles heel of many cloud services is that you have to keep paying for them in five years time, when software you've bought has had four years in which to amortise the initial cost.
Even more important is the value/cost ratio. Developing your own solution may seem extremely expensive compared to buying an off-the-peg software package, but, if you base your development on a rock-solid open-source platform, then the fact that your software has been developed exactly to fit your requirements should make it better than any generic offering. So your cost/value ratio, in the long term, means that your TCO is tiny.
Subscribe to:
Posts (Atom)

