Virtual truth (chapter 2)

by Deborah Volk on April 16th, 2009

In chapter 1 of this ongoing novel, I've written about the basic premise behind virtual directories. This post will cover use cases that we've encountered in the field when working with prospects and customers and Oracle Virtual Directory (OVD) product.

Architectural Buffer (Service-focused). The buzzword-friendly among you may label this example as Agile Infrastructure. You've got an enterprise-wide directory service that you provide to applications. Multiple applications query the directory via LDAP for identity-related information and associated entitlements, a few applications (such as Oracle Identity Manager) create or update the entries in the directory. All such efforts usually start with a single directory, "clean" schema and nice container design - everything is neatly categorized, labeled and stacked (socks in top drawer, shirts in bottom drawer) and lives in its proper place. Over time, as applications demand schema changes, containers multiply and data quality degrades (just like an increase in entropy this is inevitable), the house with a neatly trimmed lawn and a white picket fence starts looking like a soot-blackened dwelling with roaches on the floor. Yikes!

In this case we recommend that you deploy a virtual directory in front of your "real" directory and have all applications that use the service point to virtual directory. This provides an architectural buffer against both the current clients of the service as well as future needs. Perhaps the specter of future requirements (unknown unknowns!) is even more important than straightening out the current mess but you can hit both targets with one shot. If more directories spring up in the enterprise in the future (and they always do), you're protected from impacting the current clients of the service since you can incorporate the new directories into your virtualized service. The entry point for clients remains the same, the underlying directories don't change, only the piece in the middle that directs traffic changes and that's OVD. The extent of the protection depends on how the service is used but the impact will certainly be much more muted with a virtual directory than without it.

Another important benefit of Architectural Buffer is ownership of data. With multiple directories residing in various business units, you don't have to get into potentially ugly political fights for ownership since you're not taking them over, merely providing a view and a path for data flow. That's a lot easier to swallow than "I am moving your data to my central directory. Good-bye!".

A special case of Architectural Buffer is web single sign-on where various SSO components act as clients of the directory service. All web SSO products work with directories, some require them as repositories, some give you an option of storing data in the database or in their own proprietary format. Oracle Access Manager officially supports Oracle Virtual Directory as an option for storing customer (user) data. With web SSO, the virtual directory option is strongly recommended because the scope of web SSO usually expands to encompass different audiences. It starts with internal users, then it might start covering partners, then customers and so on. The identity information and associated entitlements for these distinct audiences are already there, the company has been doing business with these folks after all for many years..but now it wants them in web SSO. You would be lucky if all these records reside in a single place such as an enterprise directory. In reality such luck is rare. Usually the data is spread across multiple sources and only a few of them are directories, the rest are usually databases. Again, a virtual directory will save your life here by allowing the web SSO tool to act on partner and customer identities with little or (ideal case) no change to web SSO infrastructure.
Single View of the Customer. Timely to my note, Mary Knox from Gartner weighed on this very topic in her Customer Data Integration: Think Ideally! Act Pragmatically! Gartner talks about multiple "styles" of customer data integration, primarily in the banking context but I think they apply anywhere: registry, coexistence and transaction with transaction being the ideal state where all data is available in one central store (referred to as "hub" in Customer Data Integration (CDI) parlance). The problem being solved is that of, well, data integration - the data is spread across multiple source systems yet it needs to be available in a single place/view.

Registry style is when the central store contains minimum amount of data necessary for the service to work plus references to where the rest of the data resides; it's up to the application to retrieve the location of additional data from registry, navigate/connect to that location and retrieve additional data. Coexistence style is when the central store has a copy of the record from the source system. Both registry and coexistence require synchronization from the source to the central store; the transaction scenario usually requires bi-directional sync to/from hub and sources, real-time or batched.

CDI is focused on data and directory virtualization is focused on more than data (e.g. protocol translation and routing) but they're kissing cousins. Moreover, a virtual directory is an elegant technology implementation option for either the registry or transaction style. In fact, there's no need to sync anything with a virtual directory - it can present the data in a single, virtualized view without touching the back-end sources. If an application needs to change attribute "partner code", OVD will route the request to the CRM system. If an application needs to change attribute "product SKU", OVD will route the request to the MDM app and so on.

Even though this pattern is titled Single View of the Customer, it's really Single View of the Entity. Customers and Partners are usually entities being focused on but we've seen Products as entities too.
Replace a Directory. Oracle Virtual Directory has a notion of Local Store Adapter (LSA) that allows it to store data in its own database. In other words, not only it can proxy requests to/from sources but it can also serve as a repository for data. Given this capability, why deploy a traditional directory when you can have a directory on steroids (it slices, it dices, ...)
Directory Consolidation. This is somewhere between Architectural Buffer and Single View of the Customer. Count with me: I've got 1 directory, 2 directories, 13 directories...oops that's too many! Directory consolidation doesn't happen just for the sake of it. It is usually driven by either architectural considerations or business context such as achieving a single view of the customer. There's going to be cost savings when you shut off a silo but wrestling with data ownership issues can be costlier so directory consolidation is often talked about but rarely done. Virtual directory offers a way out: keep your data in your own backyard but centralize access.


Posted in Oracle Virtual Directory, Business Perspective, Directory Services, Master Data Management    Tagged with ovd, cdi, gartner, mdm


0 Comments


Leave a Comment
Search

Subscribe

follow on

2012 (1)
2011 (2)
2010 (2)
2009 (64)
March (11)
April (18)
May (18)
June (4)
July (1)
August (1)
September (5)
October (5)
December (1)