09.02.2015 Views

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 ...

SHOW MORE
SHOW LESS

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

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!