Cloud Computing and SOA Convergence in Your Enterprise: A Step ...
Cloud Computing and SOA Convergence in Your Enterprise: A Step ...
Cloud Computing and SOA Convergence in Your Enterprise: A Step ...
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
Importance of Data with <strong>SOA</strong> Us<strong>in</strong>g <strong>Cloud</strong> <strong>Comput<strong>in</strong>g</strong> 105<br />
logical data model for architecture versus traditional database development is<br />
the <strong>in</strong>formation source. While traditional development, generally speak<strong>in</strong>g,<br />
def<strong>in</strong>es new databases based on bus<strong>in</strong>ess requirements, a logical data model<br />
aris<strong>in</strong>g from an architecture project is based on exist<strong>in</strong>g databases.<br />
Physical Model<br />
The myriad of database types <strong>in</strong> any given enterprise m<strong>in</strong>imizes the importance<br />
of the physical enterprise model because with so many database types,<br />
the physical model will rarely be used. The reason is clear: there is simply no<br />
clear way to create a physical model that maps down to object-oriented, multidimensional,<br />
hierarchy, flat files, <strong>and</strong> relational databases all at the same<br />
time. However, if those databases are to be <strong>in</strong>tegrated, some common physical<br />
representation must be selected. Only then can the model be transformed<br />
as required.<br />
Our discussion of the physical model is only for those times when it is<br />
possible to map the logical to the physical—that is, when an enterprise uses a<br />
homogeneous database approach, usually all relational. The <strong>in</strong>put for the<br />
physical model is both the logical model <strong>and</strong> the data catalog. When access<strong>in</strong>g<br />
this <strong>in</strong>formation, consider the data dictionary, bus<strong>in</strong>ess rules, <strong>and</strong> other<br />
user process<strong>in</strong>g requirements.<br />
Importance of Data with <strong>SOA</strong> Us<strong>in</strong>g <strong>Cloud</strong> <strong>Comput<strong>in</strong>g</strong><br />
We beg<strong>in</strong> with the data because it is the foundation for most <strong>in</strong>formation<br />
systems <strong>and</strong> a good way to def<strong>in</strong>e what these systems do before we potentially<br />
relocate them to the clouds. However, the concepts <strong>and</strong> activities presented<br />
<strong>in</strong> this chapter are not at all new; they map back to core architectural activities,<br />
<strong>in</strong>clud<strong>in</strong>g <strong>SOA</strong>. The purpose here is to underst<strong>and</strong> the exist<strong>in</strong>g state of<br />
the data, def<strong>in</strong>e the data at a detailed level, <strong>and</strong> then def<strong>in</strong>e the f<strong>in</strong>al to-be<br />
data architecture that allows us to figure out which data should physically reside<br />
on-premise or on cloud comput<strong>in</strong>g platforms. However, this is all about<br />
do<strong>in</strong>g <strong>SOA</strong> with the new architectural options of cloud comput<strong>in</strong>g.<br />
What is new is that, for our target architecture, some of the <strong>in</strong>formation<br />
systems will not be under our direct control. However, not much more than<br />
that changes. We still need to def<strong>in</strong>e how the data is structured, as well as relationships<br />
between the data, <strong>in</strong>tegrity, security, <strong>and</strong> all th<strong>in</strong>gs <strong>in</strong> between. The