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

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

Build<strong>in</strong>g the Information Model 103<br />

developers have access to the catalog <strong>in</strong> order to create the <strong>SOA</strong> us<strong>in</strong>g cloud<br />

comput<strong>in</strong>g.<br />

Build<strong>in</strong>g the Information Model<br />

Once all the <strong>in</strong>formation about all the data <strong>in</strong> the enterprise is conta<strong>in</strong>ed <strong>in</strong><br />

the data catalog, it is time to focus on the enterprise metadata model, or<br />

what we call the <strong>in</strong>formation model. The difference between the two is sometimes<br />

subtle. It is best to th<strong>in</strong>k of the data catalog as the list of potential solutions<br />

to your architecture problem <strong>and</strong> to th<strong>in</strong>k of the <strong>in</strong>formation model as<br />

the f<strong>in</strong>al data architecture solution (see Figure 5.7).<br />

Let’s review:<br />

Data dictionary: What data exists currently, per system <strong>and</strong>/or application,<br />

<strong>and</strong> the def<strong>in</strong>itions of that data (metadata)<br />

Data catalog: Doma<strong>in</strong>wide, sometimes enterprisewide, data dictionary<br />

Information model: The f<strong>in</strong>al to-be state of the data architecture for our<br />

<strong>SOA</strong> us<strong>in</strong>g cloud comput<strong>in</strong>g <strong>and</strong> the jump<strong>in</strong>g-off po<strong>in</strong>t for figur<strong>in</strong>g out<br />

which data should reside on cloud comput<strong>in</strong>g platforms <strong>and</strong> which<br />

should reside on-premise<br />

The metadata model def<strong>in</strong>es all of the data structures that exist <strong>in</strong> the enterprise<br />

as well as how those data structures will <strong>in</strong>teract with<strong>in</strong> the architecture<br />

solution doma<strong>in</strong>. While you can express your <strong>in</strong>formation model <strong>in</strong> any<br />

number of ways, it is usually best to create a logical model <strong>and</strong> a physical<br />

model. Keep <strong>in</strong> m<strong>in</strong>d that we do not know the target platforms as of yet, so<br />

the models should be technology <strong>and</strong> platform <strong>in</strong>dependent at this po<strong>in</strong>t.<br />

Build Information Model<br />

Information<br />

Model<br />

Figure 5.7 The f<strong>in</strong>al step is to complete the <strong>in</strong>formation model. This is the reference<br />

model used to def<strong>in</strong>e the f<strong>in</strong>al data architecture that provides us with a<br />

jump<strong>in</strong>g-off po<strong>in</strong>t to figure out the data that should rema<strong>in</strong> on-premise or reside<br />

on cloud comput<strong>in</strong>g platforms.

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

Saved successfully!

Ooh no, something went wrong!