Archive for June, 2009

Unlocking the cloud

Here is an interesting perspective on cloud computing from the Economist. The article contends that customers subscribing to an on-demand service should be wary of data ownership and the data migration difficulties they will face when moving their data from one SaaS (software as a service) vendor to another. The author positions open source as a liberating technology and sees cloud computing as new attempt by software vendors to lock-in customers.

This is the first time I ever heard anyone argue against cloud computing. To tout on-premise open source systems as liberating technologies and to call SaaS and cloud computing as a step back is simply out of touch with what is occurring in the marketplace. At the heart of its argument against cloud computing is the lack of standards for moving data from one service provider to another. However, the same can be said for migrating data from one on-premise solution to another, whether open-source or not. For example, have you ever tried moving data from an Oracle application into a Microsoft or SAP application? No common standards exist today that would automate the migration of any form of enterprise data from one solution provider to another.

However, the process of importing data has become a relatively painless, inexpensive and a low risk activity for most forms of data. Data in most modern enterprise applications (on-premise or on-demand) is represented in XML or can easily be exported to XML, now a ubiquitous standard for data representation and data exchange. Using XML, just about every cloud service provider (and even legacy application providers) have the tools and the expertise to migrate data from the customer’s current formats and systems. There may of course be some minor challenges to overcome and the migration may require investment in a few days of consulting services but I do not at all see how data migration results in vendor lock-in.

One thing that customers need to make sure of is data ownership. Tenrox project management software and workforce management customers own their data, whether they are on-demand or on-premise. This assures our customers that they are totally free to move to another service provider.

Cloud computing has tremendous benefits for the customer. The service provider takes care of all the details of software maintenance, bug fixing, data backups, 24/7 availability, 99.9% up time, data security audits and certifications, bandwidth, worldwide access, and much more. This frees internal IT to spend time on more strategic work such as IT project portfolio and resource optimizations, data analysis, portal/report development, and activities that are directly related to the company’s core business.


The Next Game-Changers

Nice article by Morningstar on how technology and market forces are making fundamental changes in the competitive landscape. Companies whose previous market dominance and position were virtually unassailable have now become also-ran businesses experiencing a rapid decline in revenue and, specially, profits.

There is also a good non-techie explanation of Cloud Computing. Here is an excerpt:

Consider “cloud computing” (which is sometimes called “software as a service”). Basically, instead of having all your software and files installed on your computer, in a cloud computing world, you would just fire up a Web browser and use services provided remotely from central locations. In the current way of doing things, I buy Microsoft Word, install it on my machine, use it, and store my files on my local hard drive. But on the bleeding edge of technology, I could just fire up a Web browser, visit the Web site of a word processing service (such as the current Google Docs), and save my documents on the service’s central computers. It’s cheaper, and the documents are automatically backed up and available from anywhere.

Allow me a short analogy using electricity. Think of how the world would look if each of us had our personal electricity generator in our backyards. Although silly and inefficient, this is essentially what we have with computers today. Eventually, it looks as though the computing world will move to the electricity model, where power is generated efficiently at a handful of central locations and then distributed via a robust transmission system.

Another emerging example of this trend comes from console gaming. A new firm named OnLive will soon be offering a service that–according to early reviews–will offer games comparable to what is available today from Microsoft’s Xbox or Sony’s PlayStation. But with OnLive, there is no big box under the television or physical games required, just a controller and a simple device that connects to the Internet.

Cloud computing is perhaps the most revolutionary trend in this article, as opposed to the other trends that are more evolutionary. Simply put, software is no longer married to hardware. Or, just think of it as the trend toward having the majority of computing power no longer distributed on millions of desktop boxes, but rather provided by central servers in thousands of locations and distributed via the Internet.

No Comments

Applying Occam’s Razor Principle to Product Design – Lessons learned from our Project Management Software design experiences

Occam’s Razor principle by a 14th century English philosopher states that “plurality should not be posited without necessity” or “when there are multiple approaches to solving a problem just use the simplest approach”. Seems like such an obvious statement but so much of the products we build and use today totally ignore this principle. The following best practices are based on the mistakes we made and lessons learned in building a project management software application.

Applying Occam’s rule to product design and development could go something like this:

  1. Design features that are simple to use
  2. Provide just one way of performing a function
  3. Don’t oversimplify

1) Design features that are simple to use

If you can implement a feature using several design options choose the simpler one. However, for most product development teams choosing the simpler design is easier said than done.
Here’s why:

  • There is a tendency to try and build an all in one comprehensive solution

    Since a variety of internal and external stakeholders participate in the analysis phase, designers often keep adding complexity to satisfy the many parties and differing agendas involved. Therefore, often a product that was intended to automate a simple function or provide a simple service turns into a complicated device that can “do it all”, right out of a science fiction movie. 

  • Developers are naturally biased towards paying much more attention to handling extreme cases and boundary conditions at the expense of basic patterns of usage

    I have seen the negative impact of this firsthand at Tenrox. The complexity of software developed is increased by a factor of ten when developers try to cover all possible scenarios. Let me provide an example, a few years ago our R&D team redesigned Tenrox Project Workforce Management’s rate engine so that it could support a variety of cost and billing scenarios. When the new software was released, to our surprise, a few large customers with simple cost and billing rules reported significant performance issues with the new rate engine. After some analysis we discovered that these customers were using standard hourly rates, and yet the rate engine’s new design, which had absolutely nothing to do with hourly rates had been overcomplicated and slowed down a simple calculation that was working just fine before. Of course, the engineers went into emergency mode and had to come up with short and long term fixes to their overly engineered design. It takes considerable senior executive attention to reduce this bias and it is an ongoing battle in our product management and R&D teams.

  • Iterative reviews focused on what is missing complicate product design

    After working with our R&D team on several product releases over a fifteen year period we have identified this as a recurring pattern to avoid. Here is an example. We met about a year ago to redesign our software’s budgeting feature. The designers had come up with what they thought was a simple elegant solution that they claimed would address 95% of the requirements we had encountered. The meeting started on a positive note and everyone participated in the design review. A few people made suggestions of small things they thought were missing. Eventually there were many more ideas, new, even some commonly observed, usage patterns the designers had not considered. Within minutes the simple design was thrown out the window, and a complex multi headed beast of a budgeting feature design reared its ugly head. We all walked away from the meeting a little more tired, uncomfortable with the outcome. R&D ran with the feedback and put a few good developers to the development task. Six weeks later we were invited to another meeting to get a more in-depth view of the design, including some design mockups. The meeting was a disaster; the feature had become so complicated that virtually everyone agreed that the entire design should be killed. After wasting six weeks of development time, the designers went back to the drawing board and re-designed the feature from scratch. The second revision had fewer features than the initial design they proposed! But it was just the right combination of automation and ease of use. Our third design review meeting was an overwhelming success and the new budgeting interface was a hit.

2) Provide just one way of performing a function

As any product evolves, especially of the software type, we keep on adding more and more new functions. For example, in a version one, you can only create a project from the setup page. But based on customer feedback, by version 5, you can create a project while on a dashboard page, from the project manager summary page, from the customer page, while creating a portfolio… However, if you look at the products that are often viewed as amazingly simple yet effective designs such as the iPod or Google ‘s user interface the user is given very few choices of performing the same function. I had our R&D team hang pictures of the classic iPod with just five buttons in all their meeting rooms so they are constantly reminded of the importance of this bare bones “get it done” philosophy.

3) Don’t oversimplify

This is perhaps the hardest rule of all. Let me explain with an example. Developing a timesheet application seems pretty straightforward these days and is considered by most to be a simple application to buy or develop. That is until you get into the details of the varying department specific time tracking user interface and timesheet policy enforcement requirements, cost allocation, billing, leave time and overtime calculations, and approval processes that have to be accounted for and automated. Not to mention the complexities of integrating a timesheet with payroll, accounting, project management software, and CRM applications.  We are often faced with prospects who try to oversimplify such requirements, choose an under-powered product or do not make the proper investments, and pay a very heavy price when these issues resurface in the tail end of the implementation.

However, even if your product can and must handle complex functions, always focus on the most common use of a function. If you need to implement complex or boundary scenarios they can not impact the average use of the function.

In a future blog, I will apply Occam’s Razor principle to making IT investments.

1 Comment