Sunday, May 30, 2010
Vendor Webinar Worst Practices
The trend of software vendors doing webinars in conjunction with industry analysts is on the rise. While analysts do a great job in presenting, many software vendors make fatal mistakes in retaining the attention of end customers...
Let's first agree that a marketing department's job is to make content appeal to the masses and to add polish. Likewise, they will keep track of metrics such as the number of people who have registered for a webinar, demographics of the attendees and so on. What they never consider is whether their actions cause us to not pay attention to their value proposition while attending.
Many times, an idea for a webinar is seeded by some industry expert within a given subject area. The message is then massaged often to the point where the true topic gets lost in translation. Other times, marketing chooses topics based on presumed popularity and frequently attempts to over sell their product before end customers have even heard the basic message. At some level, this violates the adage of underselling and overdelivering.
Have you considered making your webinar shorter than one hour? The attention spam of society at large is becoming increasingly short where people prefer twitter over a great novel or a one-page PowerPoint over comprehensive in-depth research. Consider making future webinars no longer than 1/2 hour.
Have you also noticed that folks at large are tired of being shot at via PowerPoint bullets? A webinar should not feel like standing in the middle of a drive-by. Many great conference presenters have moved away from PowerPoint towards more modern presentation formats such as Prezi which works equally well in webinar format.
I like the fact that many vendors choose platforms which allow for me to add the webinar to my calendar. Likewise, it is natural for me to want to share interesting events with others. Intuitively, I will forward calendar invites to others. The challenge becomes for those vendors who believe it makes sense to include a webinar code that is unique to me vs being more generic. On way too many occasions, I have attempted to access a webinar only to be told that someone is using the code and I had to spend time registering. Sometimes I do register, but usually this comes at the expense of me missing the first five minutes of your presentation and not having full context. At other times, I simply don't bother to re-register and move on to the next task. Tracking is fine at some level, but it should come via putting up impediments for your end-customers to hear your value proposition...
| | View blog reactionsLet's first agree that a marketing department's job is to make content appeal to the masses and to add polish. Likewise, they will keep track of metrics such as the number of people who have registered for a webinar, demographics of the attendees and so on. What they never consider is whether their actions cause us to not pay attention to their value proposition while attending.
Many times, an idea for a webinar is seeded by some industry expert within a given subject area. The message is then massaged often to the point where the true topic gets lost in translation. Other times, marketing chooses topics based on presumed popularity and frequently attempts to over sell their product before end customers have even heard the basic message. At some level, this violates the adage of underselling and overdelivering.
Have you considered making your webinar shorter than one hour? The attention spam of society at large is becoming increasingly short where people prefer twitter over a great novel or a one-page PowerPoint over comprehensive in-depth research. Consider making future webinars no longer than 1/2 hour.
Have you also noticed that folks at large are tired of being shot at via PowerPoint bullets? A webinar should not feel like standing in the middle of a drive-by. Many great conference presenters have moved away from PowerPoint towards more modern presentation formats such as Prezi which works equally well in webinar format.
I like the fact that many vendors choose platforms which allow for me to add the webinar to my calendar. Likewise, it is natural for me to want to share interesting events with others. Intuitively, I will forward calendar invites to others. The challenge becomes for those vendors who believe it makes sense to include a webinar code that is unique to me vs being more generic. On way too many occasions, I have attempted to access a webinar only to be told that someone is using the code and I had to spend time registering. Sometimes I do register, but usually this comes at the expense of me missing the first five minutes of your presentation and not having full context. At other times, I simply don't bother to re-register and move on to the next task. Tracking is fine at some level, but it should come via putting up impediments for your end-customers to hear your value proposition...
Thursday, May 27, 2010
Analyzing the Analysts: Comparison of Gartner and Forrester
I have frequent interactions with industry analysts in my day job as an Enterprise Architect for a Fortune 100 enterprise. Likewise, during evening hours I can be found on Twitter under the handle of McGovernTheory engaging in virtualized short-form conversations where many analysts also hang out.
I currently follow the likes of Ray Wang of Altimeter, Nick Selby of Trident Risk Management, Brenda Michelson of Elemental Links, James Governor of Redmonk and others who periodically throw daggers. Their comparisons are usually cordial and tend to leave out certain relevant detail for us end-customer types to fully understand the real conversation. The challenge of the outsider looking in.
Industry Analyst Relations professionals such as Barbara French and Carter Lusher provide great insight for vendors on which analyst firms to work with, but otherwise leave a void in that they don't address end customer considerations. Today's blog entry starts with me attempting to emulate their style. Imitation is the best form of flattery...
Consulting
At Gartner, Analysts do limited consulting engagements. Much of the consulting is handled by a dedicated consulting team. At Forrester, Analysts have a mix workload of consulting and research.
McGovern’s Take: There is something to be said for having more time to dedicate to research. The challenge is in doing research that is relevant to the challenges that end-customers face. At times, you need to be in the heart of the conversation, while at others you need to take a step back and see the bigger picture.
Outstanding Questions:
At Gartner, the vast majority of analysts come from an end-customer background with IT vendors as the second. At Forrester, A significant portion of the analysts come from a journalism background.
McGovern’s Take: Journalism teaches one to become more aware of market trends, while coming from a practitioners perspective allows you to separate out marketing from reality.
Outstanding Questions:
At Gartner, Analysts only speak at events where they are sponsored. At Forrester, Analysts can speak at any event. It is up to them to manage.
McGovern’s Take: There is a subtle distinction between events that help build an analysts brand vs events that help increase direct analyst revenue. Limiting the events that an analyst can speak at can serve to build brand in a way that avoids commoditization. Limiting the events that an analyst can speak at may encourage analysts to research popular topics vs those that are necessary for complete coverage.
Outstanding Questions:
I absolutely love BurtonGroup.TV. The conversational style absolutely rocks. At Forrester, analyst participate more frequently and engage in conversations via Twitter than many of their peers.
McGovern’s Take: I could envision customer inquiries regarding social media where customers have to resort to using traditional telephone technology. Analysts have a personal vested interest in keeping tabs of the pulse of their coverage area, and social media is the most up-to-date relevant method for doing so.
Outstanding Questions:
Gartner has a thriving Fellows program where star analysts are given a year to research topics of interest to them. I am unsure of what the equivalent at Forrester is.
McGovern’s Take: Ray Wang and others have frequently discussed the challenge of maintaining top talent within analyst firms. At some level, the conversation should be less about ego and should be driven by dollars and sense. If an analyst brings in lots of money and is profitable to the firm, pay them for doing so.
Outstanding Questions:
At Gartner, members of analyst teams tend to be distributed in different parts of the United States. At Forrester, members of analyst teams tend to be clustered around a Forrester office.
McGovern’s Take: I am probably over generalizing but based on my own experiences with both firms, this tends to hold true. For example, in Gartner I have had great interactions with Ian Glazer, Bob Blakely, Mike Gotta, Ramon Krikken and Anne Thomas Manes. From what I know, none of them even live in the same state as each other let alone near a Gartner office. My interactions with Forrester analysts have included Chenxi Wang, Andrew Jacquith, Alex Cullen whom all live in the Boston area near the Forrester office. I would think that analyst firms should hire talent regardless of where they live. This worst practice is a fatal flaw in many enterprises. If we can outsource business processes around the planet, I think we should be able to figure out how to let a few employees not live near an office.
Outstanding Questions:
Gartner's recent acquisition of Burton Group proves out its commitment to the IT practitioner within the enterprise. I have not observed an equivalent within Forrester's business model.
McGovern’s Take: The vast majority of published analysis seems targeted at making a procurement decision which in the eyes of this enterprise architect feels fugly. If analysts are to truly provide guidance to enterprises, they not only need to assist with product selection but also provide architecture-level guidance as well. There is incredibly benefit from analysts not only enumerating industry standards but being a catalyst in the modification of existing ones and creating new ones where they are needed.
Outstanding Questions:
There are probably lots of other dimensions on which these two great firms could be compared on that I didn't think about. Anyway, hopefully a few analysts who happen to read this post will reply back and share their insight to some of the questions asked. I am thinking about doing a similar comparison in the future between RedMonk and the Altimeter Group which will most certainly put a smile on both James Governor and Charlene Li's face. Stay tuned...
| | View blog reactionsI currently follow the likes of Ray Wang of Altimeter, Nick Selby of Trident Risk Management, Brenda Michelson of Elemental Links, James Governor of Redmonk and others who periodically throw daggers. Their comparisons are usually cordial and tend to leave out certain relevant detail for us end-customer types to fully understand the real conversation. The challenge of the outsider looking in.
Industry Analyst Relations professionals such as Barbara French and Carter Lusher provide great insight for vendors on which analyst firms to work with, but otherwise leave a void in that they don't address end customer considerations. Today's blog entry starts with me attempting to emulate their style. Imitation is the best form of flattery...
Consulting
At Gartner, Analysts do limited consulting engagements. Much of the consulting is handled by a dedicated consulting team. At Forrester, Analysts have a mix workload of consulting and research.
McGovern’s Take: There is something to be said for having more time to dedicate to research. The challenge is in doing research that is relevant to the challenges that end-customers face. At times, you need to be in the heart of the conversation, while at others you need to take a step back and see the bigger picture.
Outstanding Questions:
- Does less frequent face-to-face interaction with end-customers cause depression? Being trapped in one’s home office for extended periods can make your home feel like a prison.
- Does so much consulting result in another form of burnout? I would think that traveling to different clients potentially in different time zones would cause every day to feel like a permanent jet lag?
At Gartner, the vast majority of analysts come from an end-customer background with IT vendors as the second. At Forrester, A significant portion of the analysts come from a journalism background.
McGovern’s Take: Journalism teaches one to become more aware of market trends, while coming from a practitioners perspective allows you to separate out marketing from reality.
Outstanding Questions:
- Do clients of analyst relations firms such as Tekrati and SageCircle ever consider what is most important to getting their product message out? A journalist can write marketing materials that vendor sales teams can use, but to truly influence an end-customer such as myself, this also best realized by having a conversation with someone who has walked in my shoes.
- A practitioner can functionally decompose a problem-domain and has the potential to provide guidance not just in the marketing aspects of any given product, but may be able to comment on the architecture of the product as well. Do analyst relations professionals only consider the marketing aspects?
At Gartner, Analysts only speak at events where they are sponsored. At Forrester, Analysts can speak at any event. It is up to them to manage.
McGovern’s Take: There is a subtle distinction between events that help build an analysts brand vs events that help increase direct analyst revenue. Limiting the events that an analyst can speak at can serve to build brand in a way that avoids commoditization. Limiting the events that an analyst can speak at may encourage analysts to research popular topics vs those that are necessary for complete coverage.
Outstanding Questions:
- Do analyst relations firms ever encourage their clients to consider sponsoring analysts for speaking engagements at conferences? For example, could Fortify Software benefit by having Neil MacDonald speak at the upcoming OWASP conference or say could Whitehat Security benefit by having say Chenxi Wang speak on web vulnerability scanning tools at BlackHat?
- In terms of analyst relations, I would think that sponsoring an analyst in this manner would allow for more intimate conversations above and beyond a ½ hour dialog. Why aren’t analyst relations firms figuring out creative ways for vendors to put the words into the mouths of analysts?
I absolutely love BurtonGroup.TV. The conversational style absolutely rocks. At Forrester, analyst participate more frequently and engage in conversations via Twitter than many of their peers.
McGovern’s Take: I could envision customer inquiries regarding social media where customers have to resort to using traditional telephone technology. Analysts have a personal vested interest in keeping tabs of the pulse of their coverage area, and social media is the most up-to-date relevant method for doing so.
Outstanding Questions:
- The model of measuring influence is busted and there is a growing chasm between how vendors think enterprise buyers think about technology vs how we actually think about technology. If you look at Twitter as a micro chasm of society, increasingly people are having less appetite to read long-form information. If this is the trend, why are analyst relations firms not talking their clients out of working with analyst firms who create reams of documentation?
- Why aren’t analyst relations firms asking analysts to do podcasts or other modern methods? Webinars are good, but have you considered how much multitasking goes on while at work? Do you think I am truly capturing the full value of the message being delivered? Have you considered that I probably have lots of idle time during my commute and can listen to podcasts where I can spend more think time on your value proposition?
Gartner has a thriving Fellows program where star analysts are given a year to research topics of interest to them. I am unsure of what the equivalent at Forrester is.
McGovern’s Take: Ray Wang and others have frequently discussed the challenge of maintaining top talent within analyst firms. At some level, the conversation should be less about ego and should be driven by dollars and sense. If an analyst brings in lots of money and is profitable to the firm, pay them for doing so.
Outstanding Questions:
- At work, I am surrounded by lots of former Accenture employees. Other firms such as Mckinsey, Diamond, Deloitte and so on have strong alumni networks. Would love to know why analyst firms arent leveraging their network in this regard?
- There is something to be said about eliminating star analysts as it has the side effect of allowing up-and-comers their opportunity to shine. Should analyst firms figure out better ways for each and every analyst to get their day in the spotlight instead of reserving it for the select few?
At Gartner, members of analyst teams tend to be distributed in different parts of the United States. At Forrester, members of analyst teams tend to be clustered around a Forrester office.
McGovern’s Take: I am probably over generalizing but based on my own experiences with both firms, this tends to hold true. For example, in Gartner I have had great interactions with Ian Glazer, Bob Blakely, Mike Gotta, Ramon Krikken and Anne Thomas Manes. From what I know, none of them even live in the same state as each other let alone near a Gartner office. My interactions with Forrester analysts have included Chenxi Wang, Andrew Jacquith, Alex Cullen whom all live in the Boston area near the Forrester office. I would think that analyst firms should hire talent regardless of where they live. This worst practice is a fatal flaw in many enterprises. If we can outsource business processes around the planet, I think we should be able to figure out how to let a few employees not live near an office.
Outstanding Questions:
- I haven’t yet figured out whether the differences in approach are one of culture or lack of tools or both? If analysts can collaborate with us end customers without being in the same geographical reason, what requires them to be in the same geographical location as each other?
- There are times when I love to work virtually at home with my coworkers and others where I appreciate being able to have a room with lots of whiteboards. I know that analysts can also collaborate at conferences they all collectively present at. This begs the question of how much cross-analyst collaboration is beneficial.
Gartner's recent acquisition of Burton Group proves out its commitment to the IT practitioner within the enterprise. I have not observed an equivalent within Forrester's business model.
McGovern’s Take: The vast majority of published analysis seems targeted at making a procurement decision which in the eyes of this enterprise architect feels fugly. If analysts are to truly provide guidance to enterprises, they not only need to assist with product selection but also provide architecture-level guidance as well. There is incredibly benefit from analysts not only enumerating industry standards but being a catalyst in the modification of existing ones and creating new ones where they are needed.
Outstanding Questions:
- If analysts are driving standards, do analyst relations firms guide their clients to understand this as a method of analyst influence as well. For example, Gerry Gebel formerly of the Burton Group drove interoperability discussions across vendors. The very nature of this activity would require him to spend a lot more time understanding the unique characteristics of each vendor than analysts who only publish product selection documentation. I know the likes of Mark Diodati of Gartner will do the same for SPML. So, this begs the case of analyst relations understanding and guiding their clients on which consortium to participate on, whom to send and how it will result in increased sales.
- The Gartner website indicates that they have 80% of the Fortune 500 as clients. What is missing from the equation is how deeply they penetrate each of their clients. If you were to study the organization chart of my employer, you would note that the procurement department is centralized and located within one building. The ability to produce product selection documentation for their benefit is relatively straightforward. However, if you were to study the IT organization, you would find that it is highly distributed across at least six different locations. At some level, this feels like analyst firms leaving money on the table by not pursuing practitioners. If an analyst firm has experienced talent with hands-on experience and has walked in the client’s shoes, why would they not want to pursue this market? They have the potential of taking money away from consulting firms such as Deloitte, Accenture, etc. What is the impediment for taking the next step?
There are probably lots of other dimensions on which these two great firms could be compared on that I didn't think about. Anyway, hopefully a few analysts who happen to read this post will reply back and share their insight to some of the questions asked. I am thinking about doing a similar comparison in the future between RedMonk and the Altimeter Group which will most certainly put a smile on both James Governor and Charlene Li's face. Stay tuned...
Wednesday, May 26, 2010
Enhancements I would love to see made to Microsoft Outlook
One could be hopeful that someone from Microsoft that is on the Office and/or Exchange team reads my blog and will be savage in pursuing my suggestions for improvement. Anyway, I figured I would outline five enhancement requests that would increase the productivity of enterprise employees in significant ways…
I will probably break this up into multiple blog entries where today’s focus will be targeted at needed improvements to the calendaring function. Some of the changes may not be limited to Outlook alone and may require changes to Exchange along with the creation of new industry standards. I will let those smarter than me decide what the best approach is. For now, let me articulate the challenge.
Location
The modern enterprise employee may spend their time not in one location but traveling across multiple enterprise sites. There is no way to indicate on one’s calendar, what location you will be in on any given day. This could be valuable in allowing others in the same location to book time with you. Likewise, it would equally cause others to not book time with you if you are going to be in another location.
Travel
In situations where a person needs to travel between locations, one needs to account for travel time. For example, I would in our Hartford office and periodically need to travel to our Windsor location. I may accept an appointment in Windsor but then need to put time around the original appointment to account for drive time. Wouldn’t it be great if this could be something the organizer could populate?
Tentative
I receive lots of calendar invites and at many times they are in conflict with other accepted appointments. In this situation, I tend to click tentative such that the event still stays on the calendar and is not lost on the chance the other meeting gets cancelled. The meeting organizer will see that I responded with a tentative and then have to guess whether I did so as a placeholder with little probability of actually attending or I did so with the full intent of attending and I am simply working to free up some time. So, tentative to the individual may have different semantic meanings than to the organizer. This could be remedied by somehow either providing more granularity beyond just tentative or at least allowing a way to indicate the probability of attending in percentage/odds terms.
Resource
Outlook allows you to invite a resource where in our culture, it allows you to choose a conference room. Nowadays, many meetings have conference dialin’s and webinars attached to them. Wouldn’t it be great if I could invite them as well without having to take multiple steps? At some level, this would require the ability to send along supplemental information stored in a wallet whereby I could as an organizer use my ATT moderator code to schedule a meeting and everyone else that is participating gets the participant code. The same behavior would be desirable for gotomeeting and webex.
Conflicts
Sometimes people are slow to respond to meeting invites and may not accept till the last minute. Wouldn’t it be great if there was a way to have the meeting organizer get alerts whenever a conflict arises? How many times have vendor sales people scheduled time with me to pitch their product when at the last minute, our administrative assistant forwards another must attend meeting. This would allow the system vs a human to let the organizer know of conflict.
Taking this one step further. There are times where you absolutely, positively know in advance that a conflicting calendar invite is something you will not accept. Imagine a scenario where I proactively scheduled time off to see my two son’s get married. I would love to indicate on this calendar invite that I will absolutely not accept any other calendar invites which are in conflict.
Anyway, if anyone from Microsoft is listening, I hope you find this list of enhancement requests useful…
| | View blog reactionsI will probably break this up into multiple blog entries where today’s focus will be targeted at needed improvements to the calendaring function. Some of the changes may not be limited to Outlook alone and may require changes to Exchange along with the creation of new industry standards. I will let those smarter than me decide what the best approach is. For now, let me articulate the challenge.
Location
The modern enterprise employee may spend their time not in one location but traveling across multiple enterprise sites. There is no way to indicate on one’s calendar, what location you will be in on any given day. This could be valuable in allowing others in the same location to book time with you. Likewise, it would equally cause others to not book time with you if you are going to be in another location.
Travel
In situations where a person needs to travel between locations, one needs to account for travel time. For example, I would in our Hartford office and periodically need to travel to our Windsor location. I may accept an appointment in Windsor but then need to put time around the original appointment to account for drive time. Wouldn’t it be great if this could be something the organizer could populate?
Tentative
I receive lots of calendar invites and at many times they are in conflict with other accepted appointments. In this situation, I tend to click tentative such that the event still stays on the calendar and is not lost on the chance the other meeting gets cancelled. The meeting organizer will see that I responded with a tentative and then have to guess whether I did so as a placeholder with little probability of actually attending or I did so with the full intent of attending and I am simply working to free up some time. So, tentative to the individual may have different semantic meanings than to the organizer. This could be remedied by somehow either providing more granularity beyond just tentative or at least allowing a way to indicate the probability of attending in percentage/odds terms.
Resource
Outlook allows you to invite a resource where in our culture, it allows you to choose a conference room. Nowadays, many meetings have conference dialin’s and webinars attached to them. Wouldn’t it be great if I could invite them as well without having to take multiple steps? At some level, this would require the ability to send along supplemental information stored in a wallet whereby I could as an organizer use my ATT moderator code to schedule a meeting and everyone else that is participating gets the participant code. The same behavior would be desirable for gotomeeting and webex.
Conflicts
Sometimes people are slow to respond to meeting invites and may not accept till the last minute. Wouldn’t it be great if there was a way to have the meeting organizer get alerts whenever a conflict arises? How many times have vendor sales people scheduled time with me to pitch their product when at the last minute, our administrative assistant forwards another must attend meeting. This would allow the system vs a human to let the organizer know of conflict.
Taking this one step further. There are times where you absolutely, positively know in advance that a conflicting calendar invite is something you will not accept. Imagine a scenario where I proactively scheduled time off to see my two son’s get married. I would love to indicate on this calendar invite that I will absolutely not accept any other calendar invites which are in conflict.
Anyway, if anyone from Microsoft is listening, I hope you find this list of enhancement requests useful…
Saturday, May 22, 2010
Missing Conversations within the Identity Community: IdP Challenges
I was reading Patrick Harding's post on Browser-Based IdP Discovery and felt that while it solves some problems, it is suspect to OWASP-style attacks. Anyway, I am of the belief that a more important challenge exists within the identity community that no one is truly addressing...
Right now, much of the identity conversation is centered around consumerish usage where sites such as Yahoo, Facebook and other time-wasting sites are participants. Identity isn't up to snuff in order to conduct business over the Internet and no one seems to care.
So, let's say that you are CTO for an online stock trading platform where consumers are constantly struggling with their ID/passwords. You believe that modern approaches to identity are needed. Would IdP discovery be on the top of your list of problems to solve? As a CTO, wouldn't you care more about a way of determining the reputation of a particular IdP and discovering its policies?
The online trading platform could not possibly establish a business relationship with every IdP on the planet where they could ask for SAS-70 Type II documents or its equivalents. This however doesn't waive the need for the online trading platform to understand characteristics of the IdP such as their identity vetting process, policies around credential usage in terms of history, expiry and complexity and most importantly is their anyone else that will vouch for their practices.
Wouldn't it be cool to somehow start the conversation and borrow from the PKI community the notion of CP/CPS but only to get it out of document format into something XML schema based such that it can be consumed programatically? Sites such as StackOverflow have figured out how to capture the reputation of users on its platforms. Even email platform providers such as Cisco's IronPort have figured out how to use reputation in order to reduce spam traveling over the Internet. Why isn't the identity community noodling something similar?
A SAS-70 is another form of document that could be converted into an XML schema. Instead of a word document, why couldn't a certifying party somehow sign the identity provider such that this is consumed within either SAML or OpenID interchanges? So far we have gotten a working group on level of assurance which is fundamental to the problem-space but we need to figure out how to put a little bit of non-repudiation behind many of the attributes.
Anyway, for solving the IdP discovery challenge, I believe that Information Cards is the best model publicly available. We simply need to figure out how to create the tipping point so that B2B sites are also full participants in the identity conversation...
| | View blog reactionsRight now, much of the identity conversation is centered around consumerish usage where sites such as Yahoo, Facebook and other time-wasting sites are participants. Identity isn't up to snuff in order to conduct business over the Internet and no one seems to care.
So, let's say that you are CTO for an online stock trading platform where consumers are constantly struggling with their ID/passwords. You believe that modern approaches to identity are needed. Would IdP discovery be on the top of your list of problems to solve? As a CTO, wouldn't you care more about a way of determining the reputation of a particular IdP and discovering its policies?
The online trading platform could not possibly establish a business relationship with every IdP on the planet where they could ask for SAS-70 Type II documents or its equivalents. This however doesn't waive the need for the online trading platform to understand characteristics of the IdP such as their identity vetting process, policies around credential usage in terms of history, expiry and complexity and most importantly is their anyone else that will vouch for their practices.
Wouldn't it be cool to somehow start the conversation and borrow from the PKI community the notion of CP/CPS but only to get it out of document format into something XML schema based such that it can be consumed programatically? Sites such as StackOverflow have figured out how to capture the reputation of users on its platforms. Even email platform providers such as Cisco's IronPort have figured out how to use reputation in order to reduce spam traveling over the Internet. Why isn't the identity community noodling something similar?
A SAS-70 is another form of document that could be converted into an XML schema. Instead of a word document, why couldn't a certifying party somehow sign the identity provider such that this is consumed within either SAML or OpenID interchanges? So far we have gotten a working group on level of assurance which is fundamental to the problem-space but we need to figure out how to put a little bit of non-repudiation behind many of the attributes.
Anyway, for solving the IdP discovery challenge, I believe that Information Cards is the best model publicly available. We simply need to figure out how to create the tipping point so that B2B sites are also full participants in the identity conversation...
Friday, May 21, 2010
Application Layer Intrusion Detection
The conversations around intrusion detection have traditionally occured within the world of network. I fundamentally believe that the conversation needs to move higher up the stack and be incorporated into enterprise applications.
I am a big fan of Static Analysis and other application security methods, but this doesn't cover all security challenges. The conversation needs to include the need to implement robust attack detection within the application to identify malicious users before they are successful in their attack. Just like in the real world, we would prefer to detect and prevent an attack instead of just responding after a compromise has occurred.
In order to detect and respond to malicious activity at the application layer we need to be able to monitor and understand a user’s actions within the application. This cannot be accomplished by either firewall or SSL as they provide no protection in this regard. A network-based intrusion detection platfor also will have no insight to our application specific traffic. Antivirus is also out of the question since this is a signature based approach that knows nothing of custom web application vulnerabilities.
Some may think that a web application firewall is a potential solution. A WAF is able to detect generic application attacks such as basic SQL injection attacks or common actions of a known attack sequence. While some detection is better than none, a generic product could never fully understand the intricacies of each custom web application.
Detection and response needs to be incorporated into the application itself. Ideally, it would be great if frameworks such as Spring, Struts, Ruby on Rails or other web application frameworks incorporated this, but this is missing in action. Within the application, there is unambigious visibility into the user initiating an action, the target of that action and whether that action should be allowed for that user.
The application is best positioned to identify attempts to circumvent security controls or use the application in an unintended manner. After we have determined that a particular user has malicious intent and is attempting to identify weaknesses, the application can respond and block the user from future access to the application, or take whatever other action is appropriate.
The rigor of response is a decision for each organization in relation to their tolerance for risk and specific needs for an application. However, it is clear that this level of detection capability is a must for any organization wishing to prevent skilled and persistent attackers from compromising their critical applications.
We of course must acknowledge that we don't just build applications but also buy them. The enterprise priority should include asking your strategic vendors to incorporate this as a requirement for future releases. Sadly, many security-oriented product offerings lack this type of capability. Ideal targets for such a deployment include federated identity platforms, identity provisioning and entitlements management products. In turn, product vendors should figure out how to include this type of scenario within conversations at security conferences and standards bodies. Events such as BlackHat, DefCon, Gartner Enterprise Security, Kantara and others come to mind.
Anyway, the OWASP community has been thinking on this challenge and I encourage people reading this blog to consider at least noodling what are the appropriate detection points. This conversation is equally relevant to the identity community as it is to the security community as it is to the privacy community as it is to the community who cares about uptime. Let's get the conversation started...
| | View blog reactionsI am a big fan of Static Analysis and other application security methods, but this doesn't cover all security challenges. The conversation needs to include the need to implement robust attack detection within the application to identify malicious users before they are successful in their attack. Just like in the real world, we would prefer to detect and prevent an attack instead of just responding after a compromise has occurred.
In order to detect and respond to malicious activity at the application layer we need to be able to monitor and understand a user’s actions within the application. This cannot be accomplished by either firewall or SSL as they provide no protection in this regard. A network-based intrusion detection platfor also will have no insight to our application specific traffic. Antivirus is also out of the question since this is a signature based approach that knows nothing of custom web application vulnerabilities.
Some may think that a web application firewall is a potential solution. A WAF is able to detect generic application attacks such as basic SQL injection attacks or common actions of a known attack sequence. While some detection is better than none, a generic product could never fully understand the intricacies of each custom web application.
Detection and response needs to be incorporated into the application itself. Ideally, it would be great if frameworks such as Spring, Struts, Ruby on Rails or other web application frameworks incorporated this, but this is missing in action. Within the application, there is unambigious visibility into the user initiating an action, the target of that action and whether that action should be allowed for that user.
The application is best positioned to identify attempts to circumvent security controls or use the application in an unintended manner. After we have determined that a particular user has malicious intent and is attempting to identify weaknesses, the application can respond and block the user from future access to the application, or take whatever other action is appropriate.
The rigor of response is a decision for each organization in relation to their tolerance for risk and specific needs for an application. However, it is clear that this level of detection capability is a must for any organization wishing to prevent skilled and persistent attackers from compromising their critical applications.
We of course must acknowledge that we don't just build applications but also buy them. The enterprise priority should include asking your strategic vendors to incorporate this as a requirement for future releases. Sadly, many security-oriented product offerings lack this type of capability. Ideal targets for such a deployment include federated identity platforms, identity provisioning and entitlements management products. In turn, product vendors should figure out how to include this type of scenario within conversations at security conferences and standards bodies. Events such as BlackHat, DefCon, Gartner Enterprise Security, Kantara and others come to mind.
Anyway, the OWASP community has been thinking on this challenge and I encourage people reading this blog to consider at least noodling what are the appropriate detection points. This conversation is equally relevant to the identity community as it is to the security community as it is to the privacy community as it is to the community who cares about uptime. Let's get the conversation started...
Wednesday, May 19, 2010
Thoughts on Adoption of Federated Identity Technologies
In conversations with Prateek Mishra, Vadim Lander, Kim Cameron and others over the last year or so, many are struggling to understand why federated identity technologies aren't being rapidly adopted. I figured I would share a few thoughts as to why...
Many people are aware that one of my current activities is in figuring out how to bring federated identity technology to the property & casualty insurance vertical, specifically targeted at independent insurance agents. In order to provide a little context as to my approach, I figured I should start with an overview.
An independent insurance agent can do business with a variety of carriers ranging from Travelers, AIG, Geico, Liberty Mutual, Progressive, OneBeacon and so on. Each of these carriers will have their own policies related to how often a password should change, its complexity and how often a previously used one could be reused. An independent insurance agent could have business relationships with 30 carriers or 300 carriers depending upon its business focus.
So, one can quickly conclude that this business model brings lots of challenges to end users in managing their passwords. Now consider why it is important for it to be done properly as a consumer.
Consider your interaction with an insurance agent where you want to get a homeowners and auto insurance quote. The agent will of course want to know lots of personally identifiable information such as your drivers license to ensure you are a good driver, your social security number such that they can do a credit check and of course may desire your credit card as a method for paying for the policy.
This insurance agent will want to know how far you drive to and from work which means he also may have a strong sense as to when you aren't home. He may know about all the goodies in your house especially items that have high street value ranging from jewelry to furs.
So, let's say you have your trusty policy in hand and get into an auto accident where you smack your head bleed all over the dash. Their of course will be a claims file containing medical information. In summary, the insurance ecosystem has more information that consumers are otherwise blissfully ignorant about.
Most people are worried about healthcare data and leakage. It has always been my opinion that this matters less than insurance. Ask yourself, which would be worse, someone knowing that you have erectile dysfunction or as Paul Madsen would say, your wife learning about you insuring a car she didn't know about...
Let's start with the premise that the business controls all the funding for IT. While a business person can understand the challenges of having too many passwords and probably could calculate support costs associated with this worst practice, they probably couldn't articulate a vision that sounds anything like what federated identity solves for.
Taking this thought one step further, IT generally speaking follows traditional habits. If a business analyst were assigned to capture requirements around federation such that this feels like a traditional IT project and top-down driven, what would they capture? Do you think most business analysts have a clue as to how to capture business requirements around federated identity? Most business analysts at best are barely capable of capturing basic security requirements for applications they are familiar with.
So, does this get connected by enterprise architects? The answer is maybe, but ask yourself what evidence exists that says the vast majority of enterprise architects even have security (other than compliance) on their radar? Enterprise architects tend to travel is certain circles. When was the last time you went to any conference on enterprise architecture where federated identity was discussed?
So, we can conclude that top-down more often that not will be a fail, so let's look at it from another dimension. Since the independent agent would want each carrier to implement federation capability consistently, how would they organize a community around this? Are they properly equipped to even put pressure on carriers to ensure consistent implementation?
Another lens would say that carriers should network with each other. Ever heard of Elliot Spitzer who believes that these types of interactions are collusion-oriented? Even if Attorney Generals decided to not be an impediment, how would one person in enterprise A even know to find the right person in enterprise B? The person in enterprise A could do basic research and attempt to contact the business but understand that human nature says that most people will not forward things to others until they understand it themselves. We also concluded that federation is a challenge for business to understand. Does person in enterprise A spend his time on educating business customers in enterprise B? What CEO in their right mind would allow this to happen?
OK, so you are probably have concluded we haven't leveraged vendors to help us with this challenge. In order for a Microsoft, Oracle, Ping Identity, RSA, etc to assist with this, they first must understand what your business is. I went down this path myself and found that all of the vendors knew I worked for an insurance company but none of them could tell within their own CRM systems what kind of insurance company I work for. They couldn't distinguish between P&C, Life, Health, Re-insurance, etc which is important to the use-case.
In this model, Aetna may have merit in coming up with standards used in health insurance along with WellPoint, Cigna, UnitedHealthCare, etc but it wouldn't make sense for Aetna to work with AllState, Travelers or Progressive in this regard.
Now ask yourself, do you think I would be successful in asking for specific contacts from a vendor so that I can have a conversation above a reference check for their product? So, even getting federation going with those who have capability to federate is problematic. A typical engineer would not have this type of contact information and could only be gathered by sales people. Do you think asking someone who makes their pay based on selling would take the effort to unify people that wouldn't result in a sale?
If you ask how would one get a sales person engaged? The answer is for employee of Enterprise A to introduce the sales person to Enterprise B. This would allow enterprise A to not spend time educating business people in Enterprise B, but this still would at some level turn enterprise A into a lead generation mechanism for vendors. Is this the right answer?
While I haven't covered all the permutations, I think I wanted to share a sense as to why federation adoption is slow. SAML 1.0 was introduced ten years ago yet we still see few industry-wide federations. The only thing that will overcome this challenge is if we all in the identity community agree to change the conversation. We need to talk less now about interoperability and more about best practices around community formation.
The next blog entry will address other challenges...
| | View blog reactionsMany people are aware that one of my current activities is in figuring out how to bring federated identity technology to the property & casualty insurance vertical, specifically targeted at independent insurance agents. In order to provide a little context as to my approach, I figured I should start with an overview.
An independent insurance agent can do business with a variety of carriers ranging from Travelers, AIG, Geico, Liberty Mutual, Progressive, OneBeacon and so on. Each of these carriers will have their own policies related to how often a password should change, its complexity and how often a previously used one could be reused. An independent insurance agent could have business relationships with 30 carriers or 300 carriers depending upon its business focus.
So, one can quickly conclude that this business model brings lots of challenges to end users in managing their passwords. Now consider why it is important for it to be done properly as a consumer.
Consider your interaction with an insurance agent where you want to get a homeowners and auto insurance quote. The agent will of course want to know lots of personally identifiable information such as your drivers license to ensure you are a good driver, your social security number such that they can do a credit check and of course may desire your credit card as a method for paying for the policy.
This insurance agent will want to know how far you drive to and from work which means he also may have a strong sense as to when you aren't home. He may know about all the goodies in your house especially items that have high street value ranging from jewelry to furs.
So, let's say you have your trusty policy in hand and get into an auto accident where you smack your head bleed all over the dash. Their of course will be a claims file containing medical information. In summary, the insurance ecosystem has more information that consumers are otherwise blissfully ignorant about.
Most people are worried about healthcare data and leakage. It has always been my opinion that this matters less than insurance. Ask yourself, which would be worse, someone knowing that you have erectile dysfunction or as Paul Madsen would say, your wife learning about you insuring a car she didn't know about...
Let's start with the premise that the business controls all the funding for IT. While a business person can understand the challenges of having too many passwords and probably could calculate support costs associated with this worst practice, they probably couldn't articulate a vision that sounds anything like what federated identity solves for.
Taking this thought one step further, IT generally speaking follows traditional habits. If a business analyst were assigned to capture requirements around federation such that this feels like a traditional IT project and top-down driven, what would they capture? Do you think most business analysts have a clue as to how to capture business requirements around federated identity? Most business analysts at best are barely capable of capturing basic security requirements for applications they are familiar with.
So, does this get connected by enterprise architects? The answer is maybe, but ask yourself what evidence exists that says the vast majority of enterprise architects even have security (other than compliance) on their radar? Enterprise architects tend to travel is certain circles. When was the last time you went to any conference on enterprise architecture where federated identity was discussed?
So, we can conclude that top-down more often that not will be a fail, so let's look at it from another dimension. Since the independent agent would want each carrier to implement federation capability consistently, how would they organize a community around this? Are they properly equipped to even put pressure on carriers to ensure consistent implementation?
Another lens would say that carriers should network with each other. Ever heard of Elliot Spitzer who believes that these types of interactions are collusion-oriented? Even if Attorney Generals decided to not be an impediment, how would one person in enterprise A even know to find the right person in enterprise B? The person in enterprise A could do basic research and attempt to contact the business but understand that human nature says that most people will not forward things to others until they understand it themselves. We also concluded that federation is a challenge for business to understand. Does person in enterprise A spend his time on educating business customers in enterprise B? What CEO in their right mind would allow this to happen?
OK, so you are probably have concluded we haven't leveraged vendors to help us with this challenge. In order for a Microsoft, Oracle, Ping Identity, RSA, etc to assist with this, they first must understand what your business is. I went down this path myself and found that all of the vendors knew I worked for an insurance company but none of them could tell within their own CRM systems what kind of insurance company I work for. They couldn't distinguish between P&C, Life, Health, Re-insurance, etc which is important to the use-case.
In this model, Aetna may have merit in coming up with standards used in health insurance along with WellPoint, Cigna, UnitedHealthCare, etc but it wouldn't make sense for Aetna to work with AllState, Travelers or Progressive in this regard.
Now ask yourself, do you think I would be successful in asking for specific contacts from a vendor so that I can have a conversation above a reference check for their product? So, even getting federation going with those who have capability to federate is problematic. A typical engineer would not have this type of contact information and could only be gathered by sales people. Do you think asking someone who makes their pay based on selling would take the effort to unify people that wouldn't result in a sale?
If you ask how would one get a sales person engaged? The answer is for employee of Enterprise A to introduce the sales person to Enterprise B. This would allow enterprise A to not spend time educating business people in Enterprise B, but this still would at some level turn enterprise A into a lead generation mechanism for vendors. Is this the right answer?
While I haven't covered all the permutations, I think I wanted to share a sense as to why federation adoption is slow. SAML 1.0 was introduced ten years ago yet we still see few industry-wide federations. The only thing that will overcome this challenge is if we all in the identity community agree to change the conversation. We need to talk less now about interoperability and more about best practices around community formation.
The next blog entry will address other challenges...
Tuesday, May 18, 2010
Thoughts on SPML 3.0
Much of the discussion around identity provisioning is centered on employees where the authoritative source of data is usually an HR system. As the conversation moves away from the employee-demographic to business partners, several additional things need to be considered. I am glad to see that SPML is not on life support and that the identity community is committed to improving the OASIS SPML specification. I figured I would share a few thoughts on what I would like to see SPML 3.0 address...
Metadata
Currently, the SPML specification describes the operations that can occur against a given user schema but does not define either a model for any particular user nor even provides a mechanism to discover supported models. If companies wanted to expose their SPML services to their business partners, they would need to first manually define what the user model looks like and then duplicate the information within each implementation. This approach is fragile and error-proven.
The ability for one identity management tool to understand the user model that another identity management tool is best supported by developing interoperable metadata exchange capabilities. At some level, the SAML specification supports this construct and it would be good if SPML supported something similar.
Virtualization
Their is an implied coupling between SPML operations and the underlying data store. For example, if you wanted to store a person and an organization, you would need to potentially invoke this as two separate operations. More importantly, one of the general principles of a service-oriented architecture is to avoid coupling, it would be bad form for you to describe your internal data structure externally and therefore a virtualization layer is needed.
Many enterprises will be coerced into thinking that virtualization is solely a construct that separate the SPML gateway from its underlying store. Others could argue that virtualization in this regard really shouldn't be a separate product but something baked into each implementation especially to aid in describing the metadata requirements. Either way, the need for provisioning to operate supporting coarse-grained constructs that aren't one-to-one with the underlying implementation is a key consideration.
Entitlements
Imagine a scenario where salesforce.com exposes a SPML gateway to allow its clients to support provisioning and de-provisioning activities. This begs several questions related to entitlements such as can Client A provision an account that allows access to Client B's data? We all know the contractual answer, but in terms of how this is enforced within current SPML solutions is all over the place. Anytime, you need to support multitenancy constructs this issue is going to raise its head.
One can think about whether SPML implementations support industry specifications such as xACML but that is an oversimplification. Again, since SPML only defines the operations but doesn't define a common way to even understand who is making the request nor having any understanding of the target resource, an entitlements model is left up to the discretion of the implementer and may introduce additional security risks.
Minimally, it would be great if products defined the right extension points such that if an end-customer wanted to do something other than deferring to an XACML-based they could pull out a trusty SDK an implement a few nterfaces in order to make this happen.
Attestation
The requirement for an organization to provide attestation capabilities for whomever accesses their IT ecosystem is at the center of many organizational SoX controls. While enterprises can be enterprisey in their thinking and insular in their focus, shouldn't they also be thinking about how their business partners attest to access to their systems as well? Within an IT ecosystem, your systems may not only be under SoX scope for you but also your business partners as well and having the right interfaces to support attestation in a federated manner is becoming increasingly important.
Attestation standards usually specify standards of reporting. Within a federated provisioning model, this include exposing statistics on various provisioning workflows that include success/failure rates filtered for a given partner/call. It may also define obligations analogous to how XACML defines this notion where certain interactions with partners or transaction types may have additional logging/auditing/alerting requirements around them. For example, if I work for a major Wall Street Bank and I need access to a trading platform, one may want to define a different level of auditing if I am requesting access to a foreign currency trading platform than other levels of access since the risk profile is different.
Each business will have their own take on what needs to be audited but we need a general way to record the obligations of different parties in a federated provisioning scenario. This all should be driven by standards.
| | View blog reactionsMetadata
Currently, the SPML specification describes the operations that can occur against a given user schema but does not define either a model for any particular user nor even provides a mechanism to discover supported models. If companies wanted to expose their SPML services to their business partners, they would need to first manually define what the user model looks like and then duplicate the information within each implementation. This approach is fragile and error-proven.
The ability for one identity management tool to understand the user model that another identity management tool is best supported by developing interoperable metadata exchange capabilities. At some level, the SAML specification supports this construct and it would be good if SPML supported something similar.
Virtualization
Their is an implied coupling between SPML operations and the underlying data store. For example, if you wanted to store a person and an organization, you would need to potentially invoke this as two separate operations. More importantly, one of the general principles of a service-oriented architecture is to avoid coupling, it would be bad form for you to describe your internal data structure externally and therefore a virtualization layer is needed.
Many enterprises will be coerced into thinking that virtualization is solely a construct that separate the SPML gateway from its underlying store. Others could argue that virtualization in this regard really shouldn't be a separate product but something baked into each implementation especially to aid in describing the metadata requirements. Either way, the need for provisioning to operate supporting coarse-grained constructs that aren't one-to-one with the underlying implementation is a key consideration.
Entitlements
Imagine a scenario where salesforce.com exposes a SPML gateway to allow its clients to support provisioning and de-provisioning activities. This begs several questions related to entitlements such as can Client A provision an account that allows access to Client B's data? We all know the contractual answer, but in terms of how this is enforced within current SPML solutions is all over the place. Anytime, you need to support multitenancy constructs this issue is going to raise its head.
One can think about whether SPML implementations support industry specifications such as xACML but that is an oversimplification. Again, since SPML only defines the operations but doesn't define a common way to even understand who is making the request nor having any understanding of the target resource, an entitlements model is left up to the discretion of the implementer and may introduce additional security risks.
Minimally, it would be great if products defined the right extension points such that if an end-customer wanted to do something other than deferring to an XACML-based they could pull out a trusty SDK an implement a few nterfaces in order to make this happen.
Attestation
The requirement for an organization to provide attestation capabilities for whomever accesses their IT ecosystem is at the center of many organizational SoX controls. While enterprises can be enterprisey in their thinking and insular in their focus, shouldn't they also be thinking about how their business partners attest to access to their systems as well? Within an IT ecosystem, your systems may not only be under SoX scope for you but also your business partners as well and having the right interfaces to support attestation in a federated manner is becoming increasingly important.
Attestation standards usually specify standards of reporting. Within a federated provisioning model, this include exposing statistics on various provisioning workflows that include success/failure rates filtered for a given partner/call. It may also define obligations analogous to how XACML defines this notion where certain interactions with partners or transaction types may have additional logging/auditing/alerting requirements around them. For example, if I work for a major Wall Street Bank and I need access to a trading platform, one may want to define a different level of auditing if I am requesting access to a foreign currency trading platform than other levels of access since the risk profile is different.
Each business will have their own take on what needs to be audited but we need a general way to record the obligations of different parties in a federated provisioning scenario. This all should be driven by standards.
Static Analysis Worst Practices
We have been using static analysis for the last couple of years and I think I have uncovered a few worst practices that I wanted to share in hopes that others may avoid the mistakes we have made...
Many of the static analysis tools, whether Fortify Software, Ounce Labs, Coverity or others tend to be bought under the misguided belief that they automate the code review process. Reality states that these tools are great in terms of aiding software security professionals in finding defects, they aren't substitutes.
One of the biggest challenges in all of these tools is the amount of defects found by them. It takes human judgment in order to understand how bad a particular application may be in terms of its security posture above and beyond the metrics it produces. For example, the application with the highest amount of findings is actually pretty good in terms of its security posture and the application that has the least amount of findings is the one I would recommend a wholesale rewrite.
More importantly, the metrics produced by static analysis tools in terms of their dashboard do not even roughly correlate to what IT executives need in order to make decisions. For example, a security professional will want to make a decision based on various risk rating criteria ranging from difficulty of discovery and the skill required to exploit and these tools simply provide no visibility in this regard.
Security professionals tend to not just look at a one-off instance of a particular scan but may also study the longer term trends of an application. Think about what happens when Microsoft releases a patch for an exploit. They may want to go "backwards" and figure out what prior releases the exploit can take advantage of. The notion of backward-chaining and inferencing simply isn't built into most products.
Are you familiar with the concept of a buildforge where the goal is to automate how software is built in order to guarantee repeatable outcome? Many of the static analysis tools assume a developer is driving and not part of a larger process. As an agilist, I am a savage believer in the notion of frequent and automated software builds and static analysis puts a manual step into the mix.
How many dashboards does an enterprise need? Should I have a separate dashboard for static analysis tools? Should the findings be merged with those acquired from web vulnerability scanners? Should this information be rolled up into GRC tools? Should this information be incorporated into EA tools such as Troux and Alfabet such that an enterprise can do strategic planning on its portfolio where security is just one aspect of an application?
We need to have honest conversations on the strengths and limitations of static analysis. Otherwise it will result in another oversold enterprise tool and security posture of the enterprise will suffer...
| | View blog reactionsMany of the static analysis tools, whether Fortify Software, Ounce Labs, Coverity or others tend to be bought under the misguided belief that they automate the code review process. Reality states that these tools are great in terms of aiding software security professionals in finding defects, they aren't substitutes.
One of the biggest challenges in all of these tools is the amount of defects found by them. It takes human judgment in order to understand how bad a particular application may be in terms of its security posture above and beyond the metrics it produces. For example, the application with the highest amount of findings is actually pretty good in terms of its security posture and the application that has the least amount of findings is the one I would recommend a wholesale rewrite.
More importantly, the metrics produced by static analysis tools in terms of their dashboard do not even roughly correlate to what IT executives need in order to make decisions. For example, a security professional will want to make a decision based on various risk rating criteria ranging from difficulty of discovery and the skill required to exploit and these tools simply provide no visibility in this regard.
Security professionals tend to not just look at a one-off instance of a particular scan but may also study the longer term trends of an application. Think about what happens when Microsoft releases a patch for an exploit. They may want to go "backwards" and figure out what prior releases the exploit can take advantage of. The notion of backward-chaining and inferencing simply isn't built into most products.
Are you familiar with the concept of a buildforge where the goal is to automate how software is built in order to guarantee repeatable outcome? Many of the static analysis tools assume a developer is driving and not part of a larger process. As an agilist, I am a savage believer in the notion of frequent and automated software builds and static analysis puts a manual step into the mix.
How many dashboards does an enterprise need? Should I have a separate dashboard for static analysis tools? Should the findings be merged with those acquired from web vulnerability scanners? Should this information be rolled up into GRC tools? Should this information be incorporated into EA tools such as Troux and Alfabet such that an enterprise can do strategic planning on its portfolio where security is just one aspect of an application?
We need to have honest conversations on the strengths and limitations of static analysis. Otherwise it will result in another oversold enterprise tool and security posture of the enterprise will suffer...
Wednesday, May 12, 2010
What does it take to recruit James McGovern?
I receive calls from recruiters all the time yet infrequently return their calls due to a variety of factors. I wanted to outline what I believe are some perspectives on what it would take to recruit me and others like me...
Let's start with some analysis of the most typical recruiting call I receive which starts out with acknowledging that I am an Enterprise Architect for a large company that sells insurance. What do you think are the odds that I would like to transition to another large company that sells insurance in the same exact role I am doing today with no real career path (regardless of what the HR documentation says)?
Do you think that a few thousand dollars more a year is enough? While the vast majority of candidates are money chasers, do you think that I am? I am passionate about leveraging technology to realize successful business outcomes and therefore you are more than likely to catch my attention by telling me that my potential new employer is leading edge and not a follower when it comes to technology adoption.
Have you spent any time figuring out that there are some enterprise architects who are savage about process and romance notions such as outsourcing, CMMI, rationalization and other cost-savings constructs while other enterprise architects prefer to instead be on the side of innovation and building out new capability? Which side do you think I reside? It feels as if recruiters almost never know this aspect of the position.
Generally speaking, I tend to return the calls of recruiters who work for the employer over those who are headhunters for a variety of reasons. Mainly, I tend to be somewhat skeptical of headhunters in terms of being successful as the bar tends to be set a lot higher. Headhunters may charge 30% of first year salary as a fee to their clients and if a client can get a candidate without paying the fee then they will which makes it kinda dumb for any candidate to want to work with them. I have always advised my friends to avoid headhunters for positions that are with large companies and to instead apply via job boards or other direct methods. Headhunters should only be used to find jobs in companies outside the Fortune 2000.
Another quirk of working with a headhunter is that it actually takes more energy. They will send you lots of questionnaires that need to be completed before your paperwork is submitted to their clients. They will ask you to make numerous changes to your resume. While this may put you in a better light, it also makes the job search become more extended than it need be. I am of the school of thought that a headhunter should take charge of editing of resumes to improve readability on the candidates behalf and not ask the candidates to do this themselves especially if the candidate is already employed full-time. This is the headhunter's full-time job where at best the candidate would work on such activities after-hours when they aren't at their prime.
If you are an IT employee for any length of time, you may have heard of the likes of Martin Fowler, Grady Booch, James Gosling and so on. Sadly, the vast majority of recruiters haven't heard of these individuals and may only think of them as a name and a skill. If a recruiter doesn't truly appreciate whom they are communicating with and desire for everyone to be walked through the same process then end clients will suffer as well. Recruiters need to do a better job of being able to distinguish between a rockstar and a nobody before a discussion of resume even occurs.
The one aspect of managing a career is the ability to know what one wants to be when you grow up. Many have attempted to articulate this in terms of an objective section on their resume but this doesn't really work in most scenarios.
For example, there are several alternatives that I would be very open to. I would love to become an industry analyst and work for a firm that allows me to work with end customers. The role of enterprise architect by definition requires you to have strong relationships and interactions with C-level executives and therefore is compatible. I would be equally open to being a product manager or even CTO of a product company. The role of enterprise architect as overseer of a portfolio of products is also inline with this role. I think you are starting to see a pattern emerge that simply isn't considered by most recruiters.
There is a big distinction between travel and commute in my mind and these words shouldn't be used interchangeably. I am willing to travel say 25% but that is different than commuting. Many of the industry analysts I know travel where they visit one client one week and a different client the following week, where consulting firms such as Accenture do what I refer to as commuting. It is guaranteed that the client I see on Monday is the same client that I will see next Monday and the following and so on. See the difference?
So, if you see opportunities that fit my background, please do not hesitate to contact me as I am easily recruitable. Hopefully you have gained a few perspectives on what it takes to recruit top talent...
| | View blog reactionsLet's start with some analysis of the most typical recruiting call I receive which starts out with acknowledging that I am an Enterprise Architect for a large company that sells insurance. What do you think are the odds that I would like to transition to another large company that sells insurance in the same exact role I am doing today with no real career path (regardless of what the HR documentation says)?
Do you think that a few thousand dollars more a year is enough? While the vast majority of candidates are money chasers, do you think that I am? I am passionate about leveraging technology to realize successful business outcomes and therefore you are more than likely to catch my attention by telling me that my potential new employer is leading edge and not a follower when it comes to technology adoption.
Have you spent any time figuring out that there are some enterprise architects who are savage about process and romance notions such as outsourcing, CMMI, rationalization and other cost-savings constructs while other enterprise architects prefer to instead be on the side of innovation and building out new capability? Which side do you think I reside? It feels as if recruiters almost never know this aspect of the position.
Generally speaking, I tend to return the calls of recruiters who work for the employer over those who are headhunters for a variety of reasons. Mainly, I tend to be somewhat skeptical of headhunters in terms of being successful as the bar tends to be set a lot higher. Headhunters may charge 30% of first year salary as a fee to their clients and if a client can get a candidate without paying the fee then they will which makes it kinda dumb for any candidate to want to work with them. I have always advised my friends to avoid headhunters for positions that are with large companies and to instead apply via job boards or other direct methods. Headhunters should only be used to find jobs in companies outside the Fortune 2000.
Another quirk of working with a headhunter is that it actually takes more energy. They will send you lots of questionnaires that need to be completed before your paperwork is submitted to their clients. They will ask you to make numerous changes to your resume. While this may put you in a better light, it also makes the job search become more extended than it need be. I am of the school of thought that a headhunter should take charge of editing of resumes to improve readability on the candidates behalf and not ask the candidates to do this themselves especially if the candidate is already employed full-time. This is the headhunter's full-time job where at best the candidate would work on such activities after-hours when they aren't at their prime.
If you are an IT employee for any length of time, you may have heard of the likes of Martin Fowler, Grady Booch, James Gosling and so on. Sadly, the vast majority of recruiters haven't heard of these individuals and may only think of them as a name and a skill. If a recruiter doesn't truly appreciate whom they are communicating with and desire for everyone to be walked through the same process then end clients will suffer as well. Recruiters need to do a better job of being able to distinguish between a rockstar and a nobody before a discussion of resume even occurs.
The one aspect of managing a career is the ability to know what one wants to be when you grow up. Many have attempted to articulate this in terms of an objective section on their resume but this doesn't really work in most scenarios.
For example, there are several alternatives that I would be very open to. I would love to become an industry analyst and work for a firm that allows me to work with end customers. The role of enterprise architect by definition requires you to have strong relationships and interactions with C-level executives and therefore is compatible. I would be equally open to being a product manager or even CTO of a product company. The role of enterprise architect as overseer of a portfolio of products is also inline with this role. I think you are starting to see a pattern emerge that simply isn't considered by most recruiters.
There is a big distinction between travel and commute in my mind and these words shouldn't be used interchangeably. I am willing to travel say 25% but that is different than commuting. Many of the industry analysts I know travel where they visit one client one week and a different client the following week, where consulting firms such as Accenture do what I refer to as commuting. It is guaranteed that the client I see on Monday is the same client that I will see next Monday and the following and so on. See the difference?
So, if you see opportunities that fit my background, please do not hesitate to contact me as I am easily recruitable. Hopefully you have gained a few perspectives on what it takes to recruit top talent...
Tuesday, May 04, 2010
Enterprise Architecture: Exercising your right to remain silent...
There are days when I hear others complain about things and feel their challenges are larger than life. I remind them that there are billions of people on the planet who don't have access to clean water, food or shelter and their problems are minor in comparison...
There is absolutely nothing in the enterprise that is worthy of being stressed out. No matter how your boss or your peers show lack of respect, your personal self-worth as an individual doesn't change. A wise industry analyst who resides in DC and is also named James once told me that no matter what happens, no one can take away your personal brand. This is something you should remember and apply to your daily life.
There is solace is understanding the human condition and considering the well-being of others. Maybe you should feel guilty not because of anything your could have accomplished at work, but because of things you didn't accomplish related to helping others?
Have you considered that being charitable at home, may improve your work situation? Even if you have no money to spare, you could at least take pause and think about what others have to do in order to make a living. Please take a look at the photos below, reflect on yourself as a human and then reconsider your condition and relationship with others...
| | View blog reactions
There is absolutely nothing in the enterprise that is worthy of being stressed out. No matter how your boss or your peers show lack of respect, your personal self-worth as an individual doesn't change. A wise industry analyst who resides in DC and is also named James once told me that no matter what happens, no one can take away your personal brand. This is something you should remember and apply to your daily life.
There is solace is understanding the human condition and considering the well-being of others. Maybe you should feel guilty not because of anything your could have accomplished at work, but because of things you didn't accomplish related to helping others?
Have you considered that being charitable at home, may improve your work situation? Even if you have no money to spare, you could at least take pause and think about what others have to do in order to make a living. Please take a look at the photos below, reflect on yourself as a human and then reconsider your condition and relationship with others...
Sunday, May 02, 2010
Enterprise Architecture: Recognizing Top Talent
I previously blogged on Enterprises suck at hiring top talent and wanted to continue the conversation with a few additional insights...
The vast majority of the time when my phone rings and it is a recruiter on the other end, they usually make multiple mistakes in assessing the worth of talent. For example, on my resume I include the fact that I used to write the Ask Doctor Java column for Java Developers Journal which means that recruiters who use keyword searching alone will contact me. What they haven't considered is the fact that my resume also clearly indicates that I am an Enterprise Architect and have been so for the last ten years where logic may indicate that I am probably somewhat higher up the food chain.
Some recruiters never bother to find out if the position truly requires top talent or whether they require someone with mediocre skills. Let's face it, some jobs will never be of interest to those who are truly talented and it is in the employers best interest to know if their work is exciting or boring in the grand scheme of things.
As I have previously stated, an enterprise needs to manage top talent regardless if they are an employee or work for one of your outsourcing firms in India. I frequently observe a scenario exhibited by many IT executives that goes beyond blissful ignorance. Many think that the opportunity for a new generation in India to be gainfully employed in ways that their parents could have only dreamt of is the opportunity to outsource suboptimal work. Reality states that if you are a motivated individual anywhere on the planet and have the opportunity to work on building new software for say Microsoft, Oracle, etc or even developing applications for Wall Street that require pushing the envelope, why would you think someone should be grateful for the opportunity to work o a forty-year old COBOL application?
Staff turnover in India is very high and just like the American generation that preceeded them, they aren't job hopping to solely chase money but want interesting work. No matter how you spin it, if your industry isn't as interesting as another vertical then you may be doomed to finding mediocre talent. If you combine this with outdated technologies can you expect nothing but turbulence in your offshore staff?
If the world is global then you have to acknowledge that outsourcing requires more than just rate arbitrage, but also requires gaining the hearts and minds of those spread throughout the planet. Ask yourself why your recruiting thinking is so local in nature?
Have you ever considered the fact that you may already have top talent within your enterprise but have blinders on? The funny thing about top talent in traditional enterprises is that they usually are beatdown to mediocrity and may not show up on the annual review process as high performers but yet everyone has the utmost respect for their ability to deliver and think outside the box.
Let's say you were lucky enough to have James Gosling, Martin Fowler, Grady Booch and Joel Spolsky on your staff. Above and beyond the job description would you know how to leverage their talent? Would you ask James Gosling to explain the merits of Java Generics to a CIO who would immediately beat him down for being too technical? Would you ask Grady Booch to take charge of all the documentation writing since he is really good at drawing UML? Would you ask Joel Spolsky to work with your arduous software release process since he knows a little bit about building software?
If you are reading this and don't appreciate the silliness, then you are more than likely part of the problem. Recognizing the best and brightest within IT is your job and this emphatically proves that you may not be worthy of your role...
| | View blog reactionsThe vast majority of the time when my phone rings and it is a recruiter on the other end, they usually make multiple mistakes in assessing the worth of talent. For example, on my resume I include the fact that I used to write the Ask Doctor Java column for Java Developers Journal which means that recruiters who use keyword searching alone will contact me. What they haven't considered is the fact that my resume also clearly indicates that I am an Enterprise Architect and have been so for the last ten years where logic may indicate that I am probably somewhat higher up the food chain.
Some recruiters never bother to find out if the position truly requires top talent or whether they require someone with mediocre skills. Let's face it, some jobs will never be of interest to those who are truly talented and it is in the employers best interest to know if their work is exciting or boring in the grand scheme of things.
As I have previously stated, an enterprise needs to manage top talent regardless if they are an employee or work for one of your outsourcing firms in India. I frequently observe a scenario exhibited by many IT executives that goes beyond blissful ignorance. Many think that the opportunity for a new generation in India to be gainfully employed in ways that their parents could have only dreamt of is the opportunity to outsource suboptimal work. Reality states that if you are a motivated individual anywhere on the planet and have the opportunity to work on building new software for say Microsoft, Oracle, etc or even developing applications for Wall Street that require pushing the envelope, why would you think someone should be grateful for the opportunity to work o a forty-year old COBOL application?
Staff turnover in India is very high and just like the American generation that preceeded them, they aren't job hopping to solely chase money but want interesting work. No matter how you spin it, if your industry isn't as interesting as another vertical then you may be doomed to finding mediocre talent. If you combine this with outdated technologies can you expect nothing but turbulence in your offshore staff?
If the world is global then you have to acknowledge that outsourcing requires more than just rate arbitrage, but also requires gaining the hearts and minds of those spread throughout the planet. Ask yourself why your recruiting thinking is so local in nature?
Have you ever considered the fact that you may already have top talent within your enterprise but have blinders on? The funny thing about top talent in traditional enterprises is that they usually are beatdown to mediocrity and may not show up on the annual review process as high performers but yet everyone has the utmost respect for their ability to deliver and think outside the box.
Let's say you were lucky enough to have James Gosling, Martin Fowler, Grady Booch and Joel Spolsky on your staff. Above and beyond the job description would you know how to leverage their talent? Would you ask James Gosling to explain the merits of Java Generics to a CIO who would immediately beat him down for being too technical? Would you ask Grady Booch to take charge of all the documentation writing since he is really good at drawing UML? Would you ask Joel Spolsky to work with your arduous software release process since he knows a little bit about building software?
If you are reading this and don't appreciate the silliness, then you are more than likely part of the problem. Recognizing the best and brightest within IT is your job and this emphatically proves that you may not be worthy of your role...
