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