Wednesday, December 20, 2006

Competition vs Cooperation

http://www.blogger.com/comment.g?blogID=8539456&postID=115893966784399322


Interesting comment from Anonymous above. I do agree in part with their comments. Cooperation is a key trait in the development and evolution of the human body of knowledge. However, I would also have to point out that the competition “clause” still applies in the two examples given. The difference is in the level of organisation.


Rather than two individuals competing, in these cases it was two countries or groups of countries. Without the competing pressure of war or national pride, the governments would not have been motivated to remove the barriers between the small units (such as individuals or companies).


Is cooperation a uniquely human trait? There are plenty of examples in nature of non-human, and even non-simian cooperation. For example wolves raising alpha couple’s pups. Or go lower in the level of complexity and look at colonial organisms such a Man O’Wars. Likewise there are plenty of examples of intra-species competition.


On a software level cooperation is necessary and beneficial even in a competitive model. If I want to write/market/sell a killer product I can’t do that on my own. Not only would I need help in writing the product (otherwise it would take too long) but I would also benefit from working with marketing and sales to distribute my product.


My post is not intended to suggest that competition is the only way. I firmly believe that cooperation through standards and patterns provides a more mature model of product development that benefits not only the end customers, but also the development companies. On the parameters of the product, standards are vital in allowing it to cooperate in an integrated environment.


I do, however, firmly believe that competition between companies in a similar space ultimately benefits the end user through driving innovation and quality. Competition does not need to be, nor should be suffered to be abusive.


Tags: , ,


Powered by Qumana


Monday, October 30, 2006

Ok, slightly different topic...

The universe is a big place. Impossibly large in fact. This video does an interesting job of putting into perspective the size of the universe:


http://geeksaresexy.blogspot.com/2006/10/hubble-deep-field-most-important-image.html



But. Something occured to me watching it. Something I once saw as a child. The words of a song...



"So remember when you’re feeling very small and insecure
How amazing and unlikely is your birth
And pray that there’s intelligent life somewhere out in space
‘Cause there’s bugger all down here on earth."


Ok, actually it's the first two lines there. The most impressive thing about the video is not the awesome reaches of space, but the kid singing with complete abandon into his web cam! A life being lived. Pretty cool!


Tags:


Powered by Qumana


What have you done to make it better?

"When you hear that a Japanese library is about to start using palm-vein technology to recognise the borrowers taking out its books, what is your instinctive reaction? Do you think, how marvellous - I've spent years worrying that someone might nick my identity and start taking out Anita Desai and Agatha Christie under my name? Or do you think, hang on a minute - that plastic library card has really been no hassle, and I really don't want to find myself living in the tracking and surveillance world of Minority Report?"

This, for me, highlights one of those critical elements in information technology. We get caught up in the wonderfully fantastic things we can do. Look at the cool technology we can bring to bear on this. How amazing!


 But whats the point? How often do we stop and ask where the benefit is? We can design many many cool pieces but if it doesn't solve a real problem for users then who's time are we wasting? Theirs or ours?


Or to put it another way; If it's not broken, don't fix it!


[Ref: http://www.guardian.co.uk/terrorism/story/0,,1923240,00.html Jenni Russell]


Tags:


Friday, September 22, 2006

Open Source vs. Proprietary

It was about 203,563 years ago, on a Tuesday morning, at about 11ish in the morning. The sun was bright in the sky and there was a gentle breeze from the south. Og had a brainwave. So sick was he of burning his hands while trying to cook a rat that he picked up a stick, rammed it through the rat and held it over the fire. Beautiful he thought! Now Ms Oog will like him since he'll be able to pick lice from her back without burnt hands! Then the stick burnt through and the rat fell in the fire. Damn.


Brian was watching this and had another brainwave. He soaked the stick in water and did the same. Perfection. Crispy rat, non-crispy hands, and he ran off with Ms Oog much to Ogs disgust.


Right there, at that point competition between humans began. And so did innovation.


Roll forward 203,563 years later and competition is alive and well, and one of the most hotly debated concepts around. Especially in software. Two seemingly polarised camps have emerged, tribes if you will; open source vs. proprietary. Both are powerfully represented and passionately defended. Often the arguments between the camps are vitriolic and personal. From the open source camp comes the charge that the proprietary tribe are evil and self serving. From the proprietary group come the charges of tree hugging etc etc....


But both have solid arguments and neither are truly wrong. Open source leads to large scale groups of minds that can refine ideas over a large area. From proprietary comes innovation driven by competition. Think back to all the technological advances that have been made during war time. Would jets have developed so quickly? Would computers have been so prevalent?


Imagine a world without competition. Imagine, if you will, that Microsoft ME was the last desktop. No competition to drive the development of new software. Ok, you can stop screaming now. Without competition would we be driven to develop new advances?


I have never been 100% on one side or the other. As a system integrator I dislike closed systems. As a business person, I like competitive edge.


So what am I talking about? My greatest area of interest is in standards. For me SOA provides an interesting balance between open source and proprietary methodology. Define the interfaces and communications between systems in a standard based, community agreed way, and treat the implementation of the service (the black box portion if you will) as proprietary. Within Healthcare we have HL7 as the primary developer of standards. Recently a new Special Interest Group (SIG) has been started up; SOA for HL7. Reviewing the draft documentation from the group I see that the primary intent is to describe the service definition without technological specifics (as much as possible) and then leave the implementation of the service up to individual companies and providers.


For me this is a perfect balance between the two tribes; it allows me to ensure the work I do benefits everyone, whilst leaving me free to innovate and develop a competitive edge. I can satisfy my desire to work to a common good by involvement in the organisation AND still provide benefit to my company.


Within the industry we have discussed standards for years, but it is only recently that I have begun to feel that this is truly becoming a realistic possibility. So I will continue to harp on about standards to my customers and colleagues (sorry guys)!


Tags: , , ,


Powered by Qumana


Friday, September 15, 2006

HL7 Ballot Site

Well the latest version of the ballot is up on the HL7 site for v3. Actually it might have been up for a while but I've been on holiday! (Rare thing I know!)


http://www.hl7.org/v3ballot/html/welcome/introduction/index.htm


Tags: ,


Powered by Qumana


Friday, September 08, 2006

Fast or slow

You know, as developers we have become lazy. To be fair it's not our fault. It makes sense for us to be lazy. It is econmically responsible for us to be this way. Consider, as developers should we spend time shaving 5% off the overall speed of our applications when we can install the application on a fast machine that will not even register the difference? Does that make sense for our customers? In fact much of my time is spent convincing people it doesn't. Development time costs more that processing power, and memory, and network speeds are so fast these days that why bother?


But then just when you think it will never matter again, circumstances come along that change your view point and you really wish things were more carefully written. For example a customer in the far north has a number of remote sites connected by satellite phone. And dog sleds. I kid you not. So all the "slow" applications that send large data volumes suddenly become problematic. Even worse are web apps. Fat clients might be easier, but remember the dog sleds? Good luck installing them.


Numerous countries that are developing are bypassing the copper/fibre networks and moving directly to wireless and satellite. Heavy network requirements need to be examined in these cases.


So I have been thinking, does AJAX give us a way through? Develop a virtual fat client web app, that makes heavy use of client side caching, and then use AJAX to refresh data at the start and end of a process.


Tags:


Powered by Qumana


Wednesday, September 06, 2006

HL7 Object Model

So I can't believe its been a year since the normative standard of HL7 version 3 has been released. It seems years in the coming, and now here it is.

But that's obviously just the start. So we have the RIM. We have DMIMs. And we have schemas. In fact we have a lot of schemas. 1000's in fact. And many different data types. So the next big question is how do we use them?


Well that probably depends on what you are trying to achive. (As a side note that's one of the reasons why there are so many; controlled flexibility) Interested in a detailed healthcare data model around the Laboratory? Try the Lab Domain DMIM. Interested in allowing a doctor to request an appointment with a hospital for a patient? Look at the interactions for the Scheduling Domain. And that's were the benefit and pitfall of the Version 3 paradim lie. It can be used to describe just about anything in the healthcare space, so where do you start?


One area of interest is in the generation of class libraries that reprisent the data contained within the interaction messages. There are many reasons why you would want to do this, say simplifying development of software that would like to communicate in the HL7 v3.0 world. But again there are many situations where this is hardly ideal, say when you want to extract a single value from the message.


I have enough reasons to make it worthwhile. So. If you try and generate a series of class libraries directly using a tool you end up with an awful lot of classes. Not so helpful. With thousands of datatypes being represented by thousands of classes you might as well use xPath given the memory requirements. A more subtle approach may be required.


One area I am currently investigating is the generation of base libraries of data types. I think the best approach is to start with the core schemas in the HL7 schemas. Only data types that have actual implementations will be included (so if an element is cloned but never used it's out). Once these have been modelled its onto the CMETs. Then we can start looking at software factories, or tools to generate domain specific classes.


The trick here is going to be namespacing to prevent redevelopment or multiple reprisentations of the same data type. Once the basic platform is created tools will hopefully provide the way forward to creating specific and re-usable, but most of all fast classes for serializing/deserializing HL7 interactions. Beyond that? Auto generation of web service end points, databases and fully interactive class systems (i.e. the system should be aware of associated messages).


I'll let you know how it goes!


Addendum:
Steve Hart has posted on this subject as well at http://www.hartsteve.com/2006/09/11/hl73-xml-msg-receipt-handling/


Tags: , , , ,


Wednesday, January 04, 2006

Temporal Sequencing In BizTalk

Temporal sequencing relates to the ability of a message broker to ensure that messages are sent out in the order in which they are received. In a simple broker this is a simple matter as each message is processed one by one in the order in which they are received. At a very basic level this can be insured by writing the messages to the data store as they are received and thenprocessing messages from the top of the table first.

Within BizTalk this is a larger issue since multiple treads of processing can occur at the same time, and there is no guarantee that each thread will execute at the same rate, or that the amount of processing time will be equal for each message. The processing time will be affected directly by the size and complexity of each message. This is further compounded by the ability of BizTalk to be clustered.

The result of this is that BizTalk does not guarantee the order of messages. It is important to realize this is not a design flaw rather an inherent result of the mechanisms used within BizTalk to ensure scalability and efficiency. Its also worth noting that for the large majority of cases this is not an issue and the speed of the product is far more important than the temporal sequencing of the messages.

In HealthCare however there are a number of valid circumstances where temporal sequencing is required. A good example of this would be admission. If a patient is admitted into a hospital typically an A01 would be raised to show that event. If a admitting clerk then realized that the name was incorrect they would make a change to demographics and this would be represented by an A08. If the A08 is received prior to the A01 by a target system then an error condition would be encountered. That situation is a problem but a worse situation would be where two A08 were sent with the second overriding the first. In that case the target system would end up with the wrong data, with no error raised.

One solution to the problem has been provided by Microsoft on GotDotNet (http://www.gotdotnet.com/Community/UserSamples/Details.aspx?SampleGuid=a50f9c7f-6c56-4791-86fb-68c4e4449713). Briefly (the documentation explains the problem and solution well) the provided solution utilizes an auxiliary database to track message order. When a message arrives into the receive pipeline an entry is made in a tracking database. When the message leaves the send pipeline the message is checked to ensure that it is the oldest. If it is not, the pipeline returns null and the message is not sent.An additional orchestration is used to insert a hold into the process so that other threads in action have a chance to complete, hopefully releasing the older messages.

The solution is quite simple and can be implemented by the code provided or a similar system can be easily coded.

One word of warning though; by including this mechanism in the broker performance will be impacted for a couple of basic reasons. Firstly the orchestration used to insert a hold will take processing power and time, as will the additional pipeline components used. Secondly each message is not free to process and release as fast as possible.

In the end the system is a trade off. If you require temporal sequencing then you will need to sacrifice some performance. If you dont then do not implement this solution.

(Thanks to Suren MachiRaju for posting this)