Introduction defining context and scope
So, what is a Reference Model (RM)? A good place to start is with this Wikipedia article on reference models. Its opening paragraph explains an RM as “an abstract framework consisting of an interlinked set of clearly defined concepts produced by an expert or body of experts in order to encourage clear communication. A reference model can represent the component parts of any consistent idea, from business functions to system components, … …”. It goes on to say that an RM can “… then be used to communicate ideas clearly among members of the same community”. This then, is the essence of an RM. It’s a descriptive conceptual framework, establishing a common language of communication and understanding, about elements of a system and their significant relationships, within a community of interest. That’s particularly important when, as in the environmental research infrastructures (RI) sector that community of interest brings together significant numbers of experts from vastly different scientific and technical backgrounds to talk about building distributed ICT infrastructures.
The present topic is concerned principally with the ENVRI Reference Model and is closely related to the topic of the Linking model, which depends upon it. However, reference models are cutting across all aspects of infrastructure design and technology review. Thus, this topic relates to all the topics of the technology review.
Change history and amendment procedure
The review of this topic will be organised by in consultation with the following volunteers: Type @ followed by first letters of person's name. They will partition the exploration and gathering of information and collaborate on the analysis and formulation of the initial report. Record details of the major steps in the change history table below.For further details of the complete procedure see item 4 on the Getting Started page.
Note: Do not record editorial / typographical changes. Only record significant changes of content.
| Date | Name | Institution | Nature of the information added / changed |
|---|---|---|---|
| 22 Dec 2015 | CU | Introduction, context, scope established. Sub-headings inserted | |
| 8 Feb 2016 | CU | More detail added; particularly on positioning the role of RMs in architectural design of research infrastructures |
Sources of information used
Places you have gone to for information e.g., RDA; standards bodies; GEOSS; existing RIs and projects and the technologies they use; technologies available from service providers (0.5 pages).
Two-to-five year analysis
Of state of the art and trends based on sources and experience. A distillation of surveyed information leading to your conclusions and recommendations about what should be done in ENVRIplus (0.5 - 1.5 pages) structured internally as appropriate for the topic but with at least the following headings.
State of the art
The ENVRI Reference Model (RM) is presently a work in progress. Version 1.1 was published in summer 2013 as a deliverable of the ENVRI project. It was based on the requirements collected from 6 research infrastructures. In the ENVRIplus project there is a task 5.2 to review and improve the RM, based on new requirements analysis of 20 research infrastructures.
Use of RMs in other sectors
RMs have been used widely in the telecoms and defence sectors, as well as among architects of enterprise and public sector systems. All these sectors are characterised by their need for "infrastructure at scale”. They involve multiple vendors who have to work, if not together then to a common framework of principles and concepts to bring about widespread interoperability. It’s easy to make a phone call to more or less anywhere on the planet, or to receive streaming video there. That is the result of using reference models and standardising interfaces between sub-systems and components from different vendors.
One view of reference models, particularly expressed by practitioners at Armstrong Process Group (APG) is that they are a supporting capability in the Enterprise Architecture value chain. Putting that into ENVRI context is to say that RMs have relevance and use for understanding and analysing the environmental science enterprise prior to and as part of planning and implementing (engineering) research infrastructures.
During 2013 the ESFRI cluster projects covering the biomedical sciences (BioMedBridges), physics (CRISP), social science and humanities (DASISH), and environmental sciences (ENVRI) came together to identify common challenges in data management, sharing and integration across scientific disciplines [doi:10.5281/zenodo.7636]. Reference models were identified as a common interest of all the clusters. Subsequently, RMs were ranked as one of the top three issues needing to be addressed jointly across all RIs at the European level.
UML40DP and tooling for software engineering
Recently revised, UML4ODP [ISO/IEC 19793:2015] allows systems architects to express their systems architecture designs in a graphical and standard manner using UML notation. This is exciting because it means, for example that the ENVRI RM and all its concepts can be built into software engineering IDEs with all that implies for inheritance, conformance, etc. This makes it possible for industry-standard systems design tools, such as Sparx Systems' Enterprise Architect or IBM Rational Software Architect to deal with ODP based designs and thus to inherit concepts from an RM once that RM is encoded as a UML4ODP representation.
Problems to be overcome
Adoption
In the research infrastructures sector we have to move to a RM oriented approach for three reasons. Firstly, so that we can achieve interoperability within and between different infrastructures. Secondly, because there are multiple players and stakeholders in the sector that have to work together and talk to one another. And thirdly, so that the sector can achieve the economies of scale within and across infrastructures that we need for attracting the attention of industry. There is a role for bespoke design and development due to the unique attributes of individual infrastructures but wherever possible, off-the-shelf capabilities should be adopted first. We can do this more easily when we have a commonly accepted conceptual foundation upon which to base procurement. Achieving a shift in culture and mindset of the community is a significant issue to be overcome.
Complexity
RMs are a systems modelling way of thinking that draws together all the conceptual elements and relations in a large class of very complex distributed systems. Systems thinking gives us a means to cope with that complexity. It helps us to better deal with change in the (scientific) business, leading to more agile styles of thinking and response. Understanding relationships between the various parts of a research infrastructure helps us to understand the possible collective (emergent) behaviours of the infrastructure and to practically engineer and manage real systems. Thus (and according to APG) a reference model is really a framework from which a portfolio of services can be derived.
Complexity can be off-putting. This Forbes article on Enterprise Architecture offers several suggestions that are transferable to the present context. You don't have to take reference models too literally. You don't have to "do" all of the RM to benefit from it. Just pick and choose what works for you. It's basically a toolkit. You can use it in several different ways - to baseline what you already have and to clean up; to target desired outcomes and plan out to achieve them; or in combination to deal with a troublesome area (pain point) - first by baselining it, then by targeting it and then iterating until the pain has gone away.
Tooling and skills development
Effective software engineering depends on having robust and capable Integrated Development Environment (IDE) within which all the processes of software design, implementation and test can take place. As noted above, industry-standard design tools are beginning to support the necessary concepts but their penetration and use in research infrastructures sector is still quite low. The level of architecting skills to be found among practitioners in research infrastructures is also quite low.
Sketch of a longer-term horizon
Notes: Possible trends to consider:
In general terms, the "digital transformation agenda" (encompassing cloud infrastructure, continuous delivery of IT services, DevOps, agile software development, etc.) acts as a significant driver.
Bots, Services, APIs and Apps - this is a catch-all for the general trend in consumer computing towards a world of smart applications, interacting with services (both bot and human) via a range of APIs. Knowing all the APIs, where they are and how they relate to one another in terms of compatibility and composition potential will be a crucial development to watch as it spills over from mainstream consumer computing into enterprise and academic/research sectors. To what extent do current RMs overtly accomodate this trend? One possible argument is that it's just engineering and that all the logical stuff is already provided for.
Agile architectures
Relationships with requirements and use cases
Link your analysis of the topic with particular identified requirements and use cases, as this will increase the relevance and help others understand your insights. Consider using tables to do this (0.5 - 1 page).
Summary of analysis highlighting implications and issues
This section should be suitable for the deliverable and also understandable on its own, without the need to read the rest of the material. A discussion of areas where ENVRIplus should change its plans as a result of your conclusions, and of open questions would be very useful here (0.25 - 0.5 pages)
Bibliography and references to sources
ENVRI Reference Model http://envri.eu/rm
ISO/IEC 10746-1:1998 Information technology -- Open Distributed Processing -- Reference model: Overview.
ISO/IEC 10746-2:2009 Information technology -- Open distributed processing -- Reference model: Foundations.
ISO/IEC 10746-3:2009 Information technology -- Open distributed processing -- Reference model: Architecture.
ISO/IEC 10746-4:1998 Information technology -- Open Distributed Processing -- Reference Model: Architectural semantics.
ISO/IEC 19793:2015 Information technology -- Open Distributed Processing -- Use of UML for ODP system specifications.
ISO/IEC 19793:2015