1. Directories, Databases and Decisions A CTO’s view of Enterprise Management Solutions

2. DRAFT The problem Hundreds of Applications, Systems and NOS’s, all with separate management structures 10 new Major applications per year, dozens of smaller apps Time to develop and deploy shows 20% overlap per project for security and entitlement TCO is mostly tied to integration and user MAC’s Complex security relationships are difficult to centralize Ownership of the user is a political hotbutton Big Friggin’ Security Store is costly to build, costly to maintain, and promotes rogue development Cost of real time WAN infrastructure for central security store is cost prohibitive Extending RDBMS design to include all apps is fiction

3. DRAFT What the CTO wants Lowered cost of development for new systems Lowered TCO for individual applications, as well as the combined spend Increased external cust sat levels Increased internal cust sat and cost levels Common methodologies and technologies Easy to integrate, easy to migrate technologies Vendor integrity SHARP Ease of adoption, ease of proliferation, ease of extension Preserves existing investments Definitive TCO and ROI models Vendor skin in the game

4. DRAFT Traditional Ways of approaching the problem Security Bridges (proxy authentication) Client Master Files (batch replication) Authoritative Sources (parsed authorization) Administrative Policy (human rules) Single technology, multiple methods (roll you own security) Hosting (devolving the problem) Delay (put off the problem) Centralized A&A (shared service, central mgmt) Directories (shared service, distributed mgmt)

5. DRAFT How the problem came to be Mainframe based apps shared a common security infrastructure Security was centrally maintained by a distinct group Single interface allowed for common programming and leverage model UNIX maintained this approach using NOS based single security store Then, the dark side… Client server systems were stand alone islands of security NOS based security was limited, and not extensible Shared systems were not scalable Security bridges are not extensible Proliferation of stand alone systems forced decentralization of mgmt. Early web systems mirrored this model, but…

6. DRAFT The promise of Webification Ubiquitous, centralized systems that have rich interfaces w/ great ease of use Simplified programming model, w/ shared services Data stores we “oil fields” or resource, instead of “gold mines” (many wells vs. one shaft) Development of discreet services, instead of applications “Velcro” functionality, instead of distinct releases “Extreme Security” - layered and crypto-ed

7. DRAFT Why we’re not there yet Traditional programming models built web apps like C/S apps A&A schema’s need great extensibility Ubiquitous user store, with rich A&A info is difficult to create Complex relationships for security and entitlement do not span systems Development time and TCO are difficult to show prior to technology decision making “Shared services” mean that “someone has to own them” LOB’s rarely fund shared services CIO’s need to be evangelized Directories are costly up front, RDBMS’s are costly long term “Maximizing a directory’s potential” is still an art, not a common skill

8. DRAFT