|
On 9/21/13 2:29 PM, David Eddy wrote:
Kingsley -
On Sep 21, 2013, at 1:43 PM, Kingsley Idehen wrote:
I thought I was explicit in
stating that a major challenge of legacy systems is
NOT the data, but the systems themselves... COBOL,
JCL, CICS, DB2, IMS, DELTA, EasyTrieve, etc.
There are tools in the form of data access drivers that
provide access to data associated with all the above.
These drivers enable access via SQL i.e., the middleware
maps the underlying data to the RDBMS model.
Please read what I'm trying to say.
So far I say "system" & you say "data"... I'm NOT
talking about the data a system processes.
One of the layers of complexity that must be addressed in
legacy portfolios is NOT the data stored in flat files or any
sort of DBMS, it is the systems themselves. The software that
contains the business logic that processes the data.
Yes, I am very aware of that. I separate Apps (what orchestrates
state transistions) and Data (what has state). As per the mail I
just sent, a view into the Data doesn't affect the Apps and Services
that *systematically* orchestrate state transitions.
There is a tremendous amount of "business logic" buried in
the software, as opposed to the data the software processes.
Yes, and in some cases those processes have SOA (via SOAP) and in
some cases REST-ful interactions wrapped around them. Be it SOAP or
REST-ful interactions, you end up with structured data
representation constrained by a schema, vocabulary, or full blown
ontology.
The big Semantic Web narrative mistake (in the early days) was the
conflation of semantics and formats i.e., if you expressed your
model using XML that wasn't RDF/XML many assumed it means no
semantics. Thus, the semantics expressed in many XML Schemas
associated with SOAP re., SOA were discarded in a utterly useless
turf war.
There is also a tremendous amount of obsolete junk buried
in the systems. Figuring out which is which non trivial.
Non trivial but doable, progressively.
Is there something that you do not grok about the different
between "system" & "data?"
I am sure (or at least hope) you know me better than that :-)
They are two different things. The machine tools (the
systems) processes the raw materials (data) into finished
goods (data).
This entire exercise is absolutely NOT nicely confined to
RDBMS engines.
I didn't say it was. I am saying that DBMS engines (including RDBMS
variants) are part of the deal re. the critical decoupling of
applications (systems) and data.
I think I've already said that I met one fellow who
matter-of-factly commented that his organization has some 28
DBMS engines in use. I could only count to 17.
Fine, but how does that change anything re., the fundamental issue
of structured representation of data (be it the data in a DBMS, the
data in messages re. state transitions orchestrated by apps and
services) ?
Kingsley
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: 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 join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
--
Regards,
Kingsley Idehen
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen
|
smime.p7s
Description: S/MIME Cryptographic Signature
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: 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 join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J (01)
|