Achieving true interoperability is hard, but it's both necessary and worthwhile to take the time to form the specifications, requirements, and documentation that outlines the methods and means for integration activities... unless you want to end up like Joe.
2. Once
upon
a
*me
there
was
a
guy
named
Joe.
Joe
had
4
systems
that
worked
together
perfectly;
they
worked
as
1
System
of
Systems.
3. One
day,
Joe
decided
that
he
needed
to
add
a
new
capability
to
his
System
of
Systems,
and
so
Joe
gave
the
components
to
a
system
integrator,
and
with
them,
a
simple
request:
Add
the
new
capability
to
the
exis*ng
SOS.
4. The
system
integra*on
team
tackled
the
task,
and
when
the
effort
was
complete
they
delivered
the
enhanced
SOS
to
Joe.
5. Everything
was
going
well
un*l
Joe
added
another
capability
and
a
few
data
types
to
the
equa*on.
The
result:
interoperability
was
lost.
So
Joe
called
the
system
integrator,
said
a
few
choice
words,
and
asked
if
he
could
fix
it
6. The
System
Integrator
was
confident
he
could
right
the
wrongs.
He
explained
to
Joe
that
there
were
2
ways
he
could
go
about
doing
this.
7. Op*on
1.
Yes,
hire
him
again
and
for
*me
&
$
he
would
make
it
work,
yet
again.
Sort
of.
Sort
of?
The
fix
only
lasts
un*l
Joe
wants
to
make
another
change
to
any
element
of
his
system.
Then
we
do
this
all
over
again.
8. Op*on
2.
Joe
could
go
online
and
search
for
a
magic
ball.
The
magic
ball
would
allow
Joe
to
see
into
the
future
so
he
could
determine
all
of
the
capabili*es
he
would
ever
require!
Then
it
was
just
1
final
integra*on
effort
and
Joe’s
SOS
would
work
forever.
Perfectly.
9. Annoyed
and
confused,
Joe
decided
he
needed
to
think
of
a
new
approach.
Interoperability
apparently
wasn’t
simple.
10. THE
PROBLEM
Achieving
interoperability
is
hard
for
so
many
reasons,
but
integra*on
issues
caused
by
a
lack
of
interoperability
being
built
into
the
system’s
architectural
framework,
as
well
as
the
specifica*on
of
rigorously
defined
standards
outlining
methods
and
means
for
exploi*ng
this,
are
usually
to
blame.