Directories, Databases and DecisionsDirectories, Databases and Decisions

A CTO’s view of Enterprise Management Solutions

A CTO’s view of Enterprise Management Solutions

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

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

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)

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…

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

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

DRAFT

DRAFT