ThoughtWorks has just released a new edition of the Tech Radar. You should read the whole thing, but I always like to highlight a few things here that I think have particular relevance to OpenMRS…
I mentioned this with the last tech radar also, but the Backend For Frontends pattern really intrigues me. In particular, I know that various groups have run into trouble trying to use our REST API on mobiles because it’s too chatty. Per this pattern, I think groups in that situation should experiment with writing their own REST APIs that are tuned to the needs of the specific application.
On the JavaScript side, there’s support for several things that @raff, @pascal, and I have already been saying, like ES6, webpack and NPM for all the things.
It’s worth noting that real-life ThoughtWorks teams have landed on preferring React.js as the default choice, followed by Ember.js, and they sound “a note of caution” about AngularJS, though it’s still a “solid framework”. This doesn’t change my opinion about what OpenMRS should do at present (i.e. we should stick with AngularJS 1.x because of the existing investment in it on the part of some big OpenMRS community members like Bahmni, AMPATH, and PIH, and the usage of it in the reference application.) But I’d love to see someone do an OpenMRS app with React or Ember. Or to try adding Redux to our existing Angular 1.x approach.
Who knows, maybe by the time we’re really ready to move on from AngularJS, those will have been eclipsed by Aurelia. 
Spring Boot gets a strong vote. We should look at this, or to one of its constituent technologies, as a way to run on an embedded tomcat/jetty, as a potential replacement for both our WAR and standalone distributions. (The Hold on Application Servers still remains.)
Several radar blips remind me that we really are not following best devops practices. (Infrastructure team, I’m not at all blaming you for this; we’re just severely under-resourced, and also hamstrung by the length of time it takes to spin up a machine.) Anyway, when we get the time we should really make all of our devtest, int, qa, and UAT into Phoenix environments. And the advice to Avoid a single CI instance for all teams seems pretty interesting, e.g. as @raff is starting to organize a series of sprints with a backbone of developers in Poland, while @teleivo and @judy are harnessing work around radiology that can almost count as its own team.
I fear what we might find if we add the OWASP dependency check maven plugin to our build pipeline. But we should do this!
I recently watched a Spring webinar (not from the tech radar) about documenting REST APIs that was very anti-Swagger. So I was interested to see the radar comments on RAML (RESTful API modeling language). (In practice, OpenMRS does not have a true HATEOAS REST API at all, but just a CRUD API, so many of the complaints about swagger don’t really apply to what we’re doing.)
