Revision [251]
Last edited on 2010-09-26 13:10:52 by MartinWehlouAdditions:
Now we've arrived at the last of the solutions in my list, namely "Opening the market for smaller entrepreneurs". There are a number of reasons we have to do this, and I've touched on most of them before in other contexts.
- You don't have to worry about interconnections; there aren't any
- You don't have to figure out who to call when things go wrong, there's only one vendor to call
- You can reduce your support staff, at least you may think so initially
- You can avoid all arguments about requirements from the users, there is nothing you can change anyway
- It looks like good leadership to the uninitiated, just like Napoleon probably looked pretty good at Waterloo, at least to start with
- Since you have no escape once the decision is made, the costs are usually much higher than planned or promised
- There is only one support organization, and they are usually pretty unpleasant to deal with, and almost always powerless to do anything
- Any extra functionality you need must come from the same vendor, and will cost a fortune, and will always be late, bug-ridden, and wrong
- The system will be worst-of-breed in every individual area of functionality; its only characteristic being that it is all-encompassing (like mustard gas over Ieper)
- The system will never be based on a simple architecture or interface standards; there is no need for it, the vendor usually doesn't have the expertise for it, and the designers have no incentives to do a quality job
- Since quality is best measured as the simplicity and orthogonality of interfaces and public specs, and large vendors don't deliver either of these, there is no objective measure of quality, hence there is no quality (there's a law in there somewhere about //"that which is not measurable does not exist";// was it Newton who said that?)
- Due to poor architecture, the system will almost certainly be developed as too few and too large blocks of functionality, making them harder than necessary to maintain (yes, the vendor maintains it for you, but you pay and suffer the poor quality)
There's no way out of this for the small vendors and the users if you need standards to interoperate, but lucky for us, standards are largely useless and unnecessary even in the best of cases. All it takes is for one or two small vendors to publish de facto standards, simple and practical enough for most other vendors to pick up and use. I've personally seen this happen in Belgium in the 80's and 90's where a multitude of smaller EHR systems used each other's lab and referral document standards, instead of waiting for official CEN standards, which didn't work at all once published. In the US, standards are generally not invented by standards bodies, but selected from de facto standards in use, and then approved, which explains why US standards usually do work, while European standards don't.
- You don't have to worry about interconnections; there aren't any
- You don't have to figure out who to call when things go wrong, there's only one vendor to call
- You can reduce your support staff, at least you may think so initially
- You can avoid all arguments about requirements from the users, there is nothing you can change anyway
- It looks like good leadership to the uninitiated, just like Napoleon probably looked pretty good at Waterloo, at least to start with
- Since you have no escape once the decision is made, the costs are usually much higher than planned or promised
- There is only one support organization, and they are usually pretty unpleasant to deal with, and almost always powerless to do anything
- Any extra functionality you need must come from the same vendor, and will cost a fortune, and will always be late, bug-ridden, and wrong
- The system will be worst-of-breed in every individual area of functionality; its only characteristic being that it is all-encompassing (like mustard gas over Ieper)
- The system will never be based on a simple architecture or interface standards; there is no need for it, the vendor usually doesn't have the expertise for it, and the designers have no incentives to do a quality job
- Since quality is best measured as the simplicity and orthogonality of interfaces and public specs, and large vendors don't deliver either of these, there is no objective measure of quality, hence there is no quality (there's a law in there somewhere about //"that which is not measurable does not exist";// was it Newton who said that?)
- Due to poor architecture, the system will almost certainly be developed as too few and too large blocks of functionality, making them harder than necessary to maintain (yes, the vendor maintains it for you, but you pay and suffer the poor quality)
There's no way out of this for the small vendors and the users if you need standards to interoperate, but lucky for us, standards are largely useless and unnecessary even in the best of cases. All it takes is for one or two small vendors to publish de facto standards, simple and practical enough for most other vendors to pick up and use. I've personally seen this happen in Belgium in the 80's and 90's where a multitude of smaller EHR systems used each other's lab and referral document standards, instead of waiting for official CEN standards, which didn't work at all once published. In the US, standards are generally not invented by standards bodies, but selected from de facto standards in use, and then approved, which explains why US standards usually do work, while European standards don't.
Deletions:
- You don't have to worry about interconnections, there aren't any
- You don't have to figure out who to call when things go wrong, there's only one vendor to call
- You can reduce your support staff, at least you may think so initially
- You can avoid all arguments about requirements from the users, there is nothing you can change anyway
- It looks like good leadership to the uninitiated, just like Napoleon probably looked pretty good at Waterloo, at least to start with
- Since you have no escape once the decision is made, the costs are usually much higher than planned or promised
- There is only one support organization, and they are usually pretty unpleasant to deal with, and almost always powerless to do anything
- Any extra functionality you need must come from the same vendor, and will cost a fortune, and will always be late, bug-ridden, and wrong
- The system will be worst-of-breed in every individual area of functionality; its only characteristic being that it is all-encompassing (like mustard gas over Ieper)
- The system will never be based on a simple architecture or interface standards; there is no need for it, the vendor usually doesn't have the expertise for it, and the designers have no incentives to do a quality job
- Since quality is best measured as the simplicity and orthogonality of interfaces and public specs, and large vendors don't deliver either of these, there is no objective measure of quality, hence there is no quality (there's a law in there somewhere about "that which is not measurable does not exist"; was it Newton who said that?)
- Due to poor architecture, the system will almost certainly be developed as too few and too large blocks of functionality, making them harder than necessary to maintain (yes, the vendor maintains it for you, but you pay and suffer the poor quality)
There's no way out of this for the small vendors and the users if you need standards to interoperate, but lucky for us, standards are largely useless and unnecessary even in the best of cases. All it takes is for one or two small vendors to publish de facto standards, simple and practical enough for most other vendors to pick up and use. I've personally seen this happen in Belgium in the 80's and 90's where a multitude of smaller EHR systems used each other's lab and referral document standards, instead of waiting for official CEN standards, which didn't work at all once published (see my previous blog post). In the US, standards are generally not invented by standards bodies, but selected from de facto standards in use, and then approved, which explains why US standards usually do work, while European standards don't.
