Our Tech Radar is an opinionated recommendation from some OpenMRSers who have been involved in many projects over the years, about what technologies you should be using, or avoiding, when building your OpenMRS implementations and distributions.
What is the structure?
The metaphor is a “radar” showing information about technologies, and how close they are to being recommended for adoption. (We took inspiration from the thinking behind ThoughtWorks’s radar.)
We organized the technologies we discussed into four quadrants:
Languages & Frameworks
Modules & Distributions
Standards & Conventions
Platforms & Integrations
Then we made a recommendation about each technology:
Adopt … projects really should use these technologies (in the appropriate contexts, of course)
Trial … projects should pilot/trial these technologies, and make an informed decision about whether they are the right fit
Assess … projects should investigate these technologies, and track their progress, but they are typically not ready for production use
Hold … you should avoid these technologies on new projects, and consider shifting away from them on existing projects, as appropriate.
Did we get something wrong? Did we miss something? Write a comment on this thread!
We are also looking for /dev/3s and above to be part of the team when we do the next version. Send me a private message if you’re interested in joining for the next iteration.
We should bookmark/link/promote this somewhere, as it gives information that might not be obvious by just searching through the OpenMRS wiki (ie, hold on OpenMRS UI Framework).
i agree with @mogoodrich about bookmarking this ( as we try to make finding information easier on the wiki). this is great work. thanks for doing this. I assume that the plan is to update every quarter? if it is, then we can add to the 1/4 update to the community report.
we should also make sure that the OpenMRS Advisory committee is aware of this somehow… nice…
In particular, this should be highlighted on the standard path that a newbie developer (and implementer for that matter) is likely to take when first coming to OpenMRS:
Actually, doing a quick search, if I go to “wiki.openmrs.org” → “Introduction to OpenMRS” → “Technical Overview” I get a page that, nevermind the UI Framework, basically says we use Spring MVC for our web layer. (Though there is at least a note saying that DWR is being replaced by REST Web Services).
On that note, I don’t see a reference to the (extremely helpful) OpenMRS SDK on these pages either.
Maybe “Rewriting OpenMRS developers guide/technical reference” could be something tackled as part of the OMRS16 Hackathon?
Thanks Darius, this is very interesting and insightful!
I would be keen to correlate this with implementation experience or at least draw some parallels based on distros implemented over the years that have been constructed with combinations of elements from the technology stack - then relate with this tech radar.
i agree about the need to rewrite the developers guide/technical reference.I like the idea of having that at the Hackathon or making a commitment to do that in the new future.
I also am intrigued by the implementation experience guiding the tech radar. Since we are a health informatics initiative, i played with the idea of looking / knowing the clinical functionality ’ need’ that somehow sits within the tech radar evaluation .
Adopt … - what functionality is essential to deliver ( graphing)
Trial …what functionality might assist in improving care quality/safety/ ( pop health at the POC and not generated in a DW)
Assess … what project/ clinical care should be investigated technologically, and track their progress, but they are typically not ready for production use ( VR; in our case, maybe GIS)
Hold … you should avoid these technologies on new projects, and consider shifting away from them on existing projects, as appropriate. ( non API based functionality)
it might be hard to do this, but it would help ensure that the tech decisions are ones that can support the clinical functionality that implementations need
@wanyee, I hope this is correlated with implementation experience, as some of the main contributors have been / are implementers. What do you think the output might look like of what you’re suggesting?
@terry, I like the idea you’re proposing, but I like it more for a separate output/effort, as opposed to trying to dual-purpose this tech radar. We tried to answer the question of how to build, assuming that you already know what to build. And it’s pretty dev-focused so that we can give specific answers to questions like “Angular 1.x vs Angular 2.x vs React?”
I would prefer to see what to build answered in the form of a maturity model showing what EHR functionality we would expect to provide the most impact. It could be very interesting to get a small group to start from an existing maturity model aimed at resource-rich settings, and think about what’s relevant to the resource-poor context.
i like what you are saying… we know that there are existing maturity models for the US and i imagine that there are many in other countries ( though many of the US vendors are represented t/o the globe).
i am not endorsing that model, BUT it does start with a paper chart ( one could surmise that OpenMRS Forms straddle stage 0 and stage 1 with some of the higher stage functionality available) . If anyone is interested in looking at ‘what to build’ to meet the functional needs of LMIC, please let us know. I think that this work could be/should be used to help guide the development path.
