To all three of my readers out there, I'm sad to say that this will be my last post for this blog.
We now have a policy stating that all external communications have to be run through our PR department. Since I'm not comfortable having my blog reviewed, I'm going to stop this one.
No need to weep in despair, however. I will be blogging under another name and another account, so keep a lookout.
Sincerest Regards,
Kelly A. Shaw
Monday, June 23, 2008
Thursday, June 5, 2008
IDC says HR to help Web 2.0 adoption. Um...what?
I just read an article by INQUIRER.net writer Lawrence Casiraya that had me raising my eyebrows. He interviewed IDC's Shalini Verma about the concept of "unified communications" and how Web 2.0 technologies such as social networking can help distributed organizations collaborate more effectively.
Here's the money quote.
What was Verma thinking? HR, together with IT, have been the main forces preventing adoption of Web 2.0 technologies in the workplace. According to Verma, HR should conduct a survey to find out what technologies are already being used and then make a plan for company-wide adoption of the most useful tools.
Well, I doubt that will work. Pretend we are listening to a conversation between two 'screenagers' when they get a survey from HR...
Nancy Networker: Did you see this survey from HR? They're trying to find out what sort of web apps we use. Why do they want to know?
Wally Widgetuser: (Smirking knowingly to Nancy) The survey says it's because they want to help us collaborate more effectively across the company.
Nancy and Wally have a good, cynical laugh.
Nancy: Well, I'm not telling them anything. The last thing I need is for them to shut down Facebook. It's the only way I keep in touch with the guys in Thailand.
Wally: You got that right. If I tell them I'm building mashups to keep track of my customer information, they'd freak.
Nancy: I'm just going to say I use Google Docs. I can live without them if HR and IT shut them down.
...
OK, the situation may not be that bad, but I'd wager that, given HR's history, there won't be a lot of trust between HR and the employees.
What's the answer?
I think HR could take the lead, but they'll have to do some groundwork first to establish some trust and credibility with the rest of the organization. Executive sponsorship wouldn't hurt either. In my own case, I spent well over a year blogging under a different name, knowing I'd be shut down if HR found out. I came out of the closet when Serena's executive leadership started promoting the use of social networking.
In addition to getting very visible executive support, HR could start publishing internal case studies about how people in the company use Web 2.0 to promote collaboration. Maybe someone in HR uses pbwiki to collaborate on ideas for the company picnic. Maybe someone in PR uses Second Life to conduct press conferences. (OK, that one's off the wall.) Perhaps someone in sales uses a mashup to get information before a customer call. If HR spends some time up front promoting the use of these collaborative tools, then maybe they will be trusted.
Maybe.
But we all remember when HR shut down MySpace, told us we couldn't blog, and forbade us from giving recommendations on LinkedIn. They've got a ways to go before we trust them with the dark secret that we use OpenKapow to scrape competitive information, or that we swap musical stations with clients on Pandora.
Here's the money quote.
So how can businesses begin to embrace Web 2.0? The task may fall into the hands of the human resource department.
What was Verma thinking? HR, together with IT, have been the main forces preventing adoption of Web 2.0 technologies in the workplace. According to Verma, HR should conduct a survey to find out what technologies are already being used and then make a plan for company-wide adoption of the most useful tools.
Well, I doubt that will work. Pretend we are listening to a conversation between two 'screenagers' when they get a survey from HR...
Nancy Networker: Did you see this survey from HR? They're trying to find out what sort of web apps we use. Why do they want to know?
Wally Widgetuser: (Smirking knowingly to Nancy) The survey says it's because they want to help us collaborate more effectively across the company.
Nancy and Wally have a good, cynical laugh.
Nancy: Well, I'm not telling them anything. The last thing I need is for them to shut down Facebook. It's the only way I keep in touch with the guys in Thailand.
Wally: You got that right. If I tell them I'm building mashups to keep track of my customer information, they'd freak.
Nancy: I'm just going to say I use Google Docs. I can live without them if HR and IT shut them down.
...
OK, the situation may not be that bad, but I'd wager that, given HR's history, there won't be a lot of trust between HR and the employees.
What's the answer?
I think HR could take the lead, but they'll have to do some groundwork first to establish some trust and credibility with the rest of the organization. Executive sponsorship wouldn't hurt either. In my own case, I spent well over a year blogging under a different name, knowing I'd be shut down if HR found out. I came out of the closet when Serena's executive leadership started promoting the use of social networking.
In addition to getting very visible executive support, HR could start publishing internal case studies about how people in the company use Web 2.0 to promote collaboration. Maybe someone in HR uses pbwiki to collaborate on ideas for the company picnic. Maybe someone in PR uses Second Life to conduct press conferences. (OK, that one's off the wall.) Perhaps someone in sales uses a mashup to get information before a customer call. If HR spends some time up front promoting the use of these collaborative tools, then maybe they will be trusted.
Maybe.
But we all remember when HR shut down MySpace, told us we couldn't blog, and forbade us from giving recommendations on LinkedIn. They've got a ways to go before we trust them with the dark secret that we use OpenKapow to scrape competitive information, or that we swap musical stations with clients on Pandora.
Monday, June 2, 2008
News from the mashup trenches
I’ve neglected this blog for a while, and now it’s time to get back to it. I didn’t think changing jobs would have much of an effect on my blogging output. Wrong again, Shaw. These days I have to do my reading and blogging mostly after hours, and that does change the dynamic. What takes priority, doing laundry, weeding the garden, helping with homework, balancing the checkbook, playing fetch with the dog, splitting wood, or...writing this blog? I'm afraid lately it's been those other things, and I'm sorry.
On the bright side, I’ve been in the trenches more than I have been in the past couple of years. It’s one thing to read analyst reports, discuss findings with customers and partners, write academic papers and pontificate from on high. It’s another to jump in and actually develop mashups. It is definitely harder to view the entire industry from a trench. Especially in the context of a fixed price contract. On the other hand, I’ve become reacquainted with the reason I went into technology in the first place: I enjoy it. I’ve written more applications (Don't be fooled. Mashups are applications.) in the past couple of months than in the past two years combined.
In a departure from my standard mashup posts, I’d like to share some things I’ve learned about mashups in the past few weeks rather than commenting on mashup news or reviewing some new mashup tool. Some of my experiences have reinforced what I thought before I embarked on this change in job title. Some have made me change my thinking, and in ways that might not make my current employer happy. Sorry in advance, Serena Software, if what I have to say doesn't agree with our marketing message.
First, I’d like to talk about the idea that mashups will allow the business to deploy their own applications without having to bother IT. I never thought this would work. After all, even applications in the tail will need access to back-end systems. Even applications in the tail will need version control of some sort. Even applications in the tail will need governance, even if that governance is light-handed compared to governance used to manage more strategic applications built by IT itself. After my time in the trenches, I’m even more convinced that mashup development has, at the very least, to be a loose partnership between the business and IT.
Let me give you an example.
I built a series of mashups as a prototype for a hardware technology company who wanted to get better control of their rebate program. It was a very intense three-day engagement where we spent the entire day working with the customer to understand their business problems, and then I got to spend the nights building mashup prototypes. (I got about four hours of sleep during those entire three days. I don’t recommend it steady-state, but it was nice to know I could get back to my developer roots if I had to do so. I even had my first fully caffeinated non-diet pop in years. I drew the line at pizza, however.)
The meetings with the client were sponsored by IT, and were run by the business. They were sponsored by IT because the business didn’t know mashups from shinola, but IT did. The business didn’t have a clue that mashups could help them, but IT did. The business was frustrated at IT’s repeated attempts to solve their growing rebate program problem, and IT responded by searching for alternatives to their same old development paradigm.
IT and business worked together to help us define the requirements. IT and business together helped identify what infrastructure was already in place to support the effort. IT and business worked together to help define what parts and pieces of the proposed new ‘system’ could be managed by end users and what parts and pieces would be governed by IT. In other words, there was deep collaboration between IT and the business. And while there were definitely self-preservation undertones in IT's motives, there was also realization on both sides that the old way of doing app dev didn’t work. Everyone was on-board to try something new.
If business had tried to run this meeting without IT, mashups wouldn't even have been on the table. It would have been strictly a shadow IT project that may or may not have taken advantage of recent Web 2.0 trends. And it would have been killed as soon as it became apparent that the project required access to CRM and financial systems. If IT had tried to run the meeting without the business, then we would likely have had a great architecture, and a deep understanding of how the pieces and parts were going to work together, but we never would have understood the deep and abiding frustration felt by the business, nor the financial imperatives that required something be done about the problem soon.
Both had to work together for success. Perhaps this isn't true for all mashup projects, but I suspect it will be true for many of them, especially any that require integration with the existing IT infrastructure.
Here’s something else I learned in the past few weeks. We’ve been saying for a while that business users would start writing their own applications because they can no longer wait for IT to do things for them. The idea is that account reps, shipping clerks, marketing program specialists, etc. would write their own mashups, and we will give them the tools to do so quickly and easily. Now that I’ve been out in the world a bit and have seen what is really going on, here’s what I think: Bullshit.
Even the young 'Net Gen' men and women on the business side don’t want to write their own apps. They may be forced to do so, but they aren’t doing it by choice. That’s because these younger workers want to make progress in their chosen career. Account reps of any age want to spend their time selling, not writing apps. Business analysts want to spend their time figuring out how to beat the competition, not writing apps. Marketing program specialists want to put programs in the field, not spend time writing apps.
So while these end users may be writing apps, they are doing so reluctantly because it takes time away from their chosen careers. Mashers are the exception rather than the rule.
What I do see is a rise in shadow IT. Certainly the business can’t wait for IT to get to their applications in the tail. But the business isn’t building these apps itself. they are hiring outside help. Unlike the wholesale shadow IT trend in the 80’s however, these new shadow IT projects have to operate below the radar. They have to be inexpensive enough to be funded within a departmental budget and not cause an IT governance blip. They also have to show fast ROI so that, when the project finally gets outed, the business can justify what it’s done in a ‘ask forgiveness not permission’ model.
(Note: web widgets are the exception. I'll write more about them in a future post.)
Here’s something that may surprise you. These shadow projects may be instigated by IT as well as by the business. IT itself is getting frustrated with its own inability to react quickly to requests for applications in the tail. In fact, I worked on a project a couple of weeks ago where I designed a guerrilla SOA infrastructure for an IT department that was trying to get an internal project into production before Big IT saw what was happening. The irony of IT setting up shadow IT to subvert Big IT made the job all the more enjoyable.
The take-away for this post is that IT and business have to work together for successful mashup projects, just as they do for any development effort. (Let's all hold hands and sing Kumbaya.) However, when business does take the lead, it is likely to be in the form of a low-cost shadow IT project rather than in the form of an internal masher. I know that isn't doctrine. Perhaps my opinion will change in the future. But for now, I calls it the way I sees it.
On the bright side, I’ve been in the trenches more than I have been in the past couple of years. It’s one thing to read analyst reports, discuss findings with customers and partners, write academic papers and pontificate from on high. It’s another to jump in and actually develop mashups. It is definitely harder to view the entire industry from a trench. Especially in the context of a fixed price contract. On the other hand, I’ve become reacquainted with the reason I went into technology in the first place: I enjoy it. I’ve written more applications (Don't be fooled. Mashups are applications.) in the past couple of months than in the past two years combined.
In a departure from my standard mashup posts, I’d like to share some things I’ve learned about mashups in the past few weeks rather than commenting on mashup news or reviewing some new mashup tool. Some of my experiences have reinforced what I thought before I embarked on this change in job title. Some have made me change my thinking, and in ways that might not make my current employer happy. Sorry in advance, Serena Software, if what I have to say doesn't agree with our marketing message.
First, I’d like to talk about the idea that mashups will allow the business to deploy their own applications without having to bother IT. I never thought this would work. After all, even applications in the tail will need access to back-end systems. Even applications in the tail will need version control of some sort. Even applications in the tail will need governance, even if that governance is light-handed compared to governance used to manage more strategic applications built by IT itself. After my time in the trenches, I’m even more convinced that mashup development has, at the very least, to be a loose partnership between the business and IT.
Let me give you an example.
I built a series of mashups as a prototype for a hardware technology company who wanted to get better control of their rebate program. It was a very intense three-day engagement where we spent the entire day working with the customer to understand their business problems, and then I got to spend the nights building mashup prototypes. (I got about four hours of sleep during those entire three days. I don’t recommend it steady-state, but it was nice to know I could get back to my developer roots if I had to do so. I even had my first fully caffeinated non-diet pop in years. I drew the line at pizza, however.)
The meetings with the client were sponsored by IT, and were run by the business. They were sponsored by IT because the business didn’t know mashups from shinola, but IT did. The business didn’t have a clue that mashups could help them, but IT did. The business was frustrated at IT’s repeated attempts to solve their growing rebate program problem, and IT responded by searching for alternatives to their same old development paradigm.
IT and business worked together to help us define the requirements. IT and business together helped identify what infrastructure was already in place to support the effort. IT and business worked together to help define what parts and pieces of the proposed new ‘system’ could be managed by end users and what parts and pieces would be governed by IT. In other words, there was deep collaboration between IT and the business. And while there were definitely self-preservation undertones in IT's motives, there was also realization on both sides that the old way of doing app dev didn’t work. Everyone was on-board to try something new.
If business had tried to run this meeting without IT, mashups wouldn't even have been on the table. It would have been strictly a shadow IT project that may or may not have taken advantage of recent Web 2.0 trends. And it would have been killed as soon as it became apparent that the project required access to CRM and financial systems. If IT had tried to run the meeting without the business, then we would likely have had a great architecture, and a deep understanding of how the pieces and parts were going to work together, but we never would have understood the deep and abiding frustration felt by the business, nor the financial imperatives that required something be done about the problem soon.
Both had to work together for success. Perhaps this isn't true for all mashup projects, but I suspect it will be true for many of them, especially any that require integration with the existing IT infrastructure.
Here’s something else I learned in the past few weeks. We’ve been saying for a while that business users would start writing their own applications because they can no longer wait for IT to do things for them. The idea is that account reps, shipping clerks, marketing program specialists, etc. would write their own mashups, and we will give them the tools to do so quickly and easily. Now that I’ve been out in the world a bit and have seen what is really going on, here’s what I think: Bullshit.
Even the young 'Net Gen' men and women on the business side don’t want to write their own apps. They may be forced to do so, but they aren’t doing it by choice. That’s because these younger workers want to make progress in their chosen career. Account reps of any age want to spend their time selling, not writing apps. Business analysts want to spend their time figuring out how to beat the competition, not writing apps. Marketing program specialists want to put programs in the field, not spend time writing apps.
So while these end users may be writing apps, they are doing so reluctantly because it takes time away from their chosen careers. Mashers are the exception rather than the rule.
What I do see is a rise in shadow IT. Certainly the business can’t wait for IT to get to their applications in the tail. But the business isn’t building these apps itself. they are hiring outside help. Unlike the wholesale shadow IT trend in the 80’s however, these new shadow IT projects have to operate below the radar. They have to be inexpensive enough to be funded within a departmental budget and not cause an IT governance blip. They also have to show fast ROI so that, when the project finally gets outed, the business can justify what it’s done in a ‘ask forgiveness not permission’ model.
(Note: web widgets are the exception. I'll write more about them in a future post.)
Here’s something that may surprise you. These shadow projects may be instigated by IT as well as by the business. IT itself is getting frustrated with its own inability to react quickly to requests for applications in the tail. In fact, I worked on a project a couple of weeks ago where I designed a guerrilla SOA infrastructure for an IT department that was trying to get an internal project into production before Big IT saw what was happening. The irony of IT setting up shadow IT to subvert Big IT made the job all the more enjoyable.
The take-away for this post is that IT and business have to work together for successful mashup projects, just as they do for any development effort. (Let's all hold hands and sing Kumbaya.) However, when business does take the lead, it is likely to be in the form of a low-cost shadow IT project rather than in the form of an internal masher. I know that isn't doctrine. Perhaps my opinion will change in the future. But for now, I calls it the way I sees it.
Subscribe to:
Posts (Atom)
