Am I Cut Out for a Startup?

I just read a great post by Paul Graham of Y Combinator entitled: "Why to Not Not Start a Startup" that i found through Phil Windley's blog. Y Combinator does real modest seed funding for entrepreneurs (usually less than 20k). Paul says:

So I'm going to list all the components of people's reluctance to start startups, and explain which are real. Then would-be founders can use this as a checklist to examine their own feelings.

He also gives feedback from their first investments back in the summer of 05. Out of 8, 4 were successful - and all that in under 2 years! Not bad.

Burton Group TIps Off IBM Scientist About Microsoft AD Patent Violation

I was taken back by an article I read today about a former IBM scientist, William Reid, who claims that he created the "technology" behind Active Directory, and that he owns the patent behind it.

OK...so what's the next logical step for Mr. Reid?!

Of course...sue Haliburton! And not for the obvious reasons Haliburton should be sued...but because their Identity Management system is based on it. Pretty interesting logic there, Bill! Using that logic, you could sue almost every company out there...go sue GM and Charles Schwab while you're at it. Too late...he already did.

The most bizarre aspect of the story, is that he got the 'tip' from Catalyst!

In an interview, Reid, who says he worked on artificial intelligence for IBM from 2000 to 2002, says he determined that GM, Schwab, and Halliburton were violating his patent after visiting a trade show. Reid says he watched presentations by IT officials from the companies while attending the Burton Group's Catalyst conference.

There's nothing quite like a disgruntled, clueless IBM scientist. (No offense to the happy IBM scientsts out there.)

Oracle's Donation

Earlier this month, Oracle announced that it would hand over the Identity Governance Framework (IGF) to Liberty Alliance. IGF is an interesting framework that is composed of CARML, AAPML, an API and an identity attribute service. This is the very high level of what I understand...

CARML (client attribute req. markup language) is an xml style doc that a developer would write that lets others know about the 'data needs' of their app, for example, my app needs attibutes A, B and C. (A good usage of carml doc is for identity services, which can tell apps what info it could give them)
AAPML (attribute authority policy markup language) on the other hand is a doc that goes with the data sources. These data sources can define how place constraints on how its data is to be used. Its a profile of XACML 2.0, and can be used by a policy enforcement point (pep) to do its job, (although it has an added feature of requiring the pep to check if user consent has been obtained).
IGF also comes with specs for an client api.

What was really cool is the industry's appreciation of Oracle's move:

"We're very pleased to see that Oracle has submitted the Identity Governance Framework to the Liberty Alliance," said Don Bowen, director of Identity Integration for Sun Microsystems, Inc. "Sun believes Liberty is well suited because of its business and technical experts from all verticals, including government. Its work in the area of data privacy is not only valuable, but essential."
— Sun Microsystems, Inc., Don Bowen, director of Identity Integration

"Novell welcomes Oracle's contribution to the Liberty Alliance. We continue to look forward to working with Oracle and the other leaders in the identity management market in the development of an open identity framework."
— Novell, Inc., Nikols, vice president, Product Management Identity and Security

"CA is supporting the Identity Governance Framework to help customers more easily protect personal data across their disparate systems and applications," said Andy Rappaport, Architect, Identity and Access Management at CA. "We look forward to working with the Liberty Alliance, Oracle and others to develop practical, adaptable XML-based specifications that simplify the creation, enforcement and management of identity security policies."
— CA, Andy Rappaport, Architect, Identity and Access

It's great when everyone can play nice.

The Effects of Drugs on Spiderwebs

On Justifications

"We fly 30 million people a year. Ten thousand were affected by this."

- David Neeleman, CEO of JetBlue

On Innovation

“Innovation is trying to figure out a way to do something better than it’s ever been done before."

-David Neeleman, founder and CEO of JetBlue

I'm a sucker for VCRs

T-Mobile AMEO, please come to America.

Advice for IT Startup Founders

Dharmesh Shah from Onstartups.com has some advice for IT Startups. I've pasted them below for your reading pleasure:


17 Pithy Insights For Startup Founders

1. Seek transparency and understanding with your partners early. Issues get harder as time passes

2. Startup founders work long hours for a reason. There’s more work than there are people. If you’re seeking balance, seek it elsewhere.

3. Bad customers will drain you of passion. Really bad customers will drain you of both passion and profits. Unfortunately, most bad customers will degenerate into really bad customers if you don’t do something about it.

4. If you’re changing direction often, worry a little. If you’re changing people often, worry a lot.

5. It’s lonely at the top, but even lonelier at the bottom. In the early days of a startup, hardly anyone wants to talk to you (except some desperate vendors).

6. Eventually, your product will need to work and do something useful. No amount of marketing or strategy will get you around this.

7. At the end of each day, ask yourself: “Did the product get better for customers today?”. If you don’t have a good answer, stay up until you do.

8. Until you are profitable, time is working against you. Once you are profitable, time is on your side.

9. Learn to take calculated risks. The market rarely rewards safe bets.

10. To improve the quality of your output, improve the quality if your inputs. Read, converse and connect with the right people.

11. Force yourself to write, as it will force you to think.

12. At least once every year or so, your startup will almost die.

13. The problem you solve should be ugly. The solution you build should be beautiful.

14. Even the most successful startup ideas had 100 reasons not to pursue them. There is no perfect idea.

15. If the pain doesn’t kill you, it just hurts a lot.

16. You choose your destiny, because you choose your team.

17. Be who you are. Do what you love. Join people you like.
    

Learn OpenID in 5 minutes!

Simon Willison has posted this screencast with a demonstration of how OpenID works. Nicely done. I wish there were one for Infocards. Then I could write a blog entry called "Learn Infocards in 5 minutes!" Kim? Is there already one?

What's this Role Management stuff about?

I read a press release today about a Role Management company called Vaau. Vaau first caught my attention back in March, when Gartner identified them as a "cool vendor". I'm sure the company name helped out, but the main reason for the honor seems to be the ability of their product RBACx to perform attestation at the user level rather than the role level (which seems like an obvious must-have for a role management product, although some "role management" vendors might disagree). Anyhow, today's press release was regarding a strategic partnership they struck with Sun. Seeing that there are more than a few vendors joining this space, I'd like write a few entries about the field, typical product features, general philosophies/approaches to role management, sushi and some of the vendors (off the top of my head, Eurekify, Bridgestream, Vaau, Courion, BHold, etc.).

The first place to start is what role management is all about. Using the latest technical jargon, a role is a grouping of things that need privileges to do stuff to other things. So it follows that role management is the management of what I just said. The main driver is usually all about access management, hence the term RBAC (role based access control). The idea is that its easier to manage roles as opposed to individual privileges. (Of course, compliance is a driver as well.) Sometimes that doesn't work out as planned. It's not unheard of for clients to complain that they ended up with more roles than people in their organization - which sort of defeats the purpose, especially if your role memberships are only people.
So the next post: typical product features in a role management app.

Become Rich: Use a Business Model!

I found this excellent blog yesterday by Alex Osterwalder. For those of you who are clueless (like me) - start here: What is a Business Model?
And find out why its important.
Then work your way to the Business Model Template.
Then use it to make very own.
Now the last and final step. Execute.

Why Use Cases Should Matter in Identity Deployments

In a comment to a previous blog entry, where I attempt to make the case for Use Cases in Identity Management integration efforts, James McGovern comments:

"First, many folks in the IDM space don't really understand how to create use-cases because it is not a traditional business-oriented scenario.

Second, the importance of getting a PM has to be not on internal nor external but someone who has walked the path before. This is pretty difficult to find even amongst the vendors themselves."

Focusing on his first point, I'd have to agree: use cases really come from the software engineering world (I believe originated from one of the three amigos - Jacobson). Wikipedia has a terse description of what a Use Case is:

In software engineering, a use case is a technique for capturing the potential requirements of a new system or software change. Each use case provides one or more scenarios that convey how the system should interact with the end user or another system to achieve a specific business goal. Use cases typically avoid technical jargon, preferring instead the language of the end user or domain expert. Use cases are often co-authored by software developers and end users.

In my opinion, the software engineering world has a lot to offer the identity integration world. Software engineers (and I use that term broadly) typically have a lot more interaction with business users than back-end integration folks. Figuring out how to efficiently produce software that the client wants/needs has been at the center of decades of discussions surrounding dev processes and methodologies. The integration community on the other hand are usually less focused on customer satisfaction, and more about making processes work efficiently and reliably. With the advent of identity integrations, the level of interaction with business development users has increased significantly. Many steps within the process of integrating an identity platform necessitates interaction with business users, such as mapping business processes and ultimately optimizing them (and the various touch points end users will have with it - for example in provisioning workflow), as well as user interaction with password management systems, esso, etc. I do agree that some components of an Identity platform may be invisible to the user, but typically the user will have at least indirect contact with it. (For example, in a metadirectory solution, a self-help name change in an HR data repository might result in a displayname change in their e-mail address or the name that appears on a phone handset.)

Identity integrators usually come over from sysadmin-type backgrounds, and (even those who have done an identity implementation or two) might not have the disciplines a software engineer would have in delivering a solution that the client is pleased with. (Even worse, many PMs for Identity projects that I've met don't seem to have much PM experience to begin with, or might be a sysadmin who successfully ran an exchange upgrade.) The result is what Mark Dixon described as the seven deadly risks, outlined below:

* Poor Pre-Project Preparation
* Poor Requirements Definition
* Large Initial Scope
* Inexperienced Resources
* Poor Project Methodology
* Scope Creep
* Not Using Available Support


The solution might lie in borrowing software engineering processes that would be helpful in initial preparation and scoping of an identity project, as well as ensuring that an iterative process results in happy business users.

To be continued...

Jackson Shaw is Blogging

Jackson Shaw from Quest is blogging. Jackson previously worked for Microsoft where he was Product Manager (I believe) of MIIS. Since then, he joined Vintela which was acquired by Quest. Quest now has its own portfolio of Identity products, ranging from the cool SSO stuff Vintela was doing between Unix and Windows, as well password management, audit tools (including what they call 'cross platform identity auditing' - which sounds really important), and provisioning.

Jackson's blog is self-described below:

Jackson's comments, commiserations, confabulations and simplifications on identity management and Microsoft's Active Directory all based on his continous "reality tour" of meetings with customers, ISVs and Microsoft.

Ok...so what does commiseration mean?

Definitions of commiseration on the Web:

a feeling of sympathy and sorrow for the misfortunes of others; "the blind are too often objects of pity"

condolence: an expression of sympathy with another's grief; "they sent their condolences"

Got it. Regardless, I think Jackson will have some pretty insightful blog entries regarding the identity topic. Go check him out here.

Sun on Identity for Healthcare and the Cost Problem

Health IT World has published an interview by John Russel called Sun’s Healthcare Mantra: Reduce Cost and Complexity with Sun Director of Healthcare and Life Sciences, Joerg Schwarz. He weighs in on Identity and provides a few interesting scenarios for federation:

Some RHIOs [regional health information organizations] follow the central model. Some follow the federated model. I chose a centralized model, which naturally creates a lot of animosity by privacy advocates, by patients, by people who are just afraid of having all the data concentrated in one place and I don't want to say who's right or wrong, but these are the two fundamental models. You centralize everything and use that as a model, or do you have a federated model where you keep the data where it is. You just have to make sure that when you need it you can save it to the aggregate it together.

When asked which model was better...

...identity management because data protection to control who accesses information through the entire lifecycle. The best way to do this is building a federated identity management concept so that a doctor that is known and authenticated with one institution can request data from another institution where he is unknown, but that gives him doctor level credentials to access information involving a patient.

Early in the interview, he explains that although most hospitals today have digital records, they are not linked, and primary care physicians typically don't have access to them. It seems that linking hospitals has a strong business case, and its just a matter of time before that gets into full swing...but what about the primary care physicians? A few barriers exist here:

1. $$$ - docs don't have the money to invest in infrastructure like this. And more importantly...
2. Why would they? Why would they want to share their info with other primary care physicians which could possibly give competitors an edge?

So there still seems to be a case for doctors as data consumers, although there seems to be a conflict of interest for them to behave as data providers. This might be circumvented if patient data can be released while protecting data regarding the physician history.

This would be a wonderful scenario for user-centric identity...

Zone of Mediocrity

Words of wisdom from Kathy Sierra:

"...if you're not doing something that someone hates, it's probably mediocre..."

"...be willing to take risks! Perhaps more importantly, be willing to tolerate (and perhaps even encourage) risk-taking in those who are managed by you..."

Identity Management PMs and Use Cases

I just read an interesting blog entry on Mike Wyatt's Blog entitled "Project Managers as a Critical Success Factor or Identity Management Projects". It peaked my interest because it has become a recurring topic of discussion amongst some of the folks in our integration team. Mike talks about clients not wanting to shell out the extra service dollars for the PM, opting to use their own "experienced" PMs. Mike aptly points out...

...in order to "get the deal done" vendors will make this concession. More often than not, when a project gets in trouble, the common issue is not technology (the bits) or even the vendor's technical team. It is usually the lack of strong project management, especially when customers are providing the project manager.

A few points that our team has come up with:

• Use Case definitions for identity projects are quite helpful, especially in defining expected behavior of the IdM system based on predefined inputs. Many times, PMs get caught up in the tasks that need to be completed, and become task masters who babysit the team to ensure that tasks get done, many times losing the big picture. What is the big picture? Its what the client wants, and that needs to be defined up front. So one of the first tasks for a PM should be to engage the client in order to clearly identify the use cases with accompanying pre-conditions and post-conditions. This document should read easily for any business user, so that the client PM (or equivalent) agrees to the exact desired behavior of the system upon project completion.
  
• If the use case document is clearly written, it can be used for project sign-off in the development environment, prior to migration. A meeting can be used to bring all relevant players together in order to demonstrate that the system behaves exactly as the client requested - using the use case document as a checklist. "This is what you wanted. Let me demonstrate that for you...great, it works. Let's check it off and go to the next use case."
• In the "Use Case" phase, the PM could be used heavily while using the architect for reference and sanity checks. Once the Use Case is completed, the PM could take a back seat and let the architect roll up his/her sleeves. The PM from this point only needs to monitor the project rather than to be involved and bill day-to-day. (Of course, the architect has to step in to ensure feasability before the use case is signed off on by both parties.) This shows the client that you could use a PM (and architect) effectively, and make them feel comfortable that it won't cost them a substantial services fee at the same time.

More to come on the PMs continuing role in the project...

Even Identity Can't Save Novell Now

Novell's Identity suite is arguably one of the best, with quite possibly the most number of production deployments in the market. It's provisioning solution is very mature, with Identity Manager 3 boasting "Designer", a tool allowing administrators to create almost the complete identity implementation graphically, and then drill down for configuration.
Furthermore, sales of Novell's Identity Manager are up 3% from last year. All that aside, Novell is in trouble.

Timothy Prickett Morgan states:

In the fourth quarter, Novell had software license sales of $46.1 million, down 41 percent from the year ago period. The bulk of this drop is attributed to a rapid decline in NetWare and its related Open Enterprise Server license sales, but Novell had issues in other areas. Linux is not growing fast enough to fill the NetWare hole, and neither are the company's identity management or server management product lines...You can also see why Novell bought SUSE three years ago. If it had not, Novell would be dead right now.

Hovsepian predicted lengthened stagnation in software sales in 2007, with the exception of Linux and Identity Management...but also stated a boost on '08 as a result of the Microsoft deal. Any way you slice it, Novell is not in good shape. Their stock price hit a 52-week low last week, as a result of their announcement regarding flat sales in '07. Identity brought in revenue of $23.8m in the quarter. Sales were up just $793,000, or 3.5%, to be worth 9.7% of overall revenue...apparently, Identity can't save Novell, but maybe Microsoft can.

DOJ, Ping, and the Disappearing Service Dollar

A friend of mine forwarded an email to me today regarding a project for a client who was interested in deploying Ping Federate. At first, I was pretty excited. I'm a big fan of what Ping has done in the past years - they've brought solid software to solve the world's federation problems. (In the company I used to work for last year, I had the privilege of taking my team of identity consultants to Ping's HQ in Denver to meet the Ping folks and get trained in Ping Federate. Honestly, they've got the highest concentration of brains in a small company I've ever seen. Kudos to Andre.)

When I got the email regarding the project, I noticed that it was in fact a forwarded email from a recruiter who wanted to "staff" a position at the Department of Justice...looking for a person who had experience with the Ping line. Then I saw this press release from Ping, stating:

...PingFederate will be part of the expanded RISSNET architecture used to enable law enforcement and criminal justice agencies throughout the United States, Canada, the United Kingdom, Australia and the U.S. Territories to share intelligence and coordinate efforts against criminal and terrorist networks that operate in multiple locations.

That's some pretty serious stuff. Eric Norlin (who knows a thing or two about Ping) states this on his ZDNet blog:

Ping Identity announced that the U.S. Department of Justice selected them to provide federation to over 7,300 local law enforcement agencies and 700,000 law enforcement officials.

I was interested. It was definitely something we could respond to. But the email's "staffing" approach of the whole thing kind of threw me off. The press release and the recruiter's email didn't seem to fit.
Anyhow, I got a phone call a few hours ago with the details. Worse than I imagined...they want a "resource" (guaranteed till February! yeehaw.), for a rate so low that we wouldn't even cover our costs. Could it be that the Department of Justice was just looking at a federation deployment for nearly three quarters of a million seats as something to throw a "resource" or two at? Anyone who knows anything about identity will tell you that federation could be pretty complicated stuff. Also, how could the rate possibly be so low? How many layers were between us and DOJ? Who's eating all of the service dollars? Even if there were alot of layers, would DOJ accept a team slapped together to deploy an enabling technology like federation? Somethings not right, definitely not right.

Best Identity Management Solution Competition?

SC Magazine has released the Finalists for its Best Identity Management Solution Award. The list of finalists are:

BMC Identity Management
Courion Enterprise Provisioning Suite
Encentuate TCI
Novell Identity Manager and Access Manager
Oracle Identity Management

What do you mean Identity Management?? Kind of broad, isn't it?

"Includes user provisioning solutions, single sign-on, password management, user rights revocation, etc."

OH. "Etc." !! Never mind, that clarifies everything.

Kim Goes Veg

Kim makes some excellent points regarding the inclusion of vegetables into the identity laws. Read for yourself:

The synergistic combination of omnidirectional identifiers and correlation handles on a per-vegetable basis could be the sustainable architecture behind the meta-zucchini infrastructure.

Any metasystem needs to realize that pumpkins may vary in physical appearance, but their basic architecture is the same: stem, seeds and pulp represent the core of our constituent squash identity system.

We hope our commentary will stimulate oral interfacing across the vegosphere and among the “gouderati”.