An app in the cloud does not a cloud app make!

I don't expect that there are many software companies who are not considering some sort of cloud strategy these days.  If Ballmer is "all in" (http://techcrunch.com/2010/03/04/steve-ballmer-microsoft-cloud/), then we know it must be mainstream!  So we have a vast army of vendors whose per-cpu or per seat priced behind-the-firewall (BTF) server products are being “re-imagined” as cloud offerings.  But what does that mean?  What is a cloud version of an existing product?  How does it differ from its BTF predecessors?  Well, what I can say for certain is that just sticking an existing product on Rackspace doesn't make it a cloud application!

 

The cloud itself is really just an enabling technology; a bunch of resources used as a service over the internet.  If a user today accesses an application by pointing her browser at a web app, she doesn’t care whether the database and app server are located in her company’s data center or in EC2.  What she cares about is what the application does.   The IT manager might care where it runs (there are certainly installation, configuration, maintenance, etc. benefits from running an application in a cloud-hosted VM), but the user doesn’t.  So if I, as a Product Manager, say that my company’s cloud strategy is to simply offer a cloud-hosted version of my existing product, I had better be certain that the IT installation/configuration/maintenance challenges that my customers face are grave enough that solving them alone will deliver competitive separation.  I certainly hope that that’s not the case in most instances (although many of us can still benefit from a bit more attention to our users’ initial experience with our products)!

 

Instead, we need to ask what the cloud enables our products to do that would have been difficult or impossible to do BTF.   Consider the transition from mainframe/minicomputer UIs to the GUIs of the client/server days.  Sure, the emergence of LANs, increased power and lower price of 386 microprocessors and microprocessor based hardware made it possible. But as dumb terminals were replaced by networked workstations and servers and PCs in the 80’s, the change in user experience was far more important than the change in architecture.  The same old text based UI didn’t simply move over to a network workstation; the GUI emerged, and users benefitted from a dramatically improved experience with their applications.

 

So as we “re-imagine” our products for the cloud, we need to be searching for the GUI equivalent of today.  What is the quantum leap in experience that we will offer our users in the cloud versions of our solutions?  I’ll argue that it hasn’t been fully realized yet, but here are two areas that I’ve been thinking about lately:

 

1. Vastly increased computing power through elasticity – (warning, this example isn’t very environmentally friendly, but I think it's valid) … If we all had our own electrical generators in our back yard, we would have a very difficult time handling the variable consumption of power.  When we were at work, the electricity being created would go unused, and when we came home at night and tried to watch TV, cook, and do some laundry all at once, we would quickly exceed our capacity.  We would all need to size our generator for the absolute highest peak we would ever need – and that would be far too expensive.  But by hooking up to the grid, we can have all of these appliances because we don’t all use them at the same time (hopefully!).  Elastic consumption is much more efficient when pooled.  Likewise, there are things that we would never propose our products do on the desktop simply because they would take too much time or be too processor intensive.  All of our users would need incredibly powerful workstations instead of the ultralight laptops that they prefer.  But the cloud employs a similar utility model as the electrical grid.  So now we, as software designers, can dream up tasks that are not bound by the limitations of each backyard generator (the local machine), but by the full power of the grid (the cloud).  What are you going to do with that power?  Well, that’s the question! What would your product look like if you could kick off huge complex tasks in the background as your user interacted with the system, for example?  Liberating, huh?   

 

2. Different pricing models – The cloud forces us to rethink the way that we’ve traditionally priced software.  Since the user doesn’t install the software BTF, the old per-CPU model is completely useless.  Currently, vendors are using a mixture of options; per user, per hour, bandwidth consumption based, disk space based, etc.  It’s a great opportunity for us to explore innovative pricing concepts and new business models.  Interestingly, github is trying to do the opposite; go from the cloud to the data-center with their fi product and its “traditional” per-user license and support model.  Are they telling us that there’s no money to be made in the cloud?  Unlikely!  So our challenge as PMs (or anyone who is creating cloud solutions) is to think about how to define the value that we offer our users and to charge appropriately for it. Perhaps it ends up being value based not on usage or consumption, but on outcome.  Interesting topic for another day…

 

The attributes that separate our cloud solutions from our existing BTF solutions are still emerging and they very well may not have anything to do with pricing models or computing power.  But whatever they end up being, I can guarantee they will be distinct.  If you think that customers will be satisfied with that same old app but running in the cloud, think again.

Comments [0]

If your code could talk, what would you ask it?

FishEye has been described as a revision control browser and code search engine: a kind of super UI to a source code repository.  That's true, but it's a rather passive explanation of the product, leading to statements like, "you can use FishEye to see what's happening in your project (commits and changesets)."  It makes the tool a window through which you can view your project.  But as the tool indexes a repository it accumulates a vast amount of information.  Statistics like your total number of committers, number of commits in a given period, total Lines of Code (Loc); changes in LoC can be very useful in understanding a project.  And other statistics like your commit history by month, day, or even hour, and an activity stream to drill down even to the level of the diff of the code that was committed can be extremely helpful in understanding you (or your team of developers') work on a project.  But the more I get to know the tool, the more excited I am discovering that there's even more value to be harvested from its understanding of a project - particularly with the emergence of DVCS (we support git now and are planning Mercurial soon) where a project can have a very complex life with branches and merges happening everywhere.

So as I work on the FishEye roadmap, I'm asking myself, "what can this repository tell us, and how can that answer help developers get stuff done?"  I'd love to get your ideas, too.  If your source repository could talk, what would you ask it?  Would you like it to give up more statistics about your project?  Would you like it to be more insightful about how your code is evolving over time?  Would you like a better sense of how the team is working together on a project?  Etc.

Feel free to use the comments - I'm sure others would be interested, too.  But I'd be glad to chat on the phone (or in person as I travel around) too.  Drop me a note if you'd like to give some more direct feedback.

Thanks!

Comments [0]

Bring us your UX and UI Brilliance

Atlassian has always been focused on great user experience. In fact, it's one of our core values (http://www.atlassian.com/about/values.jsp); solving customer problems with brilliant simplicity. Everyday we try to build products that are useful and that people lust after. We know that good design and experience is not a luxury: it's not an add-on to be picked up if a developer has some extra time on his hands at the end of a release.

To support that goal, we've been assembling a crack team of incredibly talented UX and UI experts. They not only influence our own products, but are also leaders in the field of web technologies and development as event speakers, authors, and all-around magicians of the possible.

But we need more! We want to increase the ratio of designers to developer on all of our teams. We need both interaction design and visual design masters to keep up with the company's overall pace (and it is a blazing pace!)

If you're the best of the best, please drop me a note (tim at buntel dot com). We're headquartered in Sydney, Australia – one of the world's greatest cities (and the one with the best coffee anywhere – and believe me, I've looked!) - and we also have offices in San Francisco and Amsterdam. It's a great place to work http://www.atlassian.com/32/why-join.jsp and we'll welcome you with excitement and elegance (a bridge climb http://www.bridgeclimb.com/ and fancy dinner on us) or a vacation before you even start http://www.atlassian.com/32/get-in.jsp !

I know you're out there: you're spending your days fighting an uphill battle against corporate management that neither understands nor believes in the value of outstanding experience and design. So come join an organization that already believes! We're small enough for your talents to have a real and meaningful impact on the direction of the products, but more than big enough that you'll never need to worry about that next round of VC funding coming through!

Comments [0]

Making Agile project management suck less: Hello Greenhopper 4.3

At Adobe we used what affectionately became known as "modified scrum" and I think that's pretty common.  Not too many development teams that I know do Agile and Scrum exactly the same.  A big part of it for me was always the absence of decent tools to do agile project management.  Sprint planning and task tracking can be spreadsheet hell.  If you're a scrum master, check out the new release of Greenhopper http://www.atlassian.com/software/greenhopper/ Version 4.3 just shipped and it has great improvements to get up and running quickly and (relatively) painlessly.  Nick Muldoon, the GH PM, describes some of the slick new goodness in the blog at http://blogs.atlassian.com/jira/2010/02/get-started-with-agile-using-greenhopper.html

I would have killed for the sprint Planning Board (http://www.atlassian.com/software/greenhopper/features/planning-board.jsp) a few months ago!

Comments [0]

A simple example of FishEye for Flex developers

A number of folks have asked me about Atlassian FishEye. There's broad familiarity with some of our other products (notably JIRA and Confluence) among the AS/Flex/ColdFusion community, but fewer know about our other dev tools. FishEye, specifically, has been an object of some curiosity to many of my developer friends from the Adobe world. As I'm a big fan of illustrations, enjoy the following simple explanation.

FishEye, in short, helps you understand your code. It opens up your source repository (Subversion, Git, Perforce, Clearcase and CVS) with real-time notifications of code changes plus web-based reporting, visualisation, search and code sharing. Yes, that last bit is from marketing content. Sorry. Let me stick to the first part: understanding your code.

I was just looking at the FlashBuilder 4 beta and wondering how the data-centric development features were progressing. I created a page with an empty data grid, then used the handy “bind to data” command to connect the grid up to a ColdFusion component (using the deelightful CF9 ORM features, bien sur)! I committed both the before and after into my git repository on gitHub and then launched FishEye.

Now, gitHub alone lets me see some information about my project.


I can see the raw code, commit history, nice visualizations about branch and merges. But it's not great at understanding how the code has changed over time. About the most I can get is some correspondence between the commit messages and the point where they match up with the current version of the code.


FishEye sits on top of my source code repository and gives me a much more powerful way to look into its contents. I can start exploring my project, get lost of data about its history, and get right down into the code itself (yes, this is a gross oversimplification, so I hope the dev team will forgive me. I promise more details in the future).



One of the nicest new features in FE 2.2 is a new IDE-like side-by-side diff feature. And it was just this feature that allowed me to easily answer my original question about what the data-centric wizard was doing. I could pull up the version of the file from the pre-wizard commit and the version after and, Voila!



The left and right panes can scroll independently, and the view stays anchored around a central point. Color coding illustrates where lines have been added and removed and where the line's internal content has changed. Each addition or deletion is linked to the opposite window by a colored triangle that links to the location of that change in the other version.

Here's a better example...


So by using FishEye, I get an incredibly deep understanding of the code in my project as well as its history. Again, that's just the tip of the iceberg, so bear with me and I'll give more examples soon.  And you can try it out yourself for free at http://www.atlassian.com/software/fisheye/

Comments [3]

The Environment of Software

The Finnish architect Eliel Saarinen wrote, "always design a thing by considering it in its next larger context—a chair in a room, a room in a house, a house in an environment, an environment in a city plan."  Software product managers need to do this with their products, too.  Consider the program on the machine in the office of the business.  And most of all, consider the user in the midst of it all.

Comments [0]

Groovy:Java as...

For some upcoming enhancements to some of our Atlassian Dev Tools, I'm dipping my toes in the Groovy/Grails pond.  While it's too early to make a pronouncement, I was amused by the quote in Scott Davis' excellent article at https://www.ibm.com/developerworks/java/library/j-grails01158/ where he says, "Groovy is what the Java language would look like had it been written in the twenty-first century."  In that case, does that mean that ColdFusion's CFML is what the Groovy language will look like in another decade?

Comments [0]

Tim Buntel's Blog

I've used a ColdFusion based blog for a decade; Ray Camden's outstanding Blog CFC for most of that time.  Alas, I just spent a bunch of time trying to fiddle with the header and make some other modifications to it and it was taking forever.  Consequently, while I absolutely 100% fully endorse CF and Ray, I'm giving Posterous a try.  I need easy.  Give me easy, please.

Comments [0]

About