|
||
|
||
|
|
|
|
|
|
|||
|
|
|
|
|
|||
|
 
|
|
|
Tom Austin spent part of the afternoon of 7 October in Groove's headquarters in Beverly, MA talking with Ray Ozzie, the visionary who launched an industry and a new way of thinking about how technology can help people work better together - or apart. It was Ray's handiwork, leadership and inspiration that lead Lou Gerstner and IBM to pay almost $4 billion for Lotus in 1995. Ray's at it again, this time with yet another startup, Groove Networks, working on perfecting the science, art and technology of augmenting cognitive performances. This interview provides unique insights into why Ray felt compelled to start fresh with Groove, why it's so hard to get this right, what types of situations spell failure for collaborative projects and how and why he thinks his team at Groove finally has it right. This is the second installment of a two part interview. The first installment can be found here, Part One. Interview conducted 7 October 2004
Tom Austin: In the era of increased transparency and regulations like Sarbanes-Oxley, do you see any companies out there who are relaxing controls on their networks? Ray Ozzie: No. There's a healthy degree of caution in understanding the tools, and how they're going to be used. We had to put deep auditing capabilities into our product for Sarbanes-Oxley, for CFR Part 11 and because some of our government customers do amazing levels of auditing of activity — of what's going on. They've got to do that. That's the legal environment now. It sets the bar very high for tool vendors who need to play in that environment. But, that is the environment, and so it's something that we simply must do. Is that going to slow down innovation? Let me just rant on that. There's a bifurcation happening right now, and we're in the early stages of it. Five to ten years from now, it will be so obvious that, looking back, you'll never see the industry the same way.
These days, the leading edge of technology has shifted into the hands of the consumer and small business-person, in the form of the TiVo, the iPod, and even the software they download and use. On one side of the bifurcation is the big organization, the government and the big enterprise. On the opposite side are small business and individuals. To define which side you're on, answer the question: are your technology decisions gated by an IT organization? The people in one camp buy their computers pre-loaded from Dell. They download what they need. They don't worry about expensive, complex things like VPNs. They grab tools that say they solve problems they have. They use them, deal with spam and viruses in various ways and they get their jobs done. In the other camp, you have enterprise architectures and well-defined processes and procedures. You're focused on issues of compliance, leverage and cost reduction. But you're years behind in the OSs that you've chosen. You've implemented lockdown, and you have intentionally limited choices in messaging and in most all forms of software. The gap is growing; the sides are not coming together. The benefits of innovation are accruing to the little guys, not the big organizations. Many new innovations aren't burdened by things such as auditing and monitoring and enterprise controls. But they work. They're effective for the little guys. The tables have turned, and enterprises have become the laggards. Austin: Two of our largest clients - Fortune 50 type clients — are experimenting with a strategy that I call "run what you brung." Experimenting, not deploying. The end user has the right to use whatever machine they want. It has to meet certain minimum standards. They specify certain things like mail protocol, anti-virus package and personal firewall. Beyond that, users are on their own. In the experiment, these machines are allowed into a DMZ. Out of a sea of clients, I can only think of two who are doing this, but they happen to be very large clients doing these experiments. They're also scared to death about the legal issues, the compliance issues, the regulatory issues, the liabilities that they may be facing from this. Lots of our clients seem to have fears — not just these two — around inter-enterprise collaboration. How much of it do they audit? What do they audit? What don't they audit? Ozzie: We're living in that right now. I'll just tell you a few stories as examples. Some number of months ago, we had a meeting with a very large consumer products company who had decided to dump Outlook and go to Outlook Express with a third party calendaring add-in specifically because of training costs. They know everybody at home knows how to use Outlook Express, and so they just come in and use that, and they don't have to deal with training. Training the number of employees they have is a significant cost factor. That's another experiment like the one you mentioned. On the Groove side, we have been afforded the opportunity by our investors to build a product that satisfies both constituencies. We've got the deep management and auditing capabilities, and you can download it and run it with two people on the internet. It has been challenging to meet the needs of both camps, but we've done it. The core aspect of Groove is the workspace. That's where you share your work. The first issues we ran into, right in early 2001 when GlaxoSmithKline was starting to use [Groove], were trust issues. We had to remind the user visually of who they are working with in the workspace - reminding them continuously, "are these people I'm sharing confidential information with employees, or not?" Rather than installing a burdensome DRM [what's this?] environment, they believed that their employees would frequently do the right thing if they were simply reminded that there are outsiders in the space. Visual cues — a good user interface — can actually help quite a bit. For example, people frequently send confidential information to outsiders by ignoring the CC list in email.
In Groove, we color-code members: blue if they're within your organization; dark blue if they're somebody who is outside but cross-certified with this organization; black if they're unauthenticated and red if there's a name conflict — meaning somebody might be trying to spoof you. The second thing is that Groove allows for identity policies and device policies. We took a stab at trying to understand these control issues by saying, "If I issue you an identity to use in Groove, if I'm the organization and you're the employee, then I can control and audit certain aspects of your behavior in workspaces when you're using that identity." But you might not be audited at all when using a different identity with the same Groove client in the same workspace. There's also a device policy that says, "If you're running on a device that is owned by the company, I have yet another set of policy controls I can establish." And, we have double keying of all the encrypted data on that physical computer because I, as the administrator, own that device. We found that ownership of that device is a meaningful concept. If a member of a work space is from outside the organization, I can't assert ownership of all the data on their device because they could be working for some other clients too, and their intellectual property is on there. So, there are very complicated issues, but I think the more that you accept that the business environment is becoming more of a mesh than a closed hierarchy, the more you'll understand that people who build communication tools have to deal intelligently with these issues. Austin: Where don't collaborative technologies work? What red flags would lead you to turning away business? Or telling your sales rep to stop pursing an opportunity? Ozzie: Red flag number one occurs if there isn't a solid line that you can draw between the reason for buying and real, tangible business benefits. If our sales rep can readily explain, for example, that the benefit is in shrinking the amount of time that it takes in a specific design process, or doing customer support more efficiently, then I believe there is a good chance that it will be valuable to that customer. If our product is being considered to rationalize another bad decision that they made, then it's going to fail. One prospect had spent many millions on an internal portal, and nobody was using it. The IT organization said, "Wow, if I could just throw some of that collaboration stuff on this portal, then it'll be really cool." The sales rep was surely tempted because of a potentially large deal, but many who have been through this before saw a potential train wreck. Collaborative technology — perhaps any technology these days — must be tied to a readily understandable benefit or pain, or it will likely fail to gain traction and risks becoming shelfware. Austin: And, you would have wound up with a bad reputation from that account. Both of those red flags have come up in conversations between us and our clients on a large number of occasions. What other red flags? Ozzie: Process change is hard. If you bring in any collaborative technology and you're doing it to augment a process — to make that process work more effectively — you can get a return on investment very quickly. You can get people trained on the new system because they will realize benefit even though they have to learn something new. Siemens Medical Systems is an example. They install very large, complex machines such as an MRI. These are complex projects for which it's difficult to bid accurately due to the number of physical variables and the number of subcontractors involved. Their goal was not to completely blow up and change how they sell their products, but they clearly wanted to speed up the sales and installation processes, improve shared understanding and thus lower the risk. So, they use Groove, interconnected with their enterprise systems such as SAP and Siebel. As soon as an order is generated, all the relevant individuals, both external and internal, get invited to a Groove workspace. Bids are more accurate, the project is coordinated smoothly, and it works. On the other hand, really serious process change — radical change where technology is just a part of the process change — is in a different class. Serious process change is hard, and if a process change fails for any of a variety of reasons, the technology is generally blamed. A lot of the early failed Notes installations were related to assumptions that somehow by introducing technology, it would fix broken collaborative business processes as if by magic. Technology can surely augment that kind of change, but in and of itself, technology can't make it happen. Austin: If tomorrow, someone were to come in and offer to buy out the company from you for some phenomenally large number that you couldn't turn down, what would you do next? Ozzie: The reason I'm passionate about what I do is I believe that we can make a difference in how businesses operate, and how individuals use computer technologies to interact with one another. A merger, if one were to occur, wouldn't necessarily imply moving on to doing something else. The IBM acquisition of Lotus in June of 95 was the right thing to do because it was going to enable us to fulfill what we'd been trying to accomplish for years. Notes would likely have died without that acquisition. The desktop business was heading in the wrong direction, and Lotus would have had a difficult time funding its growth requirements. And so, the IBM merger gave us the opportunity to double down because we had a distribution channel. We had services. We had somebody who had both the capacity and willingness to invest on the technology side where it was constrained before. Austin: So why did you leave IBM? They were doubling down, providing you with the channels and a whole lot of additional technical support. You stayed with it for a couple of years, finished what you had planned and then you left to start anew without the installed base constraints you had with Lotus? Ozzie: The real reason that I left was because of what was happening in the marketplace in the '95-'96 timeframe. That timeframe just happened to coincide with IBM's purchase of the company. We started to see an increase in use of Notes outside organizations and between organizations. The leading edge companies; Chrysler, AIG, a number of these channel masters were trying to extend their Notes-based business processes out to their partners, and we witnessed significant problems related that I'd characterize as the "clash of IT organizations". Here was one company saying "if you'd like to continue to do business with us, then install these servers and this software." But in many cases, it was taking months or years to get the other IT organizations to install and deploy the software, and train its users. There was simply too much friction. We tried a hosting model — you may remember AT&T Network Notes. But then the organizations lacked the ability to do the kinds of systems integration they desired, and they didn't have the kind of administrative control they desired. I came to the conclusion that the solution architecture we had created as an industry — the server based, centralized architecture — in fact doesn't match the requirements of a "meshed" business environment. The technology itself should be a "meshed architecture", reflecting the nature of business. That's Groove. Austin: The next time around, what will be the discontinuity, the problem with Groove technology? What element of the architecture will lock you in so you couldn't accomplish what you wanted to accomplish? Ozzie: I don't yet see limitations in the model. We started by embracing both extreme decentralization as well as hybrid architectures, and it's satisfying a tremendously broad range of needs and usage topologies. Austin: Groove constitutes the environment that users should really be working in when they're working with other people. Ozzie: That's right. Austin: That makes it sound as though Groove should be the end user operating environment — the place that people live in. The problem that all of these products face, you and your competitors, is that one company controls the end user operating environment. And it's not you. Microsoft's sitting there. They're the 800 pound elephant. They're not doing what you do. But you're handicapped nonetheless. How can you compete when Microsoft controls the user environment? Ozzie: There's the conventional wisdom that Microsoft's control of the operating environment puts other people at a disadvantage. I don't buy that. Microsoft's most significant advantage — and a huge advantage it is — is in their distribution muscle, not necessarily in the technological control of their operating environment. I believe that Microsoft is actually more constrained by their own operating environment than any other software vendor. For strategic reasons, Microsoft generally introduces innovations that are tied exclusively to their latest operating environment. This puts them more-or-less out of lockstep with their customers, who run a broad mix of prior versions. Other vendors have a strategic advantage in that they can create middleware that operates on a variety of operating environments. Middleware enables significantly more rapid innovation and adaptation to customer environments — particularly in the collaboration realm, where people who work with one another may not have control of what software each other are running. Austin: The problem you run into is not at the technology level. It's more a marketing issue. Instead of dwelling on Windows, look at the mail client which is controlled today at the 90 percent level by either Microsoft or IBM. Ozzie: I think what you're suggesting is that perhaps collaborative functions should be bundled with the mail client. But therein lies a similar issue to the one that I was just discussing. The nature of the business environment is that collaboration is increasingly occurring with people outside the enterprise. One company may have chosen Lotus Notes R5. Another may have chosen a certain version of Outlook and Exchange. Yet another may have chosen IBM's Workplace product. Some might be contractors using Web mail systems. In this day and age, the choice of mail client is highly diverse. Bundling a set of features with a given mail client may work extremely well for personal features such as message organization or searching, but when it comes to collaborative features, you must package them in a way that they are accessible to users of all email clients, not just one vendor or one version. The situation would be different if there were a dominant email client that we could all plug into, but there isn't. And it's going in quite the opposite direction.
Austin: That would make life easier for you. Ozzie: Well, it surely would make life better for the user, but it's just not realistic in the world that we're in. Austin: Does that model forget some types of users? Ozzie: Well, we're moving toward a world where a variety of different types of clients will be relevant. The concept of the true thin client is gone. Nobody talks about that anymore. The browser itself is not thin. It's got a lot of scripting code. It's a smart client run time. The next generation client technology is important, and it will come in many forms. For example, intelligent caching architectures such as Microsoft's Avalon and IBM's Workplace will be important for users within the firewall inside of organizations, and Flash will be increasingly important for users of the Web. And there's another class of users to whom mobility is extremely important - the people who carry around WiFi-based notebooks. People who do lots of document-based work. Projects and meetings are very central to what they do in their work life. They work anywhere, anytime, by just opening their PC. And the concept of these users running in an always-on, high-bandwidth, low-latency environment is pure fantasy; we're in a world of variable network conditions, and people will want to run disconnected even if on purpose to do their work. These people need a very rich client environment, including tools such as Microsoft Office and Groove Virtual Office. Austin: That's an autonomous rich client vision. We'll cache not only executables, but also data. At least that's the vision, right? Ozzie: Let me make a non-obvious point about caching. The IT industry generally paints a picture of the main information store being at the center, and the cache being at the edge. To use a non-business example, think of purchased music within iTunes. The center is where the RIAA Austin: Holds all the music. Ozzie: Yes. Out on your PC and ultimately on your iPod, it's just a cache. And the content usage policies live with Apple, so in theory they can terminate your access to it at any point in time. It's a beautiful model if you like control. Flip that model on its head for a moment. When you take digital photos, you're accumulating thousands upon thousands of digital image files. In the old days, people would think, "Oh, well, you'll upload them to the centralized, safe, robust repository in the cloud." Wrong. That's not what's happening. People are uploading subsets of their photos to services such as Flickr or Shutterfly. The large file libraries, content creation and full control remains at the edge. And guess what? The storage trends are favoring this "personal content management" at the edge. Hitachi has hundred gigabyte laptop drives today. By 2010 at latest, which is not a long way away, we'll see terabyte two and a half inch drives. It's simply staggering to imagine. Storage is growing way faster at the edge than it is at the center, and I think it's interesting for IT to think about how best to leverage that fact. Case in point: years ago, I used to have only my most recent email on my laptop, and kept my archives on the server. But about a year ago I flipped this, and now my main email storage is on my client because there's more disk space available. I cache a certain set on the server that I might need to access via web mail. I've switched caching models from center-edge to edge-center. As IT administrator, what am I going to do to make the best use of the fact that storage is increasingly present at the edge? How can I leverage that to reduce my organizational and management costs, by leveraging that edge-based storage? Can I reduce backup costs by saying, "Look, the only reason I'm backing up some clients is to enable them to recover from failure. But I know that most of their data is in workspaces that are auto-replicated amongst multiple PCs with tons of storage. How can I leverage the edge to reduce my centralized costs?" Austin: Your concept of edge as master versus center as master maps well into the bifurcation of the market you mentioned earlier. Two different elements of the market: the big central corporate model, and the "run what you brung" small and medium size businesses model (as well as some of the eccentrics in the large corporation). Ozzie: Because of the nature of the work environment right now - because of the economy - many very talented people have been laid off. In our business, we see a lot of these people starting virtual organizations. From what we see, this is not a small phenomenon. People who are geographically dispersed are starting small businesses, IT-less businesses, and they're using the internet to work and to connect with one another. And then, ironically, many are doing business online back with their original employers. And as a result, those people are bringing Groove back into the larger organizations from the edge. As I said before, business is becoming more of a mesh architecture, being supported by mesh technology. Austin: So you'd say let's let corporations buy their innovations from the outside so they don't have to take on the risk. Ozzie: I'm not making that specific recommendation; I'm simply saying that it's beginning to happen, for all of the reasons I stated before. Innovation is more accessible on the outside, and it's finding its way in at the edge. Austin: You have to ask yourself how many IT organizations, how many CIOs have on their goal sheet, or their mission statement, "Encouraging creativity and innovation in the corporation?" That's not why the IT organization was created. Ozzie: That's right. But what's important is that they enable it, or not take draconian steps that inhibit it. Set limits and create guidelines. Say, "Look, you can try it, but let us know before you do. Or try it at home before you bring it in here." Austin: Or, we'll create a sandbox segment of the network where you can play with it. Ozzie: Yes, exactly. I think for the most part, individuals in IT want to do the right thing. It's just that when you put them on the spot and they have to take a risk, and they're asking themselves what happens if something goes bad, it's easier to lockdown. I think users need an environment that's a bit less binary. Austin: And, that's got to be for anyone selling something like collaborative technologies. That's what makes it a very hard sales process. Ozzie: Collaboration in general has never been an easy sell, but it is so very much worth the effort. Truly effective collaboration lives at the intersection of technology, organizational dynamics, and social dynamics. If you only do two of the three right, it won't achieve the desired objectives. But when you can get it right, it just works. Austin: I appreciate you taking the time to talk with me today. Ozzie: Absolutely. My pleasure. I enjoyed the conversation.
 |
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
