Identropy Reviews Cutting Identity Management Operating Costs

Identropy will be hosting a webinar with our friends at IDC entitled "Reducing your IDM Operating Costs Using IDaaS" in a couple of weeks (Tuesday, Feb 14). Nishant from Identropy and Sally Hudson from IDC will be presenting. Hope you can join us! You can read the abstract below, and register here...

Would you like to reduce your IDM Operations costs by 50%, while still proving that the IDM program is meeting its goal?

Is your IT team overburdened with IDM operational support in response to a constant stream of patches and updates that were never budgeted for?

Do they lack the bandwidth to get to strategic new tasks in an ever-evolving, increasingly important IDM program?

Do they lack the time or subject matter expertise to enhance your IDM solution in response to changing organizational needs and business objectives?

If so, this webinar is for you.

The successful deployment of an Identity Management (IDM) infrastructure is only the first step of a continuous journey. Join Identropy and IDC for a webinar on how Identity Management-as-a-Service can help overcome the challenges of successfully and cost-effectively running an IAM program. During this webinar, guest speaker Sally Hudson, Research Director within IDC's Security Products and Services group, will discuss why many of these projects fail and what operational areas need to be accounted for to help bridge the divide between project-go-live and long-term success. Nishant Kaushik, Chief Architect at Identropy, will discuss how their SCUID Operations offering has helped many customers address their operational concerns and yield long-term and increasing value from their IDM investment.

Regarding a Potential Way Forward for SPML

Some of you might have followed the conversation in the blogosphere regarding SPML a few months back. If interested, get up to speed by reading the posts below:

- Mark Diodati, Burton Group: SPML Is On Life Support
- Ingrid Melve, Feide: Provisioning, Will SPML emerge?
- Nishant Kaushik: Oracle: SPML Under The Spotlight Again?
- Jeff Bohren, Identity guru: Whither SPML or Wither SPML?

- Jackson Shaw, Quest: SPML - Not Dead Yet!

Last month, I had the opportunity to join a discussion with some really smart folks regarding the future of the SPML standard at the SPML SIG (Special Interest Group) at the Burton Group in San Diego. Anyhow, Mark Diodati led the session and recently published some of the conversation points discussed at the SIG. Take a look here.

IAM Failures...Product or Services?

Jackson Shaw put up a few interesting posts last week regarding IAM Project Failures. The first was a company that sank $7M into an IAM Initiative that never took off. The second was an informal survey of 9 IAM projects (6 used Sun, 3 used Novell). Jackson concludes:

This was a great illustration to me of how far our little industry segment needs to improve. None of these customers were trying to do anything fancy. They had fancy plans originally but they were failing on basic provisioning or password management and were never able to progress further. It also further reinforced my view that there’s a great opportunity for a solution that doesn’t require a couple of busloads of consultants to get it (and keep it) running. A solution that delivers immediate value. A solution that customers are happy to have. A solution that is my dream

The question that I'd like to pose is, where does the cause of the failure lie? Is it a lack of IAM product capabilities or IAM services?

In my take, IAM products have evolved (and continue to evolve) quite rapidly. Due to my profession, I am present when customers are shown IAM products from vendors and even when they get to test-drive them. Some of the stuff out there now is downright impressive...from visual drag-n-drop workflow capabilities to wizard-like setup of connectors, all in all, the innovation I've seen on the product side is impressive. Furthermore, most IAM project failures that I've seen occur are rarely due to the lack of a product feature.

I think the problem lies in the services side of the IAM house. I suppose that statement is a confession of sorts, since that's the industry I've lived in for the past however long. Anyhow, the IAM services game is anything but impressive. To pull from one of Brad Feld's quotes, IAM services companies typically win deals because 'they suck less' than the next guy. Definitely nothing to be proud of! The services models are pretty much stagnant with limited innovation over the past decade. Every consulting firm has roughly the same implementation model (discovery, design, implement, test, blah blah blah). Replace those words using a thesaurus and you have the next System Integrator's methodology. That's why I believe there needs to be a shift in the IAM services paradigm.

What's your take? What's the culprit? IAM Product or Services?

On Developing a Deprovisioning Policy

An interesting discussion emerged out of a blog entry over at the Identropy blog on developing a Deprovisioning Policy.

I've reproduced both the contents of the blog and the comments section (which is probably more interesting than the article) below. Enjoy!

----

Identity Management technology can be tricky. But in most instances, it's not the technology that trips up an implementation. It's the policy development (or lack thereof) that causes the heartache.

Deprovisioning Policy is typically more complex than a simple policy that states that when HR says a person is terminated, the identity system terminates the user's access to all systems. Here are a few things to consider when developing your Deprovisioning Policy.

1. Deprovisioning Policy (Technical View)

The technical view of a deprovisioning policy is concerned with what the identity system should do once we know that the user should be deprovisioned for each target system.

• Should the user's account be hard deleted or just disabled?
• If disabled, how is that done? (Move the AD account to a disabled users OU, place the row into an archive table, etc.)
• How long should disabled users be kept in the system?
• What should happen to the person's shares, mailbox, etc.?
  

2. Deprovisioning Policy (Business Process View)

The business process view of a deprovisioning policy addresses the states that should trigger a deprovisioning action. Here are a few questions to ask your policy team:

• How do we calculate the actual last day a person should have access? Is there an effective date that can be used? Is HR using that field properly?
  
• How should 'leaves of absence' be handled?
• What should happen if a person wants to use his/her vacation days directly before retirement? What if the person may still provide off-site help during this time period and therefore needs access?
• How should sabbaticals be handled?
• Should a user's current access be terminated in a department transfer? What if they still need their old access for some time?
  
• How should unused sick days be taken into consideration?

3. Take Compliance Policy into Consideration

Besides the business process view of the policy, sometimes existing regulatory compliance rules may have an adverse impact on an otherwise sensible policy. For example, definitions of 'termination', 'employee job role change' and 'leave of absence' will directly impact the overall policy and should be taken into consideration.

By thinking through these issues, an effective Deprovisioning Policy can be put together prior to implementing an IAM solution.

----

Comments:

Hi Ash, my suggestion (as always with IAM related decisions) is to start from the business view and try to stay out from the temptation to start analyzing the event from a technical standpoint.

Using business as starting point can be very helpful for example in fragmented, complex or very dynamic environments where could be very hard to find a common agreement on the right behavior to follow and where, probably, it can give you also a longer-term solution.

What do you think?

Posted @ Tuesday, April 13, 2010 7:10 AM by Luca

Hi Luca,

Interesting point.

From a policy standpoint, both sides (biz process view and tech view) have to be defined. And although the business process view (i.e. defining the states of the user should trigger a decommissioning of the user's access) is critical, the policy would simply be incomplete without the tech view.

From a dependency standpoint, I really don't see that one piece of this is dependent on the other...(although I'm still thinking through it). It's almost as if both sides of the policy can be developed independently.

Thoughts?

Posted @ Tuesday, April 13, 2010 11:13 AM by Ash Motiwala

Ash, for sure both sides (biz process view and tech view) have to be defined. My suggestion is to avoid developing them independently and where possible to start from the business view and requirements and understand how those requirements can be fulfilled from the technical standpoint.

My idea is based on two main assumptions:

1) Technology should support business and so we should start from it and try to define the best suitable tech solution. So, is it possible to keep them independent?

2) Deriving technical view from business view allows to have more stable policies because in my (very very short) experience I’ve saw more stability on the business requirement than that on the technical one. Technical side of policies could be more fragmented, detailed and sometimes system dependent and for this reason more subject to modifications when changes happen in the technical infrastructure (mergers, new systems, etc.). In my opinion, this approach allows to keep unchanged business view and most of the decisions related to the tech view.

Are, in your opinion, my assumptions valid?

Posted @ Wednesday, April 14, 2010 2:47 AM by Luca

Hi Luca,

I'd agree in general that business process development should happen before technical analysis, (as I've mentioned in other articles here).

In order to think through this, I posed myself the following: should the following 2 questions (1 business process oriented, the other technically oriented - as defined in the article) be answered in a specific order?

1. Should a leave of absence translate to termination of access?
2. What should happen to a person's shared folder contents once terminated?

Thinking through this, the 1st question should be posed to the business process owner - whose answer will provide context to the technical owner to answer his part of the question...since a leave of absence (as a state) will probably have a direct impact on how long to hold on to a person's mailbox or shares. And will probably have a different impact on a person who was terminated for cause.

So yes...I agree. Thanks for the insight, Luca!

Posted @ Wednesday, April 14, 2010 5:42 AM by Ash Motiwala

Sorry MIIS, It's Not You, It's Me

Here's some geek humor. A buddy of mine sent me an old email correspondence I had with him back in 2006 (back when ILM, I mean FIM, was MIIS). I was doing my best to get him going on the training path on the product, and this is what he wrote me after doing MIIS dirty:

Now if you'll excuse me I have to go speak to MIIS. I think it's mad at me cuz I haven't touched it for so long (it's starting to feel that I think it's ugly). It's my fault actually, I met someone named Tivoli at a party and we really hit it off. You know when you have that connection instantly? Anyway, since then MIIS and I haven't been speaking much outside of the daily niceties a couple stuck in a rut routinely exchange. Both of us know it's a facade, but we maintain it, almost mockingly, for the sake of the little Management Agents we have running around. To make them Disconnectors now, would be devastating to business continuity.

As a side note, he still doesn't know MIIS/ILM/FIM. "If-you-don't-know-me-by-now..." :)

Series on Developing an Identity Management Roadmap

I've recently been involved in putting together a blog series on developing an Identity Management roadmap. It's a 3 part series over at the Identropy blog. Part 3 is a bit long for my taste, but has a lot of great content I'm sure you'll benefit from if you are involved in identity management strategy development for an organization.

Part 1 is an intro to what an identity management roadmap is, who needs one, who doesn't and why.
Part 2 is about the prerequisites to developing a roadmap.
Part 3 is the meat & potatoes of how to develop one.

We've left some room for input and discussion. Chime in!

Man*ged *dentity Serv*ces, Trademarked!

I received the following email today from our friends at Fischer:

http://identityman.blogspot.com/2009/01/another-entry-into-idm-managed-services.html

Dear Ashraf Motiwala,

We note that one of your recent articles used the phrase "Managed Identity Services" This phrase is a trademark owned by our company and is also the subject of a U.S. trademark application examined and approved by the U.S. Trademark Office. When you use the phrase in your articles, please place the "R" superscript after the trademark, and please make a reference in your articles that "Managed Identity Service®" is a trademark owned by Fischer International Identity, LLC. In addition, you should use the trademark as an adjective, not as a noun. These steps will help us continue to protect our trademark rights and also allow you to properly refer to it in your various articles.

Thank you for your support and proper usage of our trademarks. If you have any questions, please feel free to contact us.

I see. It's all about trademarks (and grammar). For some reason, I thought it was about innovation and making the (identity) world a better place.

Anyhow, I wonder if they are going after Citi, Arcot, Wipro, and IBM. Wait, they barked at my blog...so I also wonder if they also went after Ian Yip, Felix Gaehtgens, Matt Flynn, Nishant Kaushik and Jonathan Penn. Anyone else get an email? or should I feel honored that they are singling me out because of the 6 readers who read my blog?

C'mon Fischer, you guys should really let the trademark go. The term belongs to the industry. Remember, trademarks don't buy marketshare.

Identity Services, SaaS, and Another Matt

Matt Gardiner over at the CA blog makes some interest points regarding identity services and SaaS. (I'm a new reader of Matt's blog, and want to personally thank him for adding yet another Matt to the list of identity bloggers I have to keep up with. What's up with identity bloggers and the name 'Matt' anyhoo?)

Matt questions the value/feasibility of providing identity services in a Software-as-a-Service format, since there's a difference between apps and infrastructure. Infrastructure, he argues, must be "appropriately integrated into the enterprise premises and processes". He continues to argue that identity services in a SaaS format can't ignore on-premise apps in favor of identities in the cloud, and mentions the traditional concerns around "outsourcing" compliance and security.

Ironically, I had an interesting conversation just yesterday with an industry colleague regarding the exact issues mentioned by Matt, where he presented some new emerging paradigms in the 'Identity as a Service' world, including what he dubbed "Enterprise Looking In" and "Enterprise Looking Out" (more on this in future posts). Here are a few questions/direction for the conversation (more questions than direction)...

• Let's nail down the definition of 'identity services'. If not for the industry at large, at least for this conversation at hand. In my opinion, a lot hinges on that.
• Is the notion of 'Identity Services' in a SaaS format an either-or paradigm for on- and off-premise apps?
• Can technology help blur the internal vs. external line? Does this lead to a new category of infrastructure?

Matt does acknowledge that he sees the opportunity for some areas of identity to be outsourced. Perhaps this conversation could help clarify what areas in specific...

On SaaS Provisioning

Jackson Shaw posted some of his thoughts today on enterprise-class SaaS provisioning...

"If you consider an SaaS application as "just another application" you will understand that your end-user identities still must be managed in that SaaS application...We have a standard called "Services Provisioning Markup Language" (SPML) which was specified to help provision identities via a web service. Does your SaaS vendor support that standard? I'll bet they do not! What do you do then? I've met with hundreds of customers over the years and many are still struggling with provisioning inside the enterprise! Throw in SaaS provisioning - via some hairbrained interface because the vendor doesn't support SPML - and it only adds to the organization's identity management complexity."

I have to agree. The real pain point here is the connectivity into SaaS apps, and the lack of standards there. Ian had talked about this in a previous post. Recreating a workflow engine, role management, delegation, etc. in the cloud seems to just create redundancy for these capabilities, especially for organizations that have already dropped a few dollars to deploy an IdM solution on premise. Why would I drop my existing investment here? (Perhaps there is a compelling case, but I just don't see it.) I would much rather find a solution that proxies the SPML requests from my existing provisioning solution that handles all the complexities (or "hairbrained interfaces") for the SaaS apps on the backend! More on this soon...

DIY: Identity Management Project Scoping Exercise

-

Identity Management Project Scoping, Part I

Identity Management Project Scoping, Part II

-

FUD Swings Both Ways

Salesmen are an interesting bunch. They have to drink the company kool-aid to enable them to sell with conviction. But what happens when a salesperson starts to waver in that conviction? What happens when they start losing their religion? Fear-based selling! Easy peasy!

Since I noticed that my last post on FUD based selling and Vendor Selection was being used to spread more FUD (with Oracle being the victim this time), I decided to do my part to rid the world of keep-the-client-ignorant tactics and try to put the facts out there. It's interesting how fear always finds a home ("they're too small!" vs "they're too big!")...anyhow, here goes:

• In a solid article by techtarget, Jonathan Penn points out that customers have no need to panic today, and that Oracle will have the resources to support both product lines for a while, noting that it has continued to support the ERP products of both PeopleSoft and JD Edwards following its 2005 acquisition of PeopleSoft.
  
• Instead of spreading fear, let's spread facts - namely regarding Oracle's track record with acquisitions. Siebel hasn't gone away. Also, Oracle now supports multiple app servers with the BEA acquisition. (Someone else may want to chime in on this since I'm not an expert, but remember: facts over fear!)
• Anectodal evidence: a casual conversation with a VP at a financial firm uncovered that in the past years, Oracle has acquired nearly all of their major systems, effectively turning them into an Oracle shop. The result? Fear and mayhem? Not really. In fact, Oracle offered up a free inventory analysis from Oracle Consulting to guide the client to maximize their existing software investment and determine how they might benefit from updates resulting in tighter integration between systems (although the client stated he would have opted for a deal on maintenance).

That's my $.02, and I hope it moves the conversation away from fear and closer to the facts. And although I know I didn't cover all the facts and I welcome folks to chime in with their side, the point should NOT be boutique vs. large vendor, large vs. small, red vs. twitter blue, but simply the product's capabilities to "scratch your itch", as Dave Kearns put it. Remember this, young salesman: Sell your product, not fear, for FUD is the path to the dark side. FUD leads to anger. Anger leads to hate. Hate leads to suffering.

A Story About Vendor Selection and FUD

The shocking (at least to me) story of Oracle acquiring Sun yesterday made me think about an experience I had helping a client in the vendor selection process late last year.

The client was seeking an identity solution, and with our help, reduced the vendors to Sun, another large vendor and a small boutique vendor. After their demos/POCs, the vendor scoring matrix we helped them put together showed that the boutique vendor actually ended up with the highest score.

After some great FUD work from the sales folk, the client decided to add a new metric in the matrix for Company Viability. All of a sudden, Sun came out on top...and the solution was purchased and implemented. The whole reason the boutique vendor lost out was because of fear and the likeliness of acquisition or failure, etc.

A few months later...Sun is on the block, and finally inks a deal. Now I'm hearing that the client is worried about the direction of the Sun product line post-acquisition, because of the heavy overlap between the Sun and Oracle product lines. (And also worried about what Oracle will do to Sun's open source initiatives.)

Now the smaller vendors are having their say (and they should). Here is an interesting perspective from a Network World article:

"Figuring out what stays, what goes, and integrating the remaining pieces is going to be an enormous task that will undoubtedly create consequences for deployed customers," says Andre Duran, CEO of Ping Identity, which develops identity federation software. "This is yet one more reason companies should consider standards-based, loosely coupled approaches, as it insulates them from the potential for single vendor lock-in, which is occurring irrespective of how they are selecting their vendors."
...
Blakley says as the deal closes, Oracle management likely won't address identity until the more compelling strategies, such as the database, are worked out. "So there will be a period where not much happens and it is business as usual."

Virtual Directory Whitepaper

Oracle just put out an interesting whitepaper on how to use their virtual directory product with Sharepoint. A few interesting scenarios:

• Allow users to authenticate to SharePoint with Windows credentials but control access based on job codes maintained in a HR database (without having to sync!)
• Allow a SharePoint workspace to be used by two different business units who each maintain their own AD domain

On another note...sharepoint has been getting a lot of attention from the identity folks, hasn't it? Microsoft was promising a new "Identity Portal" in ILM 2, until they blew their release date by A YEAR(!!). Courion's been marketing their solution for Sharepoint as well, which is basically an attestation/segregation of duties play. Bitkoo has their fine grained authorization management stuff for Sharepoint.

I wonder why the trend? Hmmm....
Well, here's a billion reasons.

Some Process Re-engineering Principles for Identity Management Projects (part 1)

I'm in the early stages of working with a colleague on a whitepaper on guidelines for business process re-engineering for provisioning projects, and thought I'd share some of our thoughts to see if I could get some feedback. (If we use anyone's feedback, we'll make sure we reference you.)

1. The first point is to put some parameters around the re-engineering effort. The most common mistake that IDM focused re-engineering efforts make is to overdo it. Once a current state process diagram is put together (preferably in BPMN) - many consultants find way too much to optimize, usually because of complaints from the customer. It's important to keep your scope in mind, otherwise the project can quickly turn into a much larger endeavor than you (and the client) had previously anticipated. It's important to focus primary re-engineering efforts on areas that can positively impact identity data. It may be tempting to re-engineer an inefficient interviewing sub-process of the onboarding process, but will most likely not impact your identity data either way. Furthermore, provioning platforms were not created to solve that problem (more on this later). On the other hand, re-engineering a self-registration process to prevent duplicate accounts will have a significant impact on your identity data. The lesson: pick your process re-engineering battles wisely.

Thoughts?

(to be continued...)

Pottery Making, Iterations and Identity Management

I'm a big fan of iterations in identity management implementations. The reason is pretty simple: you can't learn from lessons until you try. (You could learn from consulting firms, but not about your environment.) Which means that you don't get really good at delivering identity management until the 3rd or 4th time. (So take that 9 month project and break it down into smaller 3 month projects!)

Anyhow, here is the pottery making connection. It's a parable a co-worker forwarded to me from Art and Fear:

The ceramics teacher announced on opening day that he was dividing the class into two groups. All those on the left side of the studio, he said, would be graded solely on the quantity of work they produced, all those on the right solely on its quality.

His procedure was simple: on the final day of class he would bring in his bathroom scales and weigh the work of the “quantity” group: fifty pound of pots rated an “A”, forty pounds a “B”, and so on. Those being graded on “quality”, however, needed to produce only one pot—albeit a perfect one—to get an “A”.

Well, came grading time and a curious fact emerged: the works of highest quality were all produced by the group being graded for quantity. It seems that while the “quantity” group was busily churning out piles of work—and learning from their mistakes—the “quality” group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of dead clay.

The lesson: Take on a small, well-defined, low-risk phase 1. Learn lessons. Take on a small, well-defined phase 2. Lather, rinse, repeat.

Nation's First CIO Has IdM Background

President Obama named Vivek Kundra as the nation's first CIO today. An interesting tidbit caught my eye.

Kundra also worked as vice president of marketing for Evincible Software, which provided electronic signatures and identity management for financial services companies and the Defense Department.

Evincible was acquired by Exostar back in 2004. On their site...

In 2004, Exostar acquired Evincible, a leader in PKI and digital signature technologies and best practices. The acquisition brought both proprietary technologies and leading subject matter experts into the Exostar organization, enabling us to deliver technology, policy and best practices leadership in the areas of PKI, federated identity management and physical and logical assess.

It's going to be interesting to see how his background in identity might influence what's happening in the federal IT space, and current initiatives (that seem to be lagging) to federate gov agencies. Hopefully, he takes identity farther than HSPD-12 did.

Where is the Motivation for Deprovisioning?

A series of blog posts on self-service deprovisioning in the federation world got me thinking about a simpler, albeit very real, problem with the "traditional" deprovisioning process in a company.

Most companies that have an IdM system have 2 ways to deprovision users:

1. Emergency Termination Workflow (where a manager logs on to the deprovisioning workflow, and kicks off the termination process that disables accounts across the board)
2. Automated Terminations (where the IdM system keys off of HR or Payroll or some authoritative store that provides the user's status and termination date which in turn automatically disables accounts)

The problem I've seen most companies face is with the second workflow because data is entered in late. So why not put a workflow together for self-service deprovisioning?

The only problem with this approach is the lack of motivation for an end-user to run through the workflow. Perhaps there is an approach to tie the completion of this workflow to some interest for the end user that will motivate him/her to run through it. Some ideas...

• Severence Pay
• COBRA Enrollment
• Continued Communications (to enter in personal e-mail address?)
• An iPhone? (seems to work for other things)

I bet that this approach would solve some of the data-timeliness issues. What do you think?

More on VDS and Cache

Mark Wilcox put up a post responding to my previous queries about the virtues of persistent cache and virtual directories. The bottom line of my post was around performance, so Mark gives some figures for OVD:

The overhead is absolutely minimal - it's generally around 2-5 milliseconds. And worst I've ever seen is around 50 milliseconds (remember that's still only 5/100s of a second). This includes doing a join of data.

Are Symlabs, Radiant Logic and other vendors seeing the same results? Perhaps, a skilled SI may want to chime in? If so, then why does anyone use a persistent cache? Anyone?

Also, Blink Technologies put the following comment on my previous post:

I thought the whole point of the cache is to lighten the load against the system as a whole. It's a compromise of data freshness for performance. Plus the entire point of a cache is to "cache" frequently used data, of course depending on the algorithm used (LRU, MRU, etc.). I also assume that the cache is adjustable and can have specific timeouts for freshness. I think for a highly trafficked directory this is a great trade-off.

Funding Doc Templates From VC = Saving $$$

Brad Feld just posted a set of 5 docs entitled "Model Seed Funding Documents" that I really wished I had a few years ago. (It has a term sheet and subscription agreement!)

Anyone who is going through a seed round should/must go read Brad's blog thoroughly before speaking with attorneys. Educating yourself on your time rather than the attorney's could save you a ton of money. I wish all VCs were this helpful.

Deprovision. We're in a Recession!

Hot off the Canadian Press:

The Canada Revenue Agency has issued at least $3-million in paycheques to people who don't work there, says a new audit.
"Overpayments generally occur when employees leave the agency and through errors or omissions their pay is not stopped on time," says the internal report.

I often hear something like this from identity management workshop participants: "I wonder how much payroll gives away for free because of a broken deprovisioning process."

Me too.

Here's a quick example I saw last week. The daily inactivation report that gets sent out to all admins from HR contains an "entry date" that is weeks, sometimes months, passed the "effective date". How's that for an ROI analysis for your next identity project?

Another Entry into the IdM Managed Services Space

I just read an interesting press release this morning from Watson SCS, an IBM Identity Management SI. They've announced an off-premise managed service offering offering called Identity Management On Demand, bolstering the following:

implementation of a simple Identity Management program can be executed in twelve weeks – about half as long as the quickest deployment of a customized solution.

I have special interest in this area. (Last week, Identropy announced the expansion of its off-premise managed identity services offering (iMIS) by adding support for Novell Identity Manager.) What's interesting about Watson SCS's play is that they're opting to offer a fully managed service, hosted off-site. A few days ago, I was speaking to a colleague at another integrator who recently pulled the plug on their off-site offering, for reasons I've already discussed.

Anyhow, it's great to hear more offerings in this space. It validates what we've been hearing from our clients: Why is this stuff so painful to implement and manage?

Welcome to the party, Watson SCS...looking forward to seeing you out in the field.