Cross-Track-A2 “Ontology for Federation and Integration of Systems” will be 1st of March 2012 -- http://ontolog.cim3.net/cgi-bin/wiki.pl?ConferenceCall_2012_03_01.
Below are my questions for this track.
System Integration, Federation, Interoperability: too many terms with not clear meaning. Different communities of practice use different words and there are difficulties in understanding. Definition of system is not clear, definition of system of systems (federated system?) is not clear twice. Systems engineering have "system integration" process that provides assembling of ready to operate system from pre-implemented parts/modules. What kind process and what system (or system of systems) life cycle we address when speaks about systems/services integration, federation, interoperability?
MW: Let me start with Federation and Interoperability. These I think are easy and reflections of each other. Federation is what you have when you have established interoperability of some systems. Information Systems are interoperable when they can exchange the data that enables them to work together. Federation of some systems is a particular set of systems that are interoperable.
MW: System Integration is a little more difficult because I have known two meanings over the years. In the early days, system integration meant the reengineering of an existing set of systems into a single integrated system. There is probably little mileage in this approach by now, but it may still be happening. Nowadays it seems to me to be being used as what you do to achieve interoperability.
Service-oriented approach suggests pay most of attention not to systems but to services. Should we speak about service integration, federation, interoperability? How integrate, federate and provide interoperability of processes (e.g. workflow traversal through several BPM engines, adaptive case management systems, complex event processors)?
MW: There are a couple of things here. The first is that a service is what something does. It has long been established for systems of any sort that decomposition by function is the most appropriate way to componentize a system. However, this is far from being the most important aspect of SOA. The key concept behind SOA is reuse. This both reduces cost and improves quality of software. So the secret of SOA is reusable components.
What can be terminology, taxonomy, ontology of systems federation, integration, and interoperability? How this ontology can help to build and assess architectures and frameworks for system/services integration, federation, and interoperability? How we can express integration, federation, interoperability architectural patterns (like "bus" or "plug-ins") in such ontology?
MW: I think ontology is essential for SOA, though I do not see much explicit use of it. Terminologies are of course very important for integration, this is the common language that allows systems to talk to each other. Reasoning is usually done by bespoke code rather than general purpose reasoning engines, but can be particularly useful in interfacing systems to a common terminology.
There are ontology frameworks that specifically address integration, federation and interoperability on industry-wide scale (e.g. ISO 15926 that intended to system life cycle data integration). What special properties should have ontologies that serve integration, federation, interoperability purposes in comparison with other kinds of ontologies?
MW: We did quite a lot of work on this before we started (ISO15926). The most important things were:
- The broadest possible context,
- Extensible,
- Enable anything to be said that is valid (i.e. no artificial restrictions),
- Explicit ontological commitments that are followed consistently
- Strong methodology so that the same thing is represented in the same way by different analysts, including,
o Choice of alternative approaches left open by ontological commitments,
o Consistent representation so the same thing would get pretty much the same name from different analysts,
What languages we need for integration, federation, interoperability?
MW: You need a mapping language, which my experience suggests needs to have the equivalent power of First Order Logic.
What lessons we learned in integration, federation and interoperability projects that tried to use ontology-based methodology for achieve its goals?
MW: The most important lessons we learnt were:
- The place where you compromise because you think that will never happen, will happen within 6 months,
- You can start small and grow, A little helps a little, a lot helps a lot.
- Have a quality improvement plan, the larger you get and the more people involved, the harder it is to maintain consistent quality.
Regards
Matthew West
Information Junction
Tel: +44 1489 880185
Mobile: +44 750 3385279
Skype: dr.matthew.west
matthew.west@xxxxxxxxxxxxxxxxxxxxxxxxx
http://www.informationjunction.co.uk/
http://www.matthew-west.org.uk/
This email originates from Information Junction Ltd. Registered in England and Wales No. 6632177.
Registered office: 2 Brookside, Meadow Way, Letchworth Garden City, Hertfordshire, SG6 3JE.