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

Case Study: Defining the Data for Blue Mountain Hammocks 99
There is not a set format or rules around what a data dictionary should consist
of. A quick and dirty listing of the data is just fine. We just need to provide a
base understanding of all the existing data to move to the next step in cataloging
the data.
The data catalog for this problem domain is the combination of all the data
dictionaries into one common place, using one common approach and format.
This the first step in abstracting the data structures from their physical instances
into a common listing of data assets that we will use to determine our “to-be” database
solution, including any use of cloud computing resources that may a fit once
we are through this process. The data catalog (very much simplified) for our BMH
problem domain may look like Table 5.1.
This is just a raw listing of the data elements found in all of the data dictionaries,
in this case three. However, you need to add some additional information, including
Description
Ownership
Security parameters
Integrity parameters
Dependencies
Again, there are no set rules for what should be contained in a data catalog,
so you can create a data catalog that best meets your requirements.
Moving on to the information model, it is a good idea to identify the common
entities in this problem domain. In our BMH example, we have
1. Customer
2. Sales
3. Products
That simple. It is also good to define the relationships, such as Customer buys
Products, which creates Sales.
Again, not complex.
So, the to-be or target information model that we consider when building our
SOA using cloud computing could be as follows:
Customer
Customer_Number
Customer_Name
Company_Name
Customer_Address
Customer_State
Customer_Zip