★ The US Government Claims You Don’t Own Your Cloud Data

Apparently the government thinks I don’t own the content of my blog:

But in addition, the government’s approach should terrify any user of cloud computer services—not to mention the providers.  The government maintains that Mr. Goodwin lost his property rights in his data by storing it on a cloud computing service.  Specifically, the government argues that both the contract between Megaupload and Mr. Goodwin (a standard cloud computing contract) and the contract between Megaupload and the server host, Carpathia (also a standard agreement), “likely limit any property interest he may have” in his data.  (Page 4). If the government is right, no provider can both protect itself against sudden losses (like those due to a hurricane) and also promise its customers that their property rights will be maintained when they use the service. Nor can they promise that their property might not suddenly disappear, with no reasonable way to get it back if the government comes in with a warrant. Apparently your property rights “become severely limited” if you allow someone else to host your data under standard cloud computing arrangements. This argument isn’t limited in any way to Megaupload — it would apply if the third party host was Amazon’s S3 or Google Apps or or Apple iCloud.

★ Putin Silencing His Critics

Using “The Children” to silence one’s critics.  You want to protect the children, don’t you?

Signed into law by Vladimir Putin on July 28, the internet-filtering measure contains a single, innocuous-sounding paragraph that allows those compiling the Register to draw on court decisions relating to the banning of websites. The problem is, the courts have ruled to block more than child pornographers’ sites. The judges have also agreed to online bans on political extremists and opponents of the Putin regime.


★ The Value of Partnership

Today I want to talk about a very simple idea:

A successful implementation begins and ends with a successful partnership.

This may sound obvious, but you’d be surprised how many people don’t understand this concept.  I’ve seen customers who are more concerned about extracting everything they possibly can from a vendor that they lose sight of their goal.  They point to the vendor any time a deadline is missed or a mistake is made.

I’ve also seen software vendors and integrators who seem to care more about landing a deal and maximizing revenue that they fail to serve their customers in the best way possible.  They look for excuses when things go awry, and resort to making up answers to issues.  This does not build trust with a customer.

I recently completed a project with a healthcare organization that understood this very well.  The project wasn’t the biggest technical challenge, but it was going to noticeably affect everyone in their organization, most notably their help desk who was going to have to handle calls for the new system.  However, we didn’t see the same resistance we see when implementing visible change at other organizations.  We were even able to get buy-in from the doctors, which is often a challenge in itself in healthcare.

The customer sponsor, the implementation team, the help desk and Identropy had all formed mutual trust with one another.  Because of this, we were able to effectively communicate the benefits of the project and work together towards a successful implementation.  One member of the customer’s implementation team even told me they liked Identropy from the start because we were willing to say “I’m not sure about that, let me get back to you” to questions before even landing the deal.

We ended up going live with barely a blip on the radar.  There were a few things that had to be tweaked after feedback from end users, but nothing major.

And one other thing, the project was also completed WAY under budget.  Part of it was due to changes in the initial scope.  Most of it was due to two things:

  1. We rarely had the communication issues that can arise from looking out for #1, and
  2. With guidance, the customer was willing to take on some of the work even though they weren’t formally trained on the product.

Rather than focusing on CYA and individual interests, we focused on the project.  I attribute this to the fact that the customer saw the value of our partnership, and viewed myself and Identropy as “Trusted Advisors” rather than just another vendor.  On the flip side Identropy understood the value of the project, and rather than just billing just because we had the hours, we truly worked in the customer’s best interests.

After wrapping up that project I joined an ongoing implementation with a large telecom.  Its an aggressive project.  Within the next 24 months we are to design, build, test, and implement a best of breed collection of logical access controls, physical access controls, privileged access management, as well as automated and request-based provisioning for an organization that cannot tolerate any real measurable downtime.  Oh, and the customer is new to pretty much all of these concepts and products and is relying heavily on Identropy’s expertise.

In most situations I would call this a daunting task.  In this instance I not only think its doable, but I have every confidence we will exceed expectations and deliver on-time.  How can I be so confident?  This customer recognizes the value of partnership.  They value a work-life balance, even for their vendors.  As a services vendor, I must say this is refreshing.

I just returned from my first on-site visit.  The purpose of the visit was to get to know the team and build rapport.  Of course I had deliverables to work on, but they could have just as easily been completed at the home office.  The better we know and understand one another, the better we will communicate and work together.

Don’t get me wrong, this customer can’t afford to simply waste dollars just to have their vendors visit the office.  Nor do they think they need to watch over us. They have assured us that they fully trust our abilities to work off-site without watchful eyes.  They just understand the value of getting to know one another.

It seems like all too often we focus on short term goals rather than building lasting relationships.  It’s good to work with customers (and for a company) that understands the value of these relationships not only for the team members, but for the organizations themselves.

★ Taking an Apple Approach to IAM Implementations

This post can also be found here on the Identropy Blog.

Ah, the religious wars: vi vs Emacs (vi!), Republican vs. Democrat (Neither), Mac vs. PC (Mac!)…

Mac vs. PC. We all know the talking points:

  1. Macs are pretty, PCs are not.
  2. PCs can be configured a billion ways, to use a Mac you must do it the way Apple thinks you should.
  3. Macs are easy, PCs can be difficult
  4. Did I mention Macs are pretty?

You may not agree with these assessments, but they’re popular opinions. You might ask why I would be blogging about them in a blog where I typically stick to consulting and Identity Management.

The fact is, we generally take a PC approach to IAM implementations: Here is the product, and these are the 5 million different switches we can flip to customize it for your organization. We have our best practices (default configuration), but ultimately we’re going to customize it the way you want it to be, whether it’s good for you or not. We want to be everything in IAM to everybody who will pay for IAM.

Is this the right approach? I don’t think it is. Why don’t we take a look at how Apple does things?
I recently read an article from Pragmatic Marketing, a journal my wife used to read as a product manager. They go through some of the reasons why Apple is worth billions of dollars and you aren’t.

A few of them stuck out at me:

You need to know your customer and your market.

The point is not to go ask your customers what they want. If you ask that question in the formative stages, then you’re doing it wrong. The point is to go immerse yourself in their environment and ask lots of “why” questions until you have thoroughly explored the ins and outs of their decision making, needs, wants, and problems. At that point, you should be able to break their needs and the opportunities down into a few simple statements of truth.

This is terrific advice. People do not typically know what they want, they only think they do. Invest the time in figuring out what the end goal is, then you can propose the right solution to the problem.

Pony meetings.

These meetings are scheduled every two weeks with the internal clients to educate the decision-makers on the design directions being explored and influence their perception of what the final product should be.

Keep leadership involved, and keep them on your side. Present them with an elegant solution that meets the needs of the organization. As long as they are on board with your solution, you can better drive the project.

Apple focuses on a select group of products.

Apple acts like a small boutique and develops beautiful, artistic products in a manner that makes it very difficult to scale up to broad and extensive product lines.

Dont try to solve every problem. Dont try to work in every vertical. Stick to what you’re good at, and be the best at it. This will actually make future engagements easier as you’ll have some street cred.


Ultimately, if you pay attention to detail and listen for what the customer really wants, not what they think they want, you should be successful. Just don’t be afraid to tell the customer “no” and explain why they need to change course a bit. The end result will be a successful implementation and a happy customer.