Author Archives: Mike Trachta - Page 2

The Customer Is Not Always Right

Posted by on July 11, 2011 4 comments

I came across this post by David Maynor, and something really stuck out to me:

Security is the first business I have seen where the customer is not always right.

I will admit I have changed testing strategies to appease customers. The wide eyed “you are gonna do what?!?!” response to a testing planned has made me worried about losing a client so although I will ruffle my feathers and puff out my chest on the importance of the testing but in most cases I will acquiesce to please the clients. This is my fault and I should not do it.

I’m sure this has happened to many of you, it has certainly happened to me.

  1. You visit a customer.
  2. They refer to you as an expert (because you are).
  3. You analyze their needs.
  4. You give your suggestions.
  5. The customer ignores you.

In the end, they say “That sounds great, but we do things this way…  We need to be able to emulate that with our new processes.”

Rather than stick to your guns, you go along with them because after all, they are the ones signing the checks, and you want them to be happy with your services/product/etc.  I often end up saying something like “Well, that is my advice, but it is ultimately your decision.”

The problem is, they end up being unhappy.  Customers often don’t fully understand the scope and impact of an Identity initiative, especially if this is their first.  The project often gets out of control.  Once they start seeing the results of implementation, they realize that maybe they should have done some things differently. Maybe they should listened to your advice.  By this time you are in testing, and its too late unless you want to start taking steps backward and pushing out your timeline.

Here are some of the situations I have run into:

  1. The customer does not want to invest in separate development and test environments.  This creates many issues.  It makes it difficult to develop one work stream while another is being tested, as they are often intertwined in some way.  It ends up being a situation where all work needs to be completed before any of it can be meaningfully tested.  You then end up with a list of changes and defects that is difficult to manage and prioritize, and you must be fixing them at the same time the customer continues their testing.
  2. Not allowing the engineers to have administrative rights on development servers.  It’s a development server!  I understand you have policies where outside contractors/vendors can’t be administrators, but let me reiterate:  It’s a development server!  This can tremendously slow down an implementation.  Often the engineer must wait for the customer for things like replacing a file, installing a component, restarting services, etc.  You are trusting us with building the system that will control the entirety of your identity infrastructure, but you won’t trust us to have full access to a single box where we perform our development.
  3. Moving forward with development before design has been fully signed off.  This happened very recently, and it has been a major headache.  We received approval for architecture, and design was 80% complete, and we moved forward with development.  Now guess what?  Requirements weren’t properly incorporated.  Screens weren’t built out as expected.  We end up doing more discovery while we are deep into the build phase.  I’ll admit this is one where we didn’t push back because we wanted to move forward, but in hindsight I wish we would have.

I’m not saying that we’re always right, or that we immediately understand all customers’ cultures immediately, but maybe we should do a better job of pushing the customer towards best practices and recommendations based on our prior experiences.  Maybe we should stand our ground a little more firmly.

The problem is:  How do you do it?

Here are a few of my suggestions:

  1. Have a prepared document of implementation best practices with supporting information.  Provide this to the customer prior to the initial engagement.
  2. Require sign-off any time a best practice isn’t being followed.  Nothing too formal, it could even an email.  Just make sure the customer is consciously aware of the decision they are making.
  3. If you deem the issue large enough, escalate it to your own project sponsor and let him or her handle further communications with the customer’s project sponsor.

How do you push the customer appropriately?  They are the ones who own the project, and they are the ones who can pull in another vendor. How do you become a “Trusted Advisor” and better guide them  through their implementation?

Migrating Data

Posted by on December 16, 2009 No comments

When migrating between Courion environments I often run into situations where I need to not only migrate the structure of a table, but also the data. This is most common when migrating configuration tables. I looked for some SQL that would generate insert statements from a given table, and came across this blog entry.

This solution was not perfect, as it didn’t properly handle columns with spaces or that used reserved words in their names.  Luckily someone else had fixed this and placed the solution in the comments.  There is still one drawback that it handles empty columns as NULLs, but it still handles 90% of the work.  If I have the time, I’ll try to work that out and post an updated solution.

SQL Code and usage after the jump.

Read more »

Custom Courion Transformation: VB-STRING

Posted by on December 14, 2009 No comments

I recently ran into a situation where I needed to take the output of a macro and assign it to a variable in a separate VBScript Courion macro.  In order to handle the line returns as well as embedded quotation marks I created a custom transformation.  To implement, simply create a file called CustomTransformations.xml in the CourionServiceTransformations Directory, and include the following XML Code:

<?xml version="1.0" encoding="UTF-8"?>
<transformations>
  <!-- VBScript String Adds leading and trailing quotes,
    escapes internal quotes and handles crlf's-->
  <transformation name="VB-STRING">
    <prefix>"</prefix>
    <replacements>
      <replace from="&quot;" to="&quot;&quot;"/>
      <replace from="&#x000d;&#x000a;" to="&quot; &amp; vbcrlf &amp; &quot;"/>
    </replacements>;
    <postfix>"</postfix>
    <seperator> &amp; "," &amp; </seperator>
  </transformation>
</transformations>

Facebook to Support OpenID Authentication

Posted by on April 29, 2009 No comments

I just read over at Jeff Bohren’s Identity Blogger that Facebook is going to become an OpenID relying party.  According to Inside Facebook:

Less than three months after joining the OpenID Foundation’s board as a sustaining corporate member (i.e. putting its weight and financial support behind OpenID), Facebook has just announced at the “technology tasting” event this afternoon at its Palo Alto headquarters that users will soon be able to log in to Facebook with their OpenID.

This is a big win that gives OpenID mainstream support and acceptance.  Hopefully it will lead to more provider support, as well as greater user adoption.

Now I’ll be able to log on to Facebook using my iPhone as a virtual token.

Verisign Powers iPhone Two-Factor Authentication

Posted by on April 10, 2009 2 comments

I just saw an article that Verisign now has a free iPhone app offering two-factor authentication:

The security app offers two-factor identification designed to strengthen protection on e-commerce site and with other online accounts. As of today’s launch, Verisign (NASDAQ: VRSN) said it has signed up over 40 Web sites as participating members of its VIP Network, including eBay (NASDAQ: EBAY), PayPal and AOL.

I personally think this is a great thing.  I previously used a Verisign token to protect my OpenID account at pip.verisignlabs.com.  It was always a pain in the you-know-what to carry around, so I never extended it to be used with my PayPal or Ebay accounts.  I ALWAYS have my handy iPhone nearby, so I immediately downloaded the app, activated it, and tied it to my PIP account.  It worked like a charm.  Next is setting it up with paypal, ebay, etc.

Anyone else have experience with these virtual tokens?  Any cons that I should be aware of?

It’s been a while

Posted by on March 24, 2009 No comments

Well, as you can see, I haven’t posted in a little over 5 months.  I’ve had some things happen in my personal life and I’ve been trying to determine the direction for this blog for the past couple of months.  I hope to have some new updates within the next week or so.

I’m also trying to figure out all of this social media stuff (Twitter, Facebook, Yammer, etc), and how that might all fit in here.  If you have any suggestions, I’m all ears!

A Good Technical Sales Person, Defined

Posted by on October 16, 2008 2 comments

Earlier this week I asked for opinions on what makes a good technical sales person.  Now, I’d like to share mine.

I’ve been lucky in my career. I’ve worked with terrific sales people, and had very few occasions where they made a promise we couldn’t deliver on.  Here are the things I think they’ve done well:

  1. They communicate with Implementation (and possibly Support) during the sales process.  This is particularly important if they are new to the company, or the product.  If there is something they are unsure about, they should always check with Implementation/Support before agreeing it can be done.  This also includes handing over any information they may have already discovered.  Customers hate being asked for the same information twice.
  2. They set customer expectations.  This really just boils down to the fact that they don’t make promises the delivery team can’t deliver on.  They give of an overview of the implementation process as well as the philosophy behind it.  This lets the customer know exactly what to expect at kickoff.
  3. They aren’t afraid to say “no”.  This goes back to setting expectations, and not promising something that can’t be delivered on.

I also want to add one more thing that isn’t really a quality of the person.  As Rod pointed out in his comments, a technical sales person should report to services rather than sales.  This keeps his/her interests aligned with services, and thus, helps ensure they strive for sales that lead to successful implementations.

Are there other things to add to this list, or maybe some things you don’t think are as important?  Please leave any feedback in the comments.

What Makes A Good Technical Sales Person?

Posted by on October 14, 2008 2 comments

I posted last week about how POCs can make life difficult on the engineer responsible for implementing a solution.  This got me thinking not just about POCs, but also about the person who makes the sale.  I started wondering, “What makes a good technical sales person?”.  I want to look at this through the perspective of services, rather than from the typical revenue perspective.

Obviously you need people who can close deals and bring revenue to the company.  Any technical sales person should have technical aptitude, and be honest and personable.  What other qualities should they have?

Please leave your thoughts in the comments.  I’ll post my opinion later this week.

Who Else Hates POCs?

Posted by on October 7, 2008 2 comments

My friend Ashraf Motiwala brought up a topic I’m very familiar with when he explained Why (most) Identity Management POCs Suck.

To give a brief overview, a POC (Proof of Concept), at least in my experience, basically consists of a sales guy, and a sales engineer.  They spend a couple of days with a client, and build a solution to prove they can integrate with the customer’s technology.  Ash came up with 3 major complaints:

  1. A typical POC is just a glorified demo.
  2. The success of the post-POC demo is highly dependent on 2 individuals on the vendor team: the Sales Engineer (the guy who duck-taped together the POC) and the POC-demo-guy
  3. A POC is typical technology focused. Most IdM deployments are business process centric.

I have a 4th and major complaint, coming from the point of view of a integrator who must implement the solution after the deal has been sold:

POCs typically stretch the system to its technical limits, and are able to do so because they are built in a very controlled environment.  When it comes time to scale, the demoed solution won’t work. This leads to unreasonable expectations.

This can create a lot of problems for the consultant/engineer implementing the final solution.  I consider one of my most important jobs to be managing the customer’s expectations.   A typical overly elaborate POC make this job extremely difficult.

The sales folks may not realize it, but the customer remembers more about the POC than you think.  They remember how pretty the screens were.  They remember how seamlessly all the pieces fit together, and how quickly each task executes.  What they don’t realize is that all of the data is massaged and simplified.  Of course the POC could do these things!  It has 3 users with 4 roles to choose from, and doesn’t include any of the “exceptions” often found in the customer’s environment.  When it comes time to actually implement this feature with 30,000 users things can (and do) get quite a bit more complex.

Has anyone else had bad experiences due to a POC?  If so, let us know by leaving a comment.

An Elevator Pitch for Identity Management, part 2

Posted by on October 3, 2008 2 comments

Here is the definition, according to Wikipedia:

Identity management is the management of the identity life cycle of entities (subjects or objects). An identity management system:

  1. Establishes the identity
    1. Links a name (or number) with the subject or object;
    2. Re-establishes the identity (i.e. links a new or additional name, or number, with the subject or object);
  2. Describes the identity:
    1. Optionally assigns one or more attributes applicable to the particular subject or object to the identity;
    2. Re-describes the identity (i.e. changes one or more attributes applicable to the particular subject or object);
  3. Destroys the identity

I also got a couple of comments from readers, including:

You help businesses be sure they know who is doing what with their computer systems.

and:

*Streamlining all user accounts (anyone who has 10 sets of ids at their workplace can relate to the benefit of this)
*being able to do a master reset on pw (save IT staff time)
*Being able to disable all accounts in one shot thus securing data from those who no longer should have access

Putting it all together, I’ve come up with the following pitch:

Identity Management solutions allow an organization to control and audit what its users can do.  This includes creating accounts for users when they are hired, modifying their accounts as they change jobs within the organization, and terminating a user’s access when they leave.  It also allows users to synchronize their password across the various computer systems they have access to.

Is there anything important I may have left out?  Is it simple enough for someone who isn’t technical to understand?


Social Widgets powered by AB-WebLog.com.