Cloud Computing and SOA Convergence in Your Enterprise: A Step ...

90 Chapter 5 Working from Your Data to the Clouds
You Can Skip Ontologies
While using ontologies is very helpful when dealing with complex problem domains
with complex data, the use of ontologies as an approach to generalizing
and understanding data within a problem domain is optional. Many architects
delve right into the data analysis, skipping ontologies, and that is perfectly
okay. We present ontologies here as an approach to analyzing data that can
prove to be very productive.
Using ontologies as a starting point makes the more detailed analysis
that much easier to deal with because we have already defined the general
categories. From there, we can work down to the details of the metadata. We
want to define the information within our problem domain more holistically
before defining it in more detail. Ontological analysis clears the ground for
generalization, making the properties of the entities much clearer. Ontological
analysis for SOA using cloud computing encourages generalization.
One of the benefits of leveraging ontologies is that no matter where the
information resides, we can understand and map information relevant to our
SOA using cloud computing. Ontologies allow us to differentiate between resources,
which is especially useful when those resources have redundant data
(e.g., customer information in almost all enterprises). By making better sense
of the data and representing the data in a meaningful way, terms defined in
ontologies allow the architect to fully understand the meaning and context of
the information.
An important notion of ontologies is entity correspondence. Ontologies
that are leveraged in more of a distributed environment, such as business-tobusiness
or cloud computing, must leverage data that is scattered across very
different information systems and information that resides in many separate
domains. Ontologies, in this scenario, provide a great deal of value because
we can join information together, such as product information mapped to
on-time delivery history, mapped to customer complaints and compliments.
This establishes entity correspondence between data that is physically distributed,
such as on-premise or within clouds.
To gather information specific to an entity, we need to leverage different
resources to identify individual entities, which vary widely from each physical
information store. For example, when leveraging a relational database,
entities are identified using keys (e.g., customer numbers). Within the vari-