John, (01)
No one I know who is seriously addressing ontology enterprise issues
thinks that everyone is going to magically convert overnight. In fact,
we take great pains to let stakeholders and existing customers,
potential customers, and leadership know the issues. There is no free
lunch. So this is a false strawman or spear-jab. It may be useful for
discussion purposes, which I assume is your purpose. So that's fine. In
fact, I invite such a discussion. (02)
For example, if not done right, creating bottom-up Community of
Interest vocabularies and models (ontologies) of those can result in
conceptual stovepipes. What's to prevent an ad hoc, laissez faire
approach from generating lots of redundancy, even if everyone is
developing ontologies and firmly believes in the paradigm: nothing. You
need strong processes and procedures, and organizational understanding,
dedicated responsible organizational units -- at the base level
(individual COIs), at the next level (hierarchic or spanning COIs), at
the middle level (comparable to the middle ontology level; we call this
the Common Core, and there are multiple such), and at the highest level
(comparable to the upper ontology level; we call this Universal Core). (03)
Another example, if an enterprise is embarking on the Service-Oriented
Architecture paradigm, they must be clearly told that this new fangled
ontology/Semantic Web/semantic technology paradigm does not supersede
SOA but in fact extends and enriches it. There are real fears that each
new paradigm in information technology is a fad which overthrows the
previous paradigm. That's not true in this case. (04)
Some of us advocate:
1) Unbundling/decomposing your existing systems over time into
services. This is hard work and will be going on for a LONG time.
2) When new systems/applications are considered, design them as
services, i.e., reusable discrete (as much as possible) components
which can be composed to create new systems/applications.
3) Build services which are described semantically. This description
can be initially a purely natural language description (implicit
model), or an ontology (explicit model). In either case, you will need
grounding in natural language descriptions: that need does not go away
with the development of a logical model (you still need to describe in
natural language what you mean by the logical expression, so humans can
inspect both and gauge conformance of the logical description with the
natural language description).
4) For existing (legacy) systems, you need to plan their evolution
toward your semantic/SOA paradigm. All systems have a maintenance
cycle. Transforming legacy systems to a new paradigm incurs such huge
costs that you cannot typically do that. Instead, you must rely on the
next bullet:
5) Abstracting functional/procedural calls into the legacy system
(assuming you can do so, i.e., if the API is rich enough to support
this; if it isn't and you just call the monolithic system and get its
final results, this effort will not work). Create wrappers for these
calls into the legacy systems. They become rudimentary services. But
most legacy systems are not amenable to this, so you must focus on the
next bullet:
6) For standalone, monolithic legacy systems (which you cannot create
functionally distinct calls into), then you must wrap the whole system,
i.e., treat the whole system as a single service and try to create a
semantic model (ontology) for what that system is doing. The system may
or may not use a distinct database.
A) If it uses a distinct database, you can try to extrapolate a
semantic model (conceptual model, local ontology) from the physical
schema and data dictionary (if there is one). This local conceptual
model/ontology will more easily map into the ontologies you are
developing for the enterprise. Then you must also analyze what
semantics the procedural code of the system provides, a difficult task,
and seek to incorporate that into the emerging semantic model
(ontology).
B) If the system has no database but simply uses internal data
structures, then you must analyze those data structures and the
procedures which use those to determine the actual semantics of the
system which could potentially be at least partially captured in a
declarative semantic model (ontology). This is hard. (05)
So, 1) there are ways to move legacy systems along towards a new
paradigm such as involving the use of explicit semantic models
(ontologies) in an enterprise; 2) but one needs to be very aware of the
potential for creating new legacy systems and guard against such by
creating processes and procedures that govern the constructs of those
new paradigms. This means new governance and policy, sociological
issues. However, these are more important finally then the technical
constructs, because systems and paradigms fail primarily due to people
issues, i.e., on flawed sociology. (06)
Thanks,
Leo (07)
_____________________________________________
Dr. Leo Obrst The MITRE Corporation, Information Semantics
lobrst@xxxxxxxxx Information Discovery & Understanding, Command and
Control Center
Voice: 703-983-6770 7515 Colshire Drive, M/S H305
Fax: 703-983-1379 McLean, VA 22102-7508, USA (08)
-----Original Message-----
From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx
[mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx] On Behalf Of John F.
Sowa
Sent: Saturday, November 17, 2007 3:48 PM
To: [ontolog-forum]
Subject: [ontolog-forum] Legacy systems (09)
Many of the ontology proposals are based on the assumption
that everybody is going to magically convert overnight to
whatever new standard is proposed. (010)
However, there are still legacy software systems running
today that were written over 40 years ago. The only reason
why there aren't many that are older is that computers only
became widely available in the 1960s. (011)
There's an article about the final days of Edison's original
direct-current service in New York City: (012)
http://cityroom.blogs.nytimes.com/2007/11/14/off-goes-the-power-current
-started-by-thomas-edison/
Off Goes the Power Current Started by Thomas Edison (013)
But the shut-down of DC service does not mean that the old
equipment will be shut down. Instead, they're using converters
from AC to DC: (014)
> The last snip of Con Ed's direct current system will take place
> at 10 East 40th Street, near the Mid-Manhattan Library. That
> building, like the thousands of other direct current users
> that have been transitioned over the last several years, now
> has a converter installed on the premises that can take
> alternating electricity from the Con Ed power grid and adapt
> it on premises. (015)
In 1928, they predicted that it would take 45 years to convert
all the DC equipment. But the equipment is still running today,
even though the service has been terminated. (016)
This provides some perspective on interoperability: any new
proposal must be able to accommodate legacy systems, and it
must be designed with the knowledge that the new system will
also become a legacy. (017)
John Sowa (018)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Subscribe/Config:
http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (019)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (020)
|