Google’s next step an OS? Probably not.

Posted in et alii, IT, UI on February 22nd, 2007 by dan

Jason Calacanis recently reveled in his accurate prediction that Google they will release an office suite in 2006. Kudos on the call but, I don’t think he is right about their next move — that Google will build an OS but, that also depends on the definition of an Operating System.

I think Google’s next move as Jason, astutely observes is to create “reoccurring revenue” for PC makers like Dell/HP by getting them to install something that isn’t MS Windows, however that something won’t be a Google OS. It will more likely be an Open source OS like, Ubuntu with a revived Google Pack installed on it. I think the simple reason for this is Google has been involved in Linux development for a long time but, in the area of the kernel not on the front end. Why should Google do any work when they can just piggy back on another great initiative.

The pack will have to have some interesting additions to really put the squeeze on MS. I think the obvious choice is “your desktop PC anywhere you are” — the current notion of “your” PC will become irrelevant, meaning, having everything on one piece of hardware you own won’t matter. You can see Google starting to do this now with Google Applications. With the addition of the elusive G-Drive mounted as a “virtual HD” sprinkled into the “Pack” you have a very flexible totally portable desktop environment. Imagine going to any machine in a business and signing in and getting all your preferences, all your documents, installed programs, right there for you! The great part about this it wouldn’t cost Google much, as they would be using currently available OS solutions, FF, Linux, etc. As more people buy PCs with the “Google OS/Pack” on them, more people will reap the benefits of the “anywhere desktop,” creating a runaway snowball effect.

So, I don’t think Google will build an OS in the strictest sense, I think they will extend existing technologies, the Linux desktop out to a their servers and their incredibly powerful data centers down to the desktop.

SAP’s users of Tomorrow

Posted in SAP, SDN blogger, UI on December 28th, 2006 by dan

If you work with me you have already heard this rant, so might as well just skip this blog post and go back to work playing with your new tech toys.

SAP user’s of today are people that can remember a time when computers were the size of small city blocks and the idea of having one on your desk was laughable[1]. Most of them are happy enough to have a computer on their desk to run Excel and mess with their own spreadsheets. These people today control the purse strings of IT spending and are “leading” the relationship with SAP. This is bad…. why? I’ll talk about that later.
If you have a child who is less then 30 years old and you work in an IT shop that runs SAP software, you should be scared. Talking from my personal experience ( I am 27 years old ) my family got their first computer when i was 6 or 7, I can just barely remember a time Before Computers, what this means to me and everyone in my age bracket is that we have used computers forever, our expectations are different. How different can be quickly mapped as you go down generations, the younger you start to use computers the higher your expectations are. I can’t stand when Ctrl-C doesn’t work or when I can’t turn on and off toolbars or when the screen is so full of information I don’t need all I can see is a box 200px by 150px. When this happens I go find another tool — this is why you should be scared.

Thomas Otterchicklet points out that at SAP they are good at process — it sounds almost like a core value,

“at SAP we think a lot about processes. I hear it all the time in the corridors and meeting rooms in Walldorf. It is one of the main reasons for SAP’s success. It is goodness, and it is very tough to emulate… It is a significant competitive advantage.”

This is all quite true they do have that “special sauce” down to a ‘T’ however, it won’t help when folks in my generation start to take control of the purse strings.

If someone gives me a piece of software I “must use” and it is horrible, the first thing I do before using it is to see if there is another tool I can quickly use the way I want and then just plug the numbers into the horrible tool. This is a huge problem for SAP as that all the wonder process focus Thomas talks about goes out the window when people don’t use the tool in the manner it was designed. I would argue that for the next generation of people who will soon ( < 10 years ) start to get into decision making positions at Fortune 1000s UI ease and flexibility will be nearly as important as all the process stuff already boiled into SAP software.

As campy as Time’s person of the year was, it was about a change of focus on the internet. From just a push of information and goods out, to a true conversation. People creating content to be consumed by others, the internet as just another conduit for people to carry out conversations. This change of focus needs to be felt in the Enterprise too and I am concerned we might not be able to move fast enough.

[1] “There is no reason for any individual to have a computer in his home.” — Ken Olson, president of Digital Equipment Corp. 1977 ( Snopes )

Innovation in IT

Posted in innovation, IT, UI on November 11th, 2006 by dan

If your IT department is even the smallest bit like mine it may seem that is almost totally impossible to create a place where you can safely try out new technology. In my IT shop though we have carved out a small niche where we have a hand full of folks with a small percentage of their time to really seek out impossible problems and help solve them. At first this seemed like an impossible sell to senior management, however using the following logic we were able to get the time we needed to see if some of any new technology could help our business.

  1. Agile Development
    • Im totally guessing here, but in most IT shops I assume you probably use some locally bastardized version of the Waterfall method. In our R&D team we use an over simplified version of Scrum, the idea is to remove all the unnecessary artifacts from the process and “Shutup and make it work,” to use one of our teams mantras. The basic idea is get testable code in another team’s hands as frequently as possible; this could mean every night or every week.
    • The reason this is number one is that it will allow you ( and/or your team ) to prove value instantly. People go nuts when you deliver the 1st version of working code before other teams have even decided who writes the spec
    • Using this type of process automatically distinguishes you from your colleagues, it allows you to move fluidly with the ever changing IT landscape, it is a huge win over your normal process and a big key to my team’s success
  2. Flatten your Team
    • This may seem like a no brainer but odds are there are lots of people between you and your user community. To be successful at delivering code as fast as you will need to justify your spent time you must be as close as possible to your user base. This means you can’t have a rigid structure the person who knows the most about the area needs to make the decisions. Suck up your pride and let them run the show.
  3. Get smart people
    • I have a really hard time phrasing this statement but, suffice to say, you have to get the cream of your organization. If you want someone to go decide if Ruby on Rails is a good idea you better trust that person’s ability to learn and their ability to judge technologies. In the end it’s better to have fewer people then an army of people you have to micro-manage.
  4. Research is failure
    • This is one of the hardest concepts for an IT shop to grasp — they mostly deal with uptime and throughput but when experimenting with new ways of doing things you have to be able to deal with a certain amount of risk and this finally brings me to the reason for this blog, a recent post ( really go read it ) by

btw — this blog was written somewhere south of Greenland at about 33k feet. On board internet is great.