How to be an Infrastructure Evangelist Kim Cameron Architect for Metadirectory and Active Directory...
-
Upload
lewis-quinn -
Category
Documents
-
view
215 -
download
1
Transcript of How to be an Infrastructure Evangelist Kim Cameron Architect for Metadirectory and Active Directory...
How to be an Infrastructure Evangelist
Kim Cameron
Architect for Metadirectory and Active Directory at Microsoft
Internet2 Middleware CAMP
Let’s think about what we do – and how we think about
what we do
(Really secondaryfunctions)
What do we do?
• Communications– Teaching and explaining– Convincing– Writing
• Organization– Cajoling– Herding– Co-ordination– Motivation– Concretization– Lobbying
(Still secondaryfunctions)
What do we do?
• Analysis– Examine technical alternatives– Reject implementation ideas
we know will fail– Search for new ways of doing
things that will work
What do we really do?
• Develop an understanding of what technological possibilities mean to the communities we serve– How they will benefit or be impacted
• Develop an understanding of how these “possibilities” are mutually dependant and relate to time (now, a year, a decade…)
• Learn to see what is technologically inevitable, and what that means…
• Weave these understandings into a vision
Vision always relates to community
• For example, my vision of identity infrastructure– A vision of what Identity means for Microsoft’s
customers (home users, portable devices, small offices, “enterprises”, internet, privacy advocates)
• For example, your vision of what Identity means for the academic community– Students, teachers, researchers, administrators,
privacy advocates
• I think of the community as being comprised of “stakeholders” in the vision
Clarifying vision for stakeholders
• Understand who the stakeholders are• Differentiate scenarios for stakeholder groups• Learn to speak stakeholder languages• Do not limit how stakeholders will use and
benefit from technology – learn from them!• Support stakeholders as they develop an
independent vision• Keep expanding the big picture to include the
newly emerging vision
Using vision as an engine
• Develop language that expresses the vision • Develop concrete prototypes that embody the
vision – but don’t let them “consume the vision”• Our first loyalty must be to the vision, not to
some detail that grows out of control• We have to make sure that stakeholders who
use the vision end up successful • To make the vision real, “Eat the loaf of bread”
slice by slice
Impairment of vision
• Confusing a protocol for a solution– For example, X.400 – or even LDAP
• Ignoring the underlying dynamics – technological inevitability– For example, X.500 and metadirectory
• Refusing to allow reality to speak – For example SMTP versus X.400
Beware of protocol gas!
• Occupational hazard or working too close to a protocol– Similar to effect of radiation on Mme Currie– Symptoms: impairment of hearing when
people tell you about reality, and of vision when people show you what is happening
Just five simple steps!
1. Have a clear vision that represents stakeholders
2. Understand technological inevitability
3. Let reality speak (loudly)
4. Master the art of the possible
5. Be ready to change and adapt
How does this relate to I2M?• The idea of a university community at the scale
of the entire academic world is an incredible concept– I don’t fully “understand” it – deep, man– I am very excited by it– I don’t think everything will happen simultaneously all
at once everywhere – what will happen first?• I think there needs to be a lot of elaboration in
conjunction with stakeholders– Compelling stakeholder scenarios that they buy into
• A lot of technical issues will be clarified– Contrast with Paradise
Where are we with I2M?
• We are still at the beginning – of a long process• We have work to do “on the words”…
– “Middleware” includes you on a good day, but not your stakeholders
• COTS vendors could become stakeholders too, avoiding some of the Paradise syndrome
• If the stakeholders buy in, all the conditions exist for this virtual community to succeed. It will then inevitably drive other federations
Listening to reality
• Monolithic directory will not happen– There will be more and more specialized
“directories” to provide• App-ness (functional differentiation)• Robustness (co-location)• Search-ability
– I foresee unified directory information, but not a simplistic homogeneous infrastructure
• Importance of the metadirectory
Listening to reality
• Convergence of directory and database technology – The whole world is “discovering” identity
issues– The balance is 99 to 1 in favor of application
developers and database people versus “directory” people
– LDAP will persist but new mechanisms will emerge – destabilizing if we are not elastic
• Metadirectory
Listening to reality
• The X.500 / LDAP model does not solve a lot of our problems– Confusion of storage hierarchy and naming– Idea that things are stored (or live) in one
place– Single scope rather than fractal-based– Single hierarchy rather than polyarchy– Simplistic concept of replication– We need elastic mechanisms, and flexibility
Listening to reality
• DSML v2 (and various emerging programming models) may be a lot easier for application developers to use than LDAP was– New standard crosses firewalls, uses XML
and SOAP– Capable of hitting databases that act like
directories
Listening to reality
• UDDI is an example of the relational database locomotive hitting directory head on– LDAP thinkers asleep at the wheel– No schema for advertising taxonomies or
services– UDDI invented as multi-vendor solution based
on separate XML protocol
Conclusion of an introduction
• The important thing is to really deliver on the vision, not getting blindsided by preconceptions. We need– new language– participation of stakeholders– flexibility in evolving our technology to meet
the challenges
Conclusion of an introduction
• Oh yes, and we have a lot of great COTS Software (like Active Directory and MMS) that can be used in helping to build I2M
Conclusion
• Microsoft is very supportive of what you are doing
• We want to learn from you and at the same time help make you successful
• We really salute your work on creating an infrastructure that will make great software more useful and fun to use (and even more fun to build!)