Scalability and Semantics

November 19th, 2009

Crawl, Walk, then Run on the Way to Identity and Context Virtualization

After I published my post on identity and context virtualization, Tom Kaczmarek posted an insightful comment in the IAM section on Linked-In—and in doing so, inspired this blogpost (I love the opportunity to riff on these topics, so Thanks, Tom!).

  1. His first question has to do with the scalability. “How does one make this sustainable as the number of local views increases?”
  2. His other issue is more fundamental and has to do with soundness of the approach: “A missing piece in the explanation of this framework is a strong semantic model (of the type AI researchers have developed) to act as the glue to bind the pieces.”

Question 1: Is it scalable?

As always, this is a key question. The whole idea is to build a hugely scalable and distributed infrastructure, which serves as the basis for the integration of multiple data sources (the “contextual” part of the story) linked to a potentially huge number of identities/actors (which can be humans or computers). This is a daunting task and as Tom emphasized, it needs to be sustainable as the number of local views increases.

Now, we know better than to try and invent a whole new philosopher’s stone. As Picasso said, “good artists copy, great artists steal.” So we borrowed a pattern that has proven its worth. In this case, we see this pattern working everyday for us; it’s the same one behind the Internet and DNS. The idea is to allow the local sources to publish their own views of the world and then link and aggregate this information as you go. So a local website exposes itself as an HTML document and then the different links and DNS ties up the whole system, turning it into what is now the Internet.  And in the same way, the virtualization and publication of structured data will enable a progressive integration of all data silos. Will that scale? Absolutely, in the same way that DNS scales.

Of course, the Internet was not born in a day, with a master plan to publish our worldview in a consistent way. Instead, it was built on this idea of providing the tools for a progressive, grassroots level of aggregation and linking of information. DNS is another example of grassroots aggregation/integration of name services based on zone files and a hierarchical structure.

In fact, think of DNS as being like all those hierarchical zone files, distributed around the world and served by multiple machines, but still able to resolve any name like “www.mycrazyworld.net” into an executable IP address. Push DNS one step further and you are transforming a simple name service into an object naming service—aka, a directory—then push it one step past that by linking related objects into sentences, and those sentences into relevant contexts. Now you’re reaching a world where your data silos are turned into a set of human readable contexts and sentences that can be searched using your favorite Google search box (or Bing box, to keep our friends from Redmond happy…).

This is what we mean by “manage globally, act locally.” Delegate the integration task to the owner of the data source—he knows his mess the best!—and let him publish the view of his data that he wants to share. Then provide a flexible layer to integrate those views in whatever way works for you. This uniform approach unlocks the data from its silo, while allowing a highly scalable and distributed architecture.

Question 2: Is it sound?

We just saw that by following a well-established technical pattern, we could publish, aggregate, and scale a huge amount of context and identity information. But scalability and ease of deployment are not guarantees of consistency or soundness. As you know, one of the main challenges when it comes to data integration is the fact that beyond matters of format or protocols, each data silo represents concepts, entities, and relationships differently. You could have homonymy (same words to designate different concepts), synonymy (different words to designate the same concepts), and everything in between.

The first and absolutely necessary step to support a real data service virtualization layer like RadiantOne is the translation of all local models to a “canonical common data model.” In fact, this is what differentiates us from any current “virtual directory” on the market. Unlike our competition, we try hard to understand your data, by creating a model for it. I won’t belabor the point, but you can learn more here. But Tom makes a good point when he says: “A missing piece in the explanation of this framework is a strong semantic model (of the type AI researchers have developed) to act as the glue to bind the pieces.”

In the semantic web space of logic, ontology/descriptive logics, and computational linguistics, there is a whole “conceptual” revolution cooking. Even today, there are wonderful tools in academia and elsewhere, designed to solve the category of problem Tom outlined in his comment: being sure that a new concept in the global model does not contradict your existing world, and being able to infer new consequences of action based on changes recorded in your data sources.

The problem with this semantic world is not the absence of tools, it is the absence of data. If all data was tagged as RDF and defined in Owl, then we’d have no trouble. The problem, of course, is jumpstarting the process. In many ways, the semantic world is in the same state as the original Internet, when academics began using protocols such as FTP, csh, Gopher, etc. to exchange info. Over time, this sea of info started to build up and when HTML and the web browser came along, suddenly the whole Internet was a tool for the rest of us.

 I believe the same things will happen with our structured data, using new tools based on data service virtualization—like RadiantOne!—to unearth the data into readable contexts and sentences. While our transactions take up less than 10% of the volume, they represent at least 90 % of the commercial value. So having searchable, contextual access to this data across silos will be a very big deal, indeed.

But how do we get from here to there? As usual, first we crawl, then we walk, and then we run (or maybe even fly):

  1. Virtualize, so that you can publish and aggregate and reach information in a uniform way
  2. Then turn it into a format (RDF) where you can leverage semantic web  tools, such as ontologies and inference engines, to create and maintain consistency—as I keep saying, don’t reinvent the wheel, steal it.
  3. And finally, converge toward a newer, better, and more consistent system.

That will get you to a good brisk walk. As for running and flying, watch this space for more discussion. ;)

And thanks again, Tom, for your insightful comment. I’d love to discuss these topics with you further. Get in touch with me using the email address on the right.

New VDS Context Edition 5.2 Delivers the Global View

November 11th, 2009

Manage Globally and Act Locally with RadiantOne Identity Virtualization

Big news from the Radiant product team—we’re thrilled to announce the new release of our flagship product. RadiantOne Virtual Directory Server Context Edition 5.2 is a data model-driven solution for complete identity integration and context management. And we’re very excited about what this will mean for enterprises like yours.

New Tools for an Increasingly Complex World

Think for a moment about the challenges you’re facing in your identity environment. Along with tight budgets and increasing demands, you’ve got:

  • New applications to support
  • High-value services to deliver—many beyond the firewall
  • And a whole mess of distributed and heterogeneous data sources

Now, Manage Globally, Act Locally is more than a slogan for us (although we’d have you all wearing Manage Globally, Act Locally t-shirts if we could)—it’s also a better way to deal with all this complexity.

Get the Unified View, with Security at the Source

Our latest release includes the new Global Identifier & Profile (GIP) Builder, a powerful tool that enables you to create a single, unified view of all identities and their profiles, without having to centralize your identity data into a single repository. So your enterprise can manage profiles globally and also act locally by enforcing security as close to the sources of service as possible.

Future-Proof Your Infrastructure

VDS Context Edition is a big leap forward, designed to help you solve today’s toughest identity integration challenges, while building a solid foundation for all tomorrow’s modern architectures, such as user-centric identity, IDaaS, and the cloud. So you’re covered for right now, and ready for whatever comes. 

Explore how this new release will make a difference in your organization:

Oh, and I promise we’ll let you know as soon as there’s a Manage Globally, Act Locally t-shirt available. ;)

Lisa Grady – Product Manager

Earl Perkins: “The Out is Now In”

November 11th, 2009

A Report from Day 1 of the Gartner IAM Summit

I’m attending the Gartner IAM Summit in San Diego this week. It’s always difficult to be inside in a hotel conference facility when the weather outside is 70 degrees and sunny, so the sessions have to be really valuable.

Fortunately, this morning’s keynote from Earl Perkins was particularly good. The session was entitled “The Death of IAM and the Loss of Identity Innocence — A Review of Program Maturity, Services-Driven Change, and New Era Threats.”

Scaling Up to Service-Centric Delivery

According to Earl, “the out is now in,” which means we need to architect and scale the IDM infrastructure not only for employees, but more and more for external constituents.

Earl mentioned that this move to a more service-centric delivery model means that separate architectures for extranet and intranet with IAM are blurring, with extranet-based access, protection, and reporting mechanisms being used to create one consistent, coherent IAM architecture. The scale that IAM is being asked to address is increasingly larger, as well. Where we once spoke of IAM implementations of 5,000, 10,000 and 100,000 users, today, we routinely discuss implementations exceeding one million users. The scale of applications (in type and count) is also increasing.

Bridging the Gap Between Databases and Directories

In fact, one of the key debates that Earl referred to, as enterprises begin to understand the requirements for external constituents, is whether to use a database or a directory. As a vendor of technology that bridges the gap between databases and directory, we’ve been involved in many of these discussions and the conclusion has always been that you need both.

In most enterprises, databases already hold most of the identity data—CRM, orders, billing, and more—that’s required to enable access for external constituents. Databases also provide facilities for transactional integrity and data normalization and are better for updates and reporting. SQL is the preferred protocol for application developers doing CDI (Customer Data Integration) or MDM (Master Data Management).

Directories, on the other hand, provide fast access, more granular security, and enable search without the need to understand the underlying schema. For these reasons, LDAP is the preferred (and often required) protocol for IAM initiatives.

The Convergence of CDI and IAM

These worlds are starting to intersect—and sometimes collide—as CDI/MDM focuses more on improving the partner or customer experience through the web and IAM focuses more on external constituents. In fact, we’re starting to see  the CDI/MDM guys trying to IAM-enable their initiatives, while the identity guys are hard at work making the IAM infrastructure CDI-compatible.

Identity virtualization bridges the gap between these two worlds by enabling you to separate the protocol (LDAP) from the underlying storage, so enterprises can leverage their existing RDBMS investments, which are designed for high-volume storage, and still derive all the speed and security benefits of the directory.

 Looking Ahead: The Out is Now Win

The market is finally beginning to understand that the true value of IdM is not in compliance, but in enabling better interaction with the constituents who drive revenue and profits. This is an exciting time to be in this space and an even more exciting time to be working with technology that enables better identity administration and more effective risk management, and also empowers you to develop new initiatives that:

  • Generate revenue
  • Reduce costs
  • Improve the customer experience
  • Drive cross-sell and up-sell opportunities

The IdM and CDI worlds are beginning to converge, as everyone starts to realize that you can’t have one without the other. Identity virtualization provides that bridge…

- Dieter Schuller, VP Sales & Business Development

Manage Globally. Act Locally.

November 4th, 2009


How identity and context virtualization will change the way we manage identities

My company invented the virtual directory to help take the complexity out of IdM. And now we’ve expanded on that idea to deliver a complete integration solution we call “identity and context virtualization.” I’d like to take the opportunity to explain what it is and why we developed it.

First off, when I say “IdM,” I mean it in its largest sense. While governance, risk, and compliance for internal populations is important, the larger and more rewarding task is helping you integrate high-value, heterogeneous identities for externally-focused initiatives, such as WAM, federation, SaaS, and more.

With that in mind, we’ve all got identities to integrate and new architectures to support.

But right now, the elements of identity are scattered across directories, databases, and applications. Reaching across all these heterogeneous, distributed data silos to aggregate and synchronize identities has proven nearly impossible.

So how do we solve today’s integration challenges and lay the groundwork for tomorrow’s modern architectures, such as user-centric identity, Identity-as-a-service, and the cloud? In short, we need to manage globally and act locally. By this I mean that we need to deliver a global view of identity, while we enforce security at the local level, as close to the sources of services as possible.

And this solution needs to be easily deployed and scalable, since nothing’s getting simpler in the world of identity, things are only growing more complex at every level. 

But how can we fill such a tall order? Well, we begin with the idea that those who do not understand history are doomed to repeat it.

What won’t work: Wait and see vs. tear it down and start over

Some see the gap between the present and the future and urge caution, saying let’s wait and see what happens. Others want to throw away the current identity infrastructure and build something completely new.

But we can’t wait when it comes to staying productive and maintaining a competitive advantage. And we can’t afford to blow up what’s already there and build an entirely new infrastructure—yet another silo—to take us into the future.

Learning from the past to innovate for the present and future

So we took more pragmatic, evolutionary approach, using what we already have to develop an infrastructure with the future built in. To do that, we revisited an old idea—the metadirectory—and a newer idea—the virtual directory as a proxy—and combined the best of both worlds. The result is a solution that solves the identity integration challenges we’re facing now, while building the right foundation for all those potentially rich future applications, such as user-centric identity, IDaas, and the cloud.

Identity and Context Virtualization: The Best of Both Worlds

Rediscovering what’s old: Metadirectory

From the metadirectory, we learned the importance of building a global reference for each identity, through synchronization, correlation of global/local identifiers, and disambiguation (watch a video about identity and context virtualization). We also found tools that let us build a highly scalable solution.

The metadirectory also taught us what not to do: move every instance, every facet of an identity into a single directory. We cannot simply centralize identity to secure today’s distributed environments or enable tomorrow’s new services. For security’s sake, there are some categories of information that you cannot move around, such as primary credentials—especially passwords, the weakest link in the chain. Plus, when you try to centralize everything, putting all logic and all function in one place, you end up paralyzed by the complexity of the task.

Reinventing what’s new: Virtual directory as proxy

The “virtual directory as proxy,” which is Radiant-speak for what the market calls a “virtual directory,” solved this challenge of centralization by calling the underlying systems to check credentials. This lets security happen in the manner appropriate to each data source—by delegating the security checking, you’re “acting locally”—while providing an abstraction layer to shield applications from the complexity of the underlying silos.

But while we know the virtual directory delegates security quite elegantly, we also know that as a proxy alone, it cannot scale as the number of sources and volume of queries begin to rise.  As a consequence, the “virtual directory as proxy” remains confined to niche tactical deployments for a limited number of identities. And that’s unfortunate because the “delegation pattern” is a key requirement in many of today’s high-volume, heterogeneous, mission-critical identity deployments.

Finally, both architectures taught us that the more complete your abstraction, the better. Basically, metadirectory was not “meta” enough and virtual directory as a proxy was not “virtual” enough. The more comprehensive the model of your system, the more flexibility you have—making your infrastructure more adaptable and protecting it from unavoidable change.

Building a better platform: Identity and context virtualization

The key to delivering identity as a service is the ability to abstract identities with their corresponding security contexts, so you can deliver the best services according to your applications’ needs. The way to achieve that is by linking identity and security context through virtualization. Here’s how we do that:

  • Virtualization simplifies the entire process, acting as an abstraction layer between applications and data sources.
  • Global/local reference and disambiguation delivers one version of the truth by correlating identity overlap and building a global map of your identity. (The “manage globally” side of the equation.)
  • Proxy/delegation passes the credentials and password verification to the original source. (The “act locally” part.)
  • Synchronization provides the scalability, performance, and high availability required when data needs to be moved.

It’s not about the storage, it’s about the service…

This changes how directories are viewed. Now it’s not only about  storage, it’s also about delivering a set of services indispensable for the identity stack—and the directory is enabled to offer those services through the magic of virtualization. But this is more than a point solution that does a quick and dirty remapping of attributes and query routing; it’s a sophisticated virtualization that creates a complete model of your system.

Our approach to virtualization is all about flexibility and scalability. By building a single global data model out of all your existing systems, you have the flexibility to create unlimited new views of your existing data as your applications require. And synchronization between the logical layer and the physical layer is auto-generated, giving you a solution that scales, no matter how complex the integration, high the volumes, or heterogeneous the data sources composing the view.

The most critical element is no longer how identities are stored, but how they’re aggregated, synchronized, and disambiguated—in short, integrating identity first, then delivering it as a directory. This becomes a powerful new way to view directories: as a set of services you could package and deliver, using different protocols as needed—LDAP, of course, but also SQL, as well as newer protocols such as web services.

Delivering a global view of identity…and linking its contexts

Identity virtualization allows you to reach an individual user across all silos to enforce security and deliver other integrated services. But once you have a handle on that identity, you can also begin to look at that user’s interactions across silos—the actor and his context.

But that’s a topic for another post…

We’ll explore the context side of identity and context virtualization next time.

SPF for Your Sun Directory Infrastructure

October 27th, 2009

Add Flexibility and Shield Yourself from Uncertainty with Identity Virtualization

It’s easy to see how losing your company phone service or email would bring your business to a standstill. Now imagine losing your directory infrastructure. While the directory’s value might not be as obvious to the average business user, it’s a mission-critical foundation for controlling access, including authentication and authorization. For many enterprises, the Sun Directory platform is an essential component in their ability to conduct daily business.

I talk with customers every day and we all agree: Oracle’s acquisition of Sun is a game changer—and no one knows how things will shake out. Announced last April, the deal is currently under review by European Union anti-trust authorities, so it will be several quarters before Oracle and Sun are able to discuss the future of Sun’s directory and identity offering. Still, it’s important to understand and address the key challenges we’re all facing right now.

What’s my strategic roadmap for the near and long-term?

Many organizations are currently running Sun Directory 5.2, which has an end of life date of November 2010. Product upgrades are costly, time-consuming, and disruptive. An upgrade to Sun Directory Version 6 would be a major investment, coming at a time when Sun will potentially cease to exist as an independent company and the future of its directory—as well as the overall identity management product roadmap—has yet to be defined. The combined company will end up with two of everything, including two directory platforms. History shows that developing go-forward product plans, as well as integrating products, is a long and uncertain process. And with Sun in the process of lay-offs, there is uncertainty about what level of support will be available in the future. 

How will this affect my business relationships and cost structure?

Sun Directory licensing can be quite complex, and all the terms will have to be re-negotiated once Oracle takes over this product. Sun has different license models—annual fee, perpetual license, even a limited use “free” license—and how these will change under new ownership is also up in the air. Companies who license Sun Directory on a per-user basis may also be paying too much, because they have large numbers of inactive users which could be stored outside the directory.

How can I make Sun play well with other infrastructures?

The sale of Sun highlights another identity management issue many enterprises are facing: the difficulty of unifying different directory infrastructures. Along with Sun Directory as a core enterprise identity store, we’ve also seen the rise of Active Directory, which is now a defacto component for most enterprise network and messaging initiatives and the authoritative repository of core identity information for employees. At senior levels within the enterprise, leaders are asking why the identity infrastructure is being complicated by multiple instances of the same data, in some cases maintained by a fragile and complex series of custom-built data and password synchronization processes.

So, given all these questions, how can you protect yourself from the business and technical aspects of unwanted change? Let’s explore how identity and context virtualization can add flexibility to your infrastructure and keep you from getting burned.

Apply Sunscreen: RadiantOne Identity Virtualization

The answer’s pretty simple—and it doesn’t take long to deploy either: Protect yourself with an identity virtualization layer. Sitting between your current Sun Directory infrastructure and the applications that access it, RadiantOne isolates applications from changes to the backend infrastructure. So the application thinks it’s talking to a Sun Directory, while behind the scenes, you have the flexibility to make changes as needed.  This simple yet powerful layer protects you from market dynamics outside your control, and also upgrades your directory and identity infrastructure to meet future requirements, including federation, fine-grained entitlements, SaaS, cloud computing, and multi-tenant services.

Provide flexibility in your infrastructure

Shield your applications from potential changes to your directory infrastructure in the immediate term, and position yourself to create an informed strategy once the new product roadmaps are announced. RadiantOne is a vendor-, product-, and version-agnostic infrastructure that protects your identity investments and enables quick deployment of new initiatives. Whether you decide to upgrade to Sun 6 or change your directory infrastructure instead, a virtual directory buys you time to decide and ensures that applications will feel minimal impact from any changes you make on the backend.

Cut deployment and licensing costs

Directory virtualization allows you to use any directory or data source to store your identity data. Many organizations use RadiantOne to bridge the gaps between the database and directory worlds, enabling the separation of protocol (LDAP) from underlying storage, where RDBMs often makes the most sense. Such a move could significantly cut deployment costs by allowing you to leverage your existing RDBMS investments and still derive all of the directory benefits. Many enterprises have also reduced licensing costs with this strategy by simply moving inactive users into a database, while still allowing applications to access a single directory with both active and inactive users.

Unify your identity infrastructures

Take better advantage of your AD investments: Use RadiantOne to gain a unified view into all your directories—one that’s cost-effective, non-intrusive, and easy to deploy. RadiantOne solves the challenges of authentication and authorization across disparate user directories by remapping certain aspects of your current directory infrastructure back to AD, without impact to existing applications.

RadiantOne: Highly flexible, plays well with everyone

For many enterprises, directory virtualization is a fast, cost-effective solution that provides protection and flexibility for the identity infrastructure—not to mention independence from some of the vendor dynamics discussed above. While this classical use case is still a strong driver, more and more organizations are turning to RadiantOne virtualization to find new ways to consolidate identity information and leverage existing IdM investments for new initiatives.

Identity organizations are enlarging their focus beyond GRC initiatives for internal populations, targeting higher-value externally focused initiatives that deliver new and better services to customers. But these high-volume, highly heterogeneous environments put new demands on your identity infrastructure.

RadiantOne bridges the gaps between the database and directory worlds, separating the protocol (LDAP) from the underlying storage. So customers can leverage their existing RDBMS investments, which are designed for high-volume storage, and still derive all the speed and security benefits of the directory. This makes RadiantOne a strategic infrastructure solution that supports current identity needs and scales up to meet tomorrow’s challenges.

I’d love to discuss how RadiantOne can make a difference to your organization. Send me an email at dschuller@radiantlogic.com, and tell me about your goals and challenges.

- Dieter Schuller, VP Sales & Business Development

The Eternal Sunshine of the Relational Model…

March 31st, 2009

I cannot count the number of times customers or prospects have asked us to remap a relational database structure into a directory, or vice versa. So keeping a separate, different database structure for directories is and has been a very expensive operation for most companies.

So let’s take a look at why we need to have a separate database structure, and how we could reduce the pain of synchronization.

Now, in my previous post, I asked why we need directories in the first place. But I’d like to refine that question a little further:

  1. Do we need a hierarchical structure like a directory? (I’ll be discussing this question in future blog posts, so stay tuned!)
  2. And the issue behind today’s post: do we need a separate, different kind of database to support such a structure? (After all, didn’t we all learn that relational theory is the alpha and the omega, back in Database 101 class?)

Let’s face it, relational databases are:

  • The workhorse of most enterprise applications.
  • Well understood, well supported, and transaction-enabled.
  • Currently optimized for updates.
  • Potentially able to answer to all kind of queries.

So why not implement a directory using a relational model on top of standard SQL engine and avoid the complexity of having to synchronize two very different data models?

Two Possible Directions, Two Big Dilemmas

If we build a directory using relational best practices, we’ll end up with a model that is “standard” and well understood and well integrated with other SQL applications. So far, so good, right? In terms of design, we will likely end up either with a recursive relation, or a static number of joins for a predefined depth of our tree. The problem is that the result of our queries would be atrociously slowno matter how you slice it, multiple joins or recursive queries are very expensive with mainstream SQL implementations. So this approach won’t work because a directory needs fast lookup/queries.

Or we could bypass best practices and build a “hard-coded” hierarchical structure model that just runs on top of a SQL database. In fact, some vendors took this approach (IBM and Oracle, I believe) and it works well.  But the approach is so specific that we’re basically building a hierarchical databasea separate hierarchical structure using SQL as an access method!  This gives us excellent results in term of speed.  But now we’re back to square one: we have 2 different database structures, two different models, and the same old problem of synchronization, This approach buys us speed but creates exactly the impedance headache that our DBA wanted to avoid.

(In fact, If we’re foregoing the relational model, why not just bypass SQL altogether and use the core access method engine (ISAM/B*trees) to win some extra speed, which is how the majority of LDAP implementations have been done?)

The Best of Both Worlds: Caching In…

So on one side we have a highly scalable system that’s optimized for transaction and updates, making it ideal for storing the data from our directory, which could deliver all the queries we need, but not at the right speed, because the multiple joins of a recursive call kills our real time/online performance. But what if we virtualize and cache the result of all queries beforehand, and update this cache incrementally in real time as new entries are created?

That would give us the best of both worlds: the infinite flexibility and scalability of the relational model, and the speed of a directory.  On top of that, we also get the rich context that a hierarchical structure, such as a directory, can carry, while benefitting from a well-established, well understood entity relationship model.  So when we write, update, or insert, we’re working in the classic SQL model with transactions our application loves and understands. And when we query, we get the speed of a directory, because the cache is the directory.

One final thing, since all the data from an existing application could now be virtualized as a set of context trees, an interesting thing happens: We inverse the relationship of the directory with the rest of the infrastructure.  The directory no longer sits in splendid isolation; instead, it’s fed by a grass roots effort of “publishing” which could be consumed by the community. (Sounds a little like the web, right?)

But I’m getting ahead of myself here…let’s dive into this in my next post, when I will cover hierarchy, directory, and context.

Oh, and cache, of course. I’m a big fan of persistent cache. ;)

- Michel Prompt, Founder & CEO

From Static Directories to Context Servers

March 6th, 2009

Bonjour, and welcome to the Radiant Logic blog!

My team and I will use this as a place to share ideas with you on directory virtualization, data services abstraction, and other topics, with a particular emphasis on identity and context. Now, you may have heard me talk about context before. You may have even thought to yourself, “context, context, it’s always context with this guy Michel.”

So what does digital identity have to do with context? And what does context have to do with directory virtualization? Well, if you’ll bear with me for a little detour through the world of directories, I think it will all begin to come into focus.

Directories: Plateau, Legacy…and Renaissance?

After a period of high excitement and fast adoption, directories (by that I mean essentially LDAP directories or their equivalent) have reached a plateau phase. Technically, there’s not much happening and to some extent they’re now legacy. At least, that’s what conventional wisdom would have you believe.

In fact, it’s the issues facing the current directories (and the whole data service layer, really)—things like difficult integrations and lack of flexibility—that have driven the trend toward virtualization. I’d compare it to the evolution of OS virtualization. In the beginning, IBM virtualization on mainframe and then VMware and other virtualization layers, was just about abstracting the low level hardware/devices, so that one legacy operating system would coexist with another. As progress was made, better understanding of this virtualization layer brought about the current craze of server abstraction and the move toward “elastic” and cloud computing.

Linking Identity and Context

I believe that data services virtualization, particularly directory virtualization, will provide another layer of abstraction, a key service that enables a common representation of not only objects, but also their relationships. Not only objects as isolated nouns, but objects forming sentences, organized in relevant context describing the business processes, the myriad of contexts buried in our applications and data silos. The impact in terms of security and identity management would be immediate, but I believe the scope could be a lot larger. It’s about linking identities with the vital context surrounding them.

This is a big topic, and one I’ll be developing here over more posts. I’ll also be considering other questions relevant to the future of identity, security, and data integration, such as:

  • Why do we need directories in the first place?
  • What can we still learn from the directories, or any supposedly “outmoded” hierarchical structure (XML, XML databases, file system, etc…)? Why do we keeping reinventing them!?
  • What is the role of data service virtualization, and why it is a lot larger than the current narrow definition of a virtual directory? Why do we need a context layer, a service that could be a key requirement for an efficient smart, and secure service-oriented architecture?  
  • And of course, we’ll have to address the usual suspects: speed, scalability, flexibility, and security.

Thanks for reading, and please feel free to join the conversation.

- Michel Prompt, Founder & CEO