ontolog-forum
[Top] [All Lists]

Re: [ontolog-forum] Architectural considerations in Ontology Development

To: "[ontolog-forum] " <ontolog-forum@xxxxxxxxxxxxxxxx>
From: "Barkmeyer, Edward J" <edward.barkmeyer@xxxxxxxx>
Date: Fri, 22 Feb 2013 13:29:13 -0500
Message-id: <63955B982BF1854C96302E6A5908234417D4F5A025@xxxxxxxxxxxxxxxxxxxxxxxxxx>
John,    (01)

The first problem is to get banks A and B to be able to interoperate as 
independent firms.  They do already use different physical formats for 
transactions, and they have different operations practices.  So the problem is 
to define a common set of concepts and understand the different physical 
formats as different expressions of the common concepts.  Then it is possible 
to translate between them, and OBTW, also the formats used by bank C, with whom 
they both also deal.  To interoperate, there may a need for some additional 
practice or change in practice at the interface between them, but nowhere else.     (02)


When bank A merges with bank B, yes, the AB bank has the problem of merging its 
operational systems and practices.  That is a separate goal from getting 
interoperability between independent banks.  It is further complicated by local 
governmental rules for operations and transfers between financial entities, 
registries of commercial identifiers and active transactions and commitments.  
In the US, the number on your check is preceded by a Federal Reserve District 
id and a bank registry number.  That check will be processed using those labels 
no matter who owns the bank, or what name is on the sign over the bank 
building.  So, the practical concerns in implementing a merger of operations 
are a lot more complicated than having a common ontology, or a merger of 
existing ones.   It is a very different problem from creating interoperability 
for independent systems.    (03)

In manufacturing, the operations of different business units in the same firm 
can be entirely different.   Two plants that make the same, or similar, 
products can have significantly different structures and operations practices, 
sometimes for historical reasons, but often for other reasons related to 
location -- different suppliers, different transportation infrastructure, 
different local regulations, different labor pools, etc.  Imposing a common 
software system on all of them can be a major corporate effort; ask any SAP 
installer.  But some interoperability among the separate systems is needed to 
accomplish meaningful corporate financial reporting, and other interoperability 
conventions may be needed for centralized human resource management or 
procurement management, according to the corporate decisions about these 
things.  So merger doesn't necessarily mean a merger of systems; it all depends 
on business decisions.      (04)

Ontologies are made for a purpose.  If the purpose is to enable 
interoperability of independent systems, that is different from the purpose of 
integrating operational systems and business practices of diverse business 
units.    (05)

-Ed    (06)


> -----Original Message-----
> From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx [mailto:ontolog-forum-
> bounces@xxxxxxxxxxxxxxxx] On Behalf Of John F Sowa
> Sent: Friday, February 22, 2013 12:40 PM
> To: ontolog-forum@xxxxxxxxxxxxxxxx
> Subject: Re: [ontolog-forum] Architectural considerations in Ontology
> Development
> 
> On 2/22/2013 11:42 AM, Mike Bennett wrote:
> > The financial industry has lots of standards for messaging, and some
> > at the level of common logical data models, but the requirements for
> > integration within financial firms has led to an increasing
> > realisation that what's really needed is common semantics...
> 
> Common ontology can certainly be a big help for enabling two firms, A and B,
> to interoperate.  But independently developed systems that use the same
> ontology are likely to have different *physical* formats and different
> *human* conventions for the people who use and operate the computer
> systems.
> 
> If bank A buys bank B, the merged bank continues to run the software and
> databases of bank A and B separately.  Even when they say that they merged
> the two databases, they are really running them as if they were still 
>separate.
> 
> If and when they want to shut down the old programs, they persuade (or
> force) customers from bank B to close the old accounts, open new accounts
> in the formats of A, and transfer the funds from the old accounts to the new
> accounts.
> 
> John
> 
> __________________________________________________________
> _______
> 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
>     (07)

_________________________________________________________________
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    (08)

<Prev in Thread] Current Thread [Next in Thread>