spectare.nl

Met gedachte om een kliniek beter te automatiseren, wordt er concept opgebouwd waarbij er zoveel mogelijk gebruik gemaakt wordt van beschikbare software op de PC. Hierdoor ontstaat er een informatiesysteem dat te gebruiken valt met het adresboek, de kalender (iCal) en de browser (Safari) van Apple. 

De kliniek draaide op windows met MS Office (wie niet) en sinds een maand of wat op Apple OS X met Office voor de Mac. (We hebben ook iWork geprobeerd maar dat was niet zo handig)

Sindsdien hoor ik vrij veel dat mensen bestanden kwijt zijn, die later op een andere plaats blijken te staan. 

Wat blijkt ?

Apple heeft een andere logica rondom het bewaren (opslaan (als)) van bestanden. Windows geeft de folder waar het bestand is geopend. Apple lijkt standaard de laatste locatie waar iets bewaard is te geven.

Als je als ex-windows gebruiker even niet oplet staan je geopende brieven dan ook in andere folder dan waar je deze geopend had.

Het is nu een jaar geleden dat ik in de zorg aan de slag ben gegaan. Wat me opviel is het gesloten en beschermende karakter van de ICT partijen in deze markt. Veel gelijke zaken worden door vele partijen als pakket of maatwerk geleverd en dit wordt door vele ziekenhuizen en klinieken weer afgenomen.

Om maar een voorbeeld te noemen ‘Controle op Verzekeringsrecht’ via Vecozo. Hoeveel partijen hebben deze koppeling al niet gemaakt ? (Wat overigens een door de verzekeraars gedeelde ontwikkeling is)

Waarom wordt er niet meer gedeeld op het gebied van ICT in de zorg ?
Op het medische vlak is dit uitstekend ontwikkeld, complete behandel methoden en zorg trajecten worden gedeeld en samen gemaakt door specialisten uit het hele (buiten)land.

Om naar het voorbeeld terug te gaan : vanuit de zorgverleners en instellingen zou het een stuk goedkoper en kwalitatief beter zijn om samen zo’n koppeling te maken en te gebruiken. Dan kan je je nog afvragen of je niet veel verder kan gaan in het delen om zo zelfs een informatie systeem gedeeld op te zetten.

Dat is de vraag die me bezig houdt.

Many people these days, use some type of build framework. Especially the java side of the world is pretty advanced but you see many things happening at the ruby side and python side too.

I’d like to use a build framework as a sample how it kills your productivity.

Assume you have ANT based framework using targets to build and test your software. How would you call these ?
Most people will go for something like ant jar, ant dist, ant test
As said, most people do but the target names are free and ambiguous. Nothing wrong with that , you just need to tell people what they need to type in order to build and test your software.

Just telling people, adds up to knowledge that can’t be foreseen by the consuming party. This is is a piece of implicit knowledge required to consume the provided software.
When the software grows, things are added to ANT to support reporting tasks, coding standards checking, code coverage checking and so on. Most of these elements need specific care before you can use that….. again you are adding implicit knowledge that prevent people from consuming that out of the box.

In the end people need to know too many things and that will prevent eventually the consumption of your piece of software. It claims the time that others could have used to continue their own works.

This is just a sample of build framework, the same counts for the architecture and implementation of your software. The moment you just need to know some ‘small’ things in order to get it to work it becomes harder to use it.
This will lead to longer development time and a steeper learning curve.

In the end your software can hardly be used outside a controlled environment and leads to longer lead times during development.

I wrote this post as a reply to the post on Arjen Poutsma’s Blog entry: The Quest for the Domain Expert
Arjen refers to definitions of the Domain Expert as found in the specification of EJB and BPEL, the first looks more like a technical assembly task that belongs to a deployment process and therefore still is software driven. The BPEL definition contains the same notion:
The creation of the BPEL is a developers job, attachment to services is a domain experts’ job
At least that could be an explanation of the small piece of text.
The concept of the Domain Expert is also connected to Expert Systems.
If we define the Domain Expert as a professional in a more business oriented job, the separation could be more useful.
It might be that BPEL as a whole is not on the right level of abstraction for Domain Experts, still the Service Oriented Architecture and standards around web-services make it possible to grow to a situation that Domain Experts could ‘compose’ a solution for their needs.

There are a few conditions:

The Domain Expert should be able to learn the ‘language’

Language in the broad sense of the word. For example many Financial Domain Experts are pretty handy with Excel, most of the times it ends up with a special type of programming inside spreadsheets. So, you can say that Domain Experts are able to learn a specific type of language as long as it fulfills their needs.
A more visual language like BPEL – or better BPMN – gives the possibility to master the logic behind the language.

Services should have a Business Logic Type of interface

To keep the comparison with Excel, inside excel all types of calculation and information are fixed. A webservice is much more flexible with its’ responsesWeb-services could very well return 3rd generation programming language types of results, like a Map with objects that need to be used to build your own decision (while loops with if then else constructions). These types of web-services make it quite impossible for Domain Experts to compose their solution as the level of abstraction moves down towards a 3rd generation programming language and requires programming thinking and skills.
Web-services are better fitted on the business interface type of level, don’t return a list of objects but work with interfaces like:

Verify Creditcard Number
Cancel Order
Ship Order Via

I strongly believe in design by contract, there should not be a hard link between your web-services interface and your code
When the conditions are met, Domain exports could manage themselves by modeling their solutions and execute those. It will remain a tough task to meet the conditions though.
In the end it will not lead to improved productivity for developers but mere a division between service building (business logic type of interface) and the consumer of these interfaces, it moves work towards another type of person, that might be the Business Oriented Domain Expert.