This page is part of the OpenTele3 architectural design efforts.
On this page we outline two things:
1) The drawing above illustrates the process so far and outlines proposals for next steps. That is, the green arrows illustrate the process resultning in the initial (and current, Sept. 2015) OpenTele3 design proposal in the form of
This part of the process is described in further detail on the page about OpenTele 3 scope, goal and process.
The orange part of the drawing above is an illustration of how we see the next steps:
It is important that the roadmap is one the one hand flexible and open enough to accommodate exploratory and agile development processes and on the other hand concrete and delimiting enough to function as a frame for planning. Ideally the roadmap should at least cover:
Finally, it is important that the recommendations for overall timing are based in realistic economic frames.
The purpose of the OpenTele3 proposal and the process following it (see above) is not to initiate a “big bang” replacement of existing OpenTele. Rather the proposed principles, strategic focus areas and recommendations on standards are meant to guide a step-by-step process, incrementally implementing and plugging in new services and standard conformant interfaces.
For example, we suggest putting a forwarding gateway or broker in front of the WAN device. The forwarding gateway will enable the support for existing (or legacy) OpenTele interfaces in conjunction with new hData and FHIR based interfaces. The gateway will route messages and data appropriately. That is, some will simply forward directly to the “old” OpenTele servers, some will go via translator services (from new standard conformant format to legacy OpenTele) and yet others will go to completely new microservices, that replace existing OpenTele functionality. In this way, as Application Hosting Devices and other clients are gradually all migrated to hData and FHIR based interfaces legacy OpenTele interfaces can gradually be turned off.