The best way to architect your distributed system while driving down integration costs is to design your system of systems around one key property: inherent interoperability. But your design approach must embrace legacy systems. After all, you almost never start with a clean sheet of paper.
Achieving interoperability is challenging for many reasons. Mainly, it's poorly understood and specified, and current design and architecture approaches never take the single most important thing into consideration: the data. Architecting your data is arguably more important than architecting your applications if you want your distributed system of systems to meet the requirement for semantic interoperability. Once you understand the movement and definition of data in a system, you can tackle almost any integration problem.
This webinar covers how to begin to analyze and understand interoperability. It also lays the groundwork for data modeling that ultimately helps architect and design your systems for inherent interoperability.
Webinar link: http://event.on24.com/r.htm?e=590196&s=1&k=43CAE462F938702FDA5DE6E059333D7F&partnerref=rti
10. The process of linking together different computing systems and software
applications physically or functionally, to act as a coordinated whole.
Integration
12. Integratability is the ability for some combination of systems to come
together and form, coordinate, or blend into a functioning or unified
whole.
Integratability
13. The setup of components and methods to make two or more systems
work together as a combined system.
Interoperation
16. A system of systems is a collection of task-oriented or dedicated systems
that pool their resources and capabilities together to create a new, more
complex system which offers more functionality and performance than
simply the sum of the constituent systems.
System of Systems
17. Interoperability is the ability for systems, units, or forces to provide
services to and accept services from other systems, units, or forces, and
to use the services so exchanged to enable them to operate effectively
together.
Interoperability
19. Technical Interoperability
доброе
утро
• Requires おはよ
– Communications う
Infrastructure established
• Result
– Bits & Bytes are exchanged
in an unambiguous manner
• Non-Functional Need Met
– Replaceability
Interchangeability
20. Syntactic Interoperability
What was her
temperature?
• Requires
– Communications
Infrastructure established 37.2
– Common structure or
common data format for
exchanging information Get the
• Result warming
blankets.
– Bits/Bytes and the
Structure of Data are
exchanged in an
unambiguous manner
• Non-Functional Need Met
– Interchangeability and
Integratability
21. Semantic Interoperability
The apple is
orange and
• Required yellow.
– Communications What does that
Infrastructure and Common
Data Format are established have to do with
her surgery?
– Common information model
is defined for exchanging the Oh! I
meaning of information thought we
• Result were talking
– Bits/Bytes and the structure about food.
of data are exchanged in an She didn’t
unambiguous manner need
– Content of the information surgery.
exchanged is unambiguously
defined
• Non-Functional Need Met
– Actual, high-level
Interoperability
23. A model is anything used in any way to represent something else
Model
24. A data model is a representation that describes the data about the things
that exist in your domain
Data Model
25. Systems of Systems are Different
[n]sets of
requirements +
many things to
the requirement
express
for Semantic
Interoperability
many different
representations of
[n] types of
those expressions
systems
System to achieve
interoperability
of
Systems
26. The SOS Data Model Shall…
1. Meet the requirements of all of the constituent systems
2. Support the overarching requirement for Semantic
Interoperability
3. Allow for changes to be made to the model without requiring
changes to the existing system and application interfaces that use
it
1. 2. 3.
Formal Rigorous
Formal Process
Language Documentation
We Need A Formal Approach!
27. Formal Language for Data Modeling
• Similar to
structured,
rigorous Transformation
Rules
programming
Formation
languages Alphabet
Rules
• Ambiguity is not
acceptable Formal
Language
– Syntax
– Semantics
28. Semantics, Ambiguity, and Language
Natural Language
Representation Formal Language Representation
• A pair of shoes that Claire Pc = $1500...
wants costs 1500 dollars. ì $1500 ´ 1+ 0.0825
( )
ï
ï
$1, 623.75
She waits until the shoes go Pc = í or = or
on sale. She can spend 450 ï $1500 $1, 500.00
ï
î
dollars, including 8.25% tax.
t = tbuy when P £ $450
On Monday, the shoe store
ì
discounts everything by ï
$811.88
50%. Each day an item is not @t = 1, P = í Pc ´ (1- 0.5) = or
ï $750.00
sold, it is discounted î
another 25%. How soon can ì
ï
Claire buy her shoes? @t ³ 2, P = í é Pc ´ (1- 0.5)ù ´ é( t -1) ´ 0.75ù = ...
ë û ë û
ï
î
29. Documentation Methodology
• Documenting only your
messages is insufficient
• Documentation doesn’t
end at the data model
– Your system
– Key decisions
– Context
30. Formal Process
• Mandates are
insufficient with so
many stakeholders
• Can’t dictate everything, Elements
must accommodate Atomic Elements of
many things Meaning
• SOS DM needs to
enforce rigorous well
defined processes, not
mandate messages
31. Putting the Pieces Together
Data Modeling Process
Structure
Things to
Model from Behavior Data Model
System A
Context
representation
A
representation
A
per a representation
Rigorous and Formal [n]
Approach
32. Data Centric Integration Solution
• Technical
Interoperability
Legacy System A New System B – Infrastructure &
Protocol
Mediation Mediation
• Syntactic
Interoperability
– Common Data
Structure
Mediation
• Semantic
Interoperability
– Common Data
Future System C
Definition