ESSO/Context and Healthcare, In the Trenches (Part 3)

From my last post, I promised a post to go a bit deeper on the technical side. Instead of reinventing the wheel, there are a few docs that could provide a good starting point. I think Gartner's report provides a decent high level technical overview of the products out there, although the vendor analysis seemed a bit superficial. The most notable area from the report is the "Architectural Differences" section.

The following is a terse explanation of how it works:

ESSO tools serve as a proxy between client devices and target systems. Target systems still maintain independent credential stores and will present their own unique, sign-on prompts to users' client devices. ESSO tools provide various mechanisms to sense sign-on, password and password change prompts for different target systems. Automated sign-on logic can fail when sign-on or password update prompts change with new releases of target applications or operating systems (OSs).

Two-tiered architectures will require schema modifications in AD (or whichever repository is being utilized), although it gets to leverage the benefits of your directory services infrastructure, like redundancy, fault-tolerance and performance. N-tiered approaches require a separate set of ESSO boxes (midtier architectural components) - i.e. more stuff to maintain, and vendors in this world tend to battle on how many concurrent users their boxes could handle (Don't confuse the number of users on a box, with the number of concurrent connections the box could handle. Sales folk love to muddle those two). On the other, this approach may prove useful if your directory infrastructure leaves something to be desired, or if your data is dispersed in more than one repository. In that case, a synchronization strategy is pretty typical from the various data repositories to the internal ESSO repository. Although I have yet to see it, I would love to see an ESSO/Virtual Directory model here. On paper, this seems like an elegant solution, allowing (for example) physician data to remain in eDirectory, employee data in AD, and the ESSO solution pointing to the Virtual Directory that intelligently routes requests based on user type. At least this would not mangle things with a metadirectory, though I'm not about to get into the whole 'metadirectory is dead/almost dead' debate.

Instead of going into depth on every ESSO feature, I've decided to put together a list of technical areas that are important differentiators. Each vendor may have a different approach in dealing with the situations described below. Anyhow, these questions are a good place to start:

* What directories does the ESSO solution support - in terms of storing ESSO data?
* How are username changes managed? For example, someone changes their last name, and their username changes...how does the ESSO system manage that?
* Every healthcare institution has a pretty involved Citrix environment. How will it deal with physicians accessing applications externally through a portal? Will it still provide the appropriate ESSO experience? Does the solution support authentication by generic accounts using virtual channel?
* Most healthcare institutions have areas with shared workstations, in which generic accounts are used for authentication. How does the ESSO solution deal with that? What about multiple session private desktops?
* How does the vendor support remote users (i.e. users connecting via VPN)? How does it support for a user connecting via VPN from a non-domain controlled PC?
* Does the solution support fast user switching?
* How easy is it to integrate new applications? Is the point and click wizard really that easy to use? (In a POC, make sure your techies get hands-on. An expert can make it look easy, so don't be fooled.)

On another note, if you are looking for a detailed analysis of the vendor offerings, at over 400 pages - the KLAS report on ESSO and Context Management is quite a comprehensive paper (Sorry, I can't seem to find the link right now), and definitely better than Gartner's magic quadrant report from a vendor analysis perspective.

Up next...a bit on Context Management.

ESSO/Context and Healthcare, in the Trenches (Part 2)

In my last post, I focused on the first lesson: In-House Homework first, Hold Back the Vendors. In this post I'll go on to speak about the importance of executive sponsorship as well as the application inventory.

Executive Sponsorship

I think a ton has been written about this so I won't go into detail. I'll give two live examples. The first example was from a client that was seeking a Provisioning solution. We spent significant time with the right folks, or at least we thought they were the right folks. According to titles and apparent job function, we had an executive sponsor on board for the project. We identified a solid road map, the right resources on both sides of the fence, everything seemed dapper. At the last moment (and I mean legal approved contracts, pens were drawn), the CIO pulled the plug on the project by simply stating, 'I don't like this solution.' Everyone was baffled.
Example number two has a more positive ending. This time, the correct executive sponsor in place. The organization is going through a massive re-org, and it seems that the project will continue running smoothly. The project hasn't completed yet, but so far, so good.

A lesson learned:

Lesson 2: Validate 'Executiveness'

Just because a sponsor seems like he or she has leverage, it's important to understand the dynamics of the relationships in the organization. Each company is different with vastly different cultures. Does the sponsor's superior respect his or her decisions? Does the person have a track record of pushing projects forward?


Application Inventory

On to application Inventory. What is an application inventory and why is it important? I have yet to meet a Healthcare organization that has less than 50 apps. The last one I've dealth with has 1400+! That means that for clients who wish to ESSO/Context enable their environment, we need to identify which applications exist in their infrastructure, how important they are for ESSO/Context Management enablement, the technical difficulty to enable the application, etc. This information will help provide relevant context for the usage of the applications and which applications to focus on first.

Here is a list of things to document regarding each application:

1. General info on the app: name, version, app owner, number of users, app function, etc.
2. Application type: client/server, web, terminal emulator, java, etc.
3. Does the client seek to SSO and/or Context enable this app?
4. What is the driver for enablement? security reasons? audit trail?
5. Ranking importance level for enablement. I.e., how badly does the client want to enable this app vs. other apps?
6. What are the processes around this app? (Login Screen(s), Login Success Screen(s), Login Failure Screen(s) - Note Different Screens based on User Role (Physician, Nurse, Admin, Staff, etc.))
7. Is the application CCOW enabled ?
8. Application Credentials - Does this application have it's own credentials repository or share one with other applications? Application Credential Submission - Does this application use auto submit? (Some applications require users to select printers-ESSO can not auto submit.)
9. Is Change Password functionality supported by the application ? (If Yes, does the application have a configurable expiration timer? What are the valid characters? Do you want to automate Change Password and Auto Generate Passwords?)
10. What is the Business Process of the application Change Password Feature Change Password Screen(s), Change Password Success Screen(s), Change Password Failure Screen(s) - Note Different Screens based on User Role (Physcian, Nurse, Admin, Staff, etc.)
    

This should give you and your team a good handling on your existing application infrastructure vis-a-vis ESSO. In my next post, I'm planning on taking a step back and talk a little about the technologies.

ESSO and Healthcare, in the Trenches (Part 1)

I've been involved in the early stages of a fairly large ESSO project as of late. Since it's been a while since I've been involved hands-on with a project, I've decided to write a short series regarding my experiences. The goal is to impart some practical lessons that a PM could use the next time they decide to undertake an Enterprise Single-Sign On project, with special emphasis on healthcare.

I love working with healthcare institutions. There's always hundreds of apps to support, disparate teams with fragmented goals, and pushy users with lots of power (clinicians). Sarcasm aside, its always interesting given the unique landscape.

Lesson 1: In-House Homework first, Hold Back the Vendors

The client had been embarking on this project for nearly two years. Out of the gate, they called every vendor under the sun to see which products fit their needs. The problem was that they didn't clearly identify their needs up front. The good news is that the client was smart enough to recognize their mistake. They put the vendor calls on hold (indefinitely), and decided to do some in-house homework. The client identified that improving the clinician's experience was their primary driver, which helped a ton with the steps to come (as I'll demonstrate in future posts). They followed this up with the following very intelligent steps:

* They garnered some serious executive sponsorship
* They completed a thorough application inventory


In my next post, I'll dive a little deeper into the two points above. Anyhow, this experience rang loud, especially in light of the recent storm of articles on KPMG's Identity & Access Management Survey findings (here, here and here):

"More than two thirds (68 per cent) of executives surveyed for KPMG’s 2008 European Identity & Access Management (IAM) Survey believe the effectiveness of projects is hampered because they put too much focus on technology and fail to address the organisational and procedural changes that are required. As a result, only a handful, (11 per cent) are fully satisfied with the outcome of their IAM projects."

Ouch...SIs better do something and quick. (I'm sure that KPMG has nothing to gain from that!)