Customer Relationship Management (CRM)
Data Farm
Inc.®
|
The Technical "Know-How"
|
Data Structures - Also Store Objects, Processes and Business Rules
A data structure is a specialized format for organizing and storing data. General data structure
types include the array, the file, the record, the table, the tree, and so on. Any data structure is
designed to organize data to suit a specific purpose so that it can be accessed and worked with in appropriate ways.
Data structure can also store objects, references to methods (C has array of pointers to methods) or
constants. These constants can run through a "switch-case" statement and each case run a number of
object instantiations or method calls.
int [ ] rulesArray = { DELETE_ITEM, ADD_ITEM, ...};
switch(rules)
{
case DELETE_ITEM:
callMethod_A();
callMethod_B();
callMethod_A();
break;
...
}
Our view of data structure is it is the foundation which supports the system architect. It is
very important for an architect to envision the data and processes as they travel through the system and choose
the best data structure which would store data and service the business processes efficiently. Real
world experience is the best teacher when it comes choosing the types of data structure. Another
added bonus is searching the web for the latest comments and suggestions from IT professionals'
experience on of data structure.
Our Business Intelligence (BI) Data Structure:
Our BI Framework is composed of four levels of Java Map:
• Macro Decision - used by CEO
• Micro Decisions - used by business analyst
• Processes - used by architect
• Java Code - used by Java developers
Each level is a map of the processes or components of the level below it. For example, CEO
deletes an item from the company's product list. The following table shows the processes to
complete such task.
Level
|
Command
|
Tasks
|
Macro Decision
(CEO-Decision maker)
|
Delete an item from list of products
|
Using CEO GUE interface (MS word like tool with English like commands), CEO would delete an item from company products and press the run command on the CEO GUE interface.
|
Micro Decisions
(Business Analyst)
|
Analyst would delete item and update products and document the delete request
|
Using Analyst GUE interface, the Analyst translates the CEO decision into a product revision.
|
Processes
(System Architect)
|
Architect creates a revision to deletes the item.
|
Architect comments or deletes the java object and methods from main menu item.
Architect revises system documents and writes code revision for developers.
|
Java Code
(Developers)
|
Developers perform the code revision
|
Developers will back up the system, revise the code and delete item and all database values from database tables and back up the system.
|
With our BI Framework, all the above is automated and the changes in any level may or may
not need any changes in other levels. Each level has a list or a set of maps. Each map is a map
of a list of processes of the level below it. For example, if CEO uses CEO GUE interface, removes
an item and presses the run command on the CEO GUE interface, then the item would be removed
from system and the company web pages will not show such an item. No action is needed by the
lowers levels (business analyst, architect and developers) and processes are automated. The
same is true for code revision or refactoring by developers where there will not be any changes to the above levels.
|
|