Site Tools


How to Get There

This page is part of the OpenTele3 architectural design efforts.

On this page we outline two things:

  1. A proposal for a process taking us from the proposed to-be architecture to a concrete realisation of a componetised and standardised new platform.
  2. A proposal for step-by-step technical means involved in realising OpenTele3

Process: Next steps and beyond

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

  • Principles and guidelines
  • Key services & components
  • Standards for communication and content

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:

  1. Stakeholders give feedback and proposals for prioritisation.
  2. Feedback, prioritisation and concrete plans are consolidated into a roadmap.
  3. Roadmap realisation is be broken into two parts:
    1. The most concrete parts can go directly to procurement and product realisation
    2. Less concrete parts benefit from cycles of exploratory development feeding into procurements and product development processes.

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:

  1. Identification of OpenTele and surroundings.
  2. Use cases / scenarios and overall requirements (now, in 2 years, in 5 years, …).
  3. Strategic / critical focus areas.
  4. The context of the strategic focus areas (legacy, standards, tech.drivers,…).
  5. Overall options and alternatives within the strategic focus areas.
  6. Recommendations with overall timing / time frames.

OpenTele3 constitutes input for 1 through 5 (together with the existing reports on OpenTele technologies). However:

  • Use cases and scenarios needs clarification, placement in context, and not least consolidation in relation to shared service center.
  • Context of strategic focus areas and the options and alternatives need to be investigated through exploratory development efforts.

Finally, it is important that the recommendations for overall timing are based in realistic economic frames.

Incremental technical process

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.

opentele3/ot3_how_to_get_there.txt · Last modified: 2018/12/12 13:27 (external edit)