The CA MDB

1. The CA MDB Revised May 16 2006

2. CA MDB: Summary • Primary version based on Ingres 3.0 • Other versions based on MS SQL Server, Oracle • Includes thousands of tables, views, indexes • Built by combining database models from many CA products

3. How do you build an MDB? • Single database instance • Use unique data types • Consistent schemas • Naming conventions • Stored procedures • Design patterns • Unified sets of tables for specific entities/objects

4. Where is the MDB today? • Single database instance • Multiple definitions for some data elements

5. Today (continued) • Mostly consistent schemas • Naming conventions • Stored procedures • One unified set of tables: for assets • eIAM stores applications’ authentication, authorization, access control information • May adopt industry standards (e.g. CIM) when possible • Single set of data owners, permissions

6. Unified model for assets • Set of tables defined by developers for: • ServiceDesk • Unicenter NSM • Argis • Unicenter Asset Management • Entries made by one application visible to all • DB triggers used to update other tables, perform additional operations when assets are added.

7. Revolutionary Change • Applications can access other app’s data directly • Simplifies reporting, analysis across apps • Multiple products can share database server

8. What the current MDB offers • Central Management • Standard Configurations • Standard Patch and Upgrade • A set of best practices for: • Scalability • Fault Tolerance • Securability (firewall and NAT) • MDB Federation

9. What the current MDB offers • Product Specific Federation • Core Bridge • Service Desk multiple MDBs, contact replication, and request broker • Desktop and Server Management hierarchical selective replication (2-tier but n-tier designed)

10. What the current MDB offers • An ERwin physical model-based collection of all tables & columns used by the CA products • A physical model that was assembled by combining DDL from various product teams • A breakdown of tables & columns into Subject Areas that map to the respective CA products • A partial definition of the relationships between the tables that comprise MDB

11. What the current MDB offers • A model that supports basic IP-address based asset reconciliation capabilities • A model that recognizes the central importance of asset and provides some modeling of the complexity of asset • Asset Logical model is documented • Tools used in conjunction with ADT allow asset import using the common object registration API (CORA)

12. Summary • MDB is used in r11 products and value is huge • Most applications co-exist, with selective sharing • Several “best in class” products coordinate use of, and share data – especially for assets and users • Application-specific interfaces, communications are still used • Deployment options generally rich

13. Common Misunderstandings… • MDB’s availability on a specific DB does not mean all applications support that DB • No common method/API for modifying all data in MDB • Not used consistently by all CA products • MDB is not a CMDB

14. Asset Information Scenarios • ServiceDesk and Argis: • As Service Desk is about to enter data about an asset, the user can search through existing assets in the MDB, including those created by Argis. • Users can pick an existing asset and avoid data entry, or the addition of a duplicate entry. • NSM and UAM: • When Discovery runs, every object is registered as an asset.  UAM is triggered by asset registration and can push out an agent to do a full hardware and software inventory. • Trigger provides the “glue” between "continuous discovery" and UAM. • Result: When an incident is recorded in ServiceDesk, SD will check registered assets, even those discovered by NSM, and the inventory info will be available as well.

15. Limitations • No public (client) API for asset definition through the MDB • Definitions may change, or may rely upon undocumented behavior or business logic • Exception: UAPM packages a copy of ADT with CORA integration to add assets • Existing application-specific APIs should be used (for now)

16. Deployment Choices • One product, one MDB instance • Multiple products, one MDB instance • Multiple products, multiple MDB instances

17. Integration • Model level: normalized data • Database level • triggers, stored procedures • Application level • API, scripts • “Bridge” for CORe • Presentation level • Portal, Reporter, F&T

18. Deployment Issues • Ingres issues • Performance – you architect in scalability • MDB issues • May not want information shared between applications; e.g. UAM assets become managed objects in NSM • Legally may be unable to put all data in one MDB • Application issues?

19. Moving Forward – MDB • Distributed installation and access services • Federation services • Abstraction Layers • Connectors • Platform and additional RDBMS Support • “ Hot” upgrade services • Granular DDL definition/extension

20. Moving Forward – MDB • Some Techie Details Under Study: • Reduce data type duplication • Normalize data model • Add common methods across applications for: • Extension of models • Entity addition, updates • Address MDB-specific issues: • Filtering of shared data • Replication vs. application distribution

21. Moving Forward – MDB • More Techie Details Under Study : • A model that supports a central Asset registry to which all physical instances can register Assets • A model that supports a technical solution without a single point of failure • A model that can scale in a predictable manner • A model that supports a central authentication and consistent data authorization facility • A model documented at the entity and attribute level

22. Moving Forward – MDB • Even More Details Under Study : • A model in which non IP-address based assets are accommodated • A model that recognizes and registers assets with satisfactory performance • A model in which critical taxonomies (Owned versus Discovered Asset, Logical versus Physical Asset, Locations, Organizations, Contacts/Users, Services, and Configuration) are normalized