eaTWa6): gaming=job skillz, teams=privilege & coopetition

Posted on March 30, 2011 by Rob H

I like slow media that takes time to build and explain a point (aka books) and I have read plenty of business media that I think are important (Starfish & Spider, Peopleware, Coders At Work, Predictably Irrational) and fun to discuss; however, few have been as immediately practical as Brad Szollose’s Liquid Leadership.

On the surface, Liquid Leadership is about helping Boomers work better with Digital Natives (netizens). Just below that surface, the book hits at the intersection of our brave new digital world and the workplace. Szollose’s insights are smart, well supported and relevant. Even better, I found that the deeper I penetrated into this ocean of insight, the more I got from it.

If you want to transform (or save) your company, read this book.

To whet your appetite, I will share the conversational points that have interested my peers at work, wife, friends and mother-in-law.

Membership on a team is a privilege: you have to earn it. Not everyone shows up with trust, enthusiasm, humility and leadership needed.
Video games position digital natives for success. It teaches risk taking, iterative attempts, remote social teaming and digital pacing.
Netizens leave organizations with hierarchal management. Management in 2010 is about team leadership and facilitation.
Smart people are motivated by trust and autonomy not as much pay and status.
Relationship and social marketing puts to focus back on quality and innovation, not messaging and glossies. Broadcast (uni-directional) marketing is dead.
Using speed of execution to manage risk. Szollose loves Agile (does not call it that) and mirrors the same concepts that I expound about Lean.
Being creative in business means working with your competitors. My #1 project at Dell right now, OpenStack, requires this and it’s the best way to drive customer value. The customers don’t care about your competitor – they just want good solutions.

PS: If you like reading books like this and are interested in a discussion group in Austin, please comment on this post.

Substituting Action for Knowledge – adopting “ready, fire, aim” as a strategy (and when to run like hell)

Posted on March 28, 2011 by Rob H

Today my mother-in-law (a practicing psychiatrist) was bemoaning the current medical practice of substituting action for knowledge. In her world, many doctors will make rapid changes to their patients’ therapy. Their goal is to address the issues immediately presented (patient feels sad so Dr prescribes antidepressants) rather than taking time to understand the patients’ history or make changes incrementally and measure impacts. It feels like another example of our cultural compulsion to fix problems as quickly as possible.

Her comments made me question the core way that I evangelize!

Do Lean and Agile substitute action for knowledge? No. We use action to acquire knowledge.

The fundamental assumption that drives poor decision-making is that we have enough information to make a design, solve a problem or define a market. Lean and Agile’s more core tenet is that we must attack this assumption. We must assume that we can’t gather enough information to fully define our objective. The good news, is that even without much analysis we know a lot! We know:

roughly what we want to do (road map)
the first steps we should take (tactics)
who will be working on the problem (team members)
generally how much effort it will take (time & team size)
who has the problem that we are trying to solve (market)

We also know that we’ll learn a lot more as we get closer to our target. Every delay in starting effectively pushed our “day of clarity” further into the future. For that reason, it is essential that we build a process that constantly reviews and adjusts its targets.

We need to build a process that acquires knowledge as progress is made and makes rapid progress.

In Agile, we translate this need into the decorations of our process: reviews for learning, retrospectives for adjustments, planning for taking action and short iterations to drive the feedback loop. Agile’s mantra is “ready, fire, aim, fire, aim, fire, aim, …” which is very different from simply jumping out of a plane without a parachute and hoping you’ll find a haystack to land in.

For cloud deployments, this means building operational knowledge in stages. Technology is simply evolving too quickly and best practices too slowly for anyone to wait for a packaged solution to solve all their cloud infrastructure problems. We tried this and it does not work: clouds are a mixture hardware, software and operations. More accurately, clouds are an operational model supported by hardware and software.

Currently, 80% of cloud deployment effort is operations (or “DevOps“).

When I listen to people’s plans about building product or deploying cloud, I get very skeptical when they take a lot of time to aim at objects far off on the horizon. Perhaps they are worried that they will substitute action for knowledge; however, I think they would be better served to test their knowledge with a little action.

My MIL agrees – she sees her patients frequently and makes small adjustments to their treatment as needed. Wow, that’s an Rx for Agile!

My EV, RAVolt, rides again. Brakes no longer broken.

Posted on March 28, 2011 by Rob H

My EV blog (RAVolt.com) is basically inactive so I’m cross posting the positive news that I’ve got the RAVolt road worthy again! I was able to repair the brake line and learned how to bleed the brake lines (surprisingly easy). Next step is to order some new batteries.

The RAVolt has been idle for over 18 months. With $4 gas around the corner, my timing is looking very good.

Please (I’m begging here) consider the psychology of meetings!

Posted on February 9, 2011 by Rob H

It’s an occupational hazard that I go to a lot of meetings. That’s not a bad thing because my job is a team sport. Except for rare moments of programming bliss, my primary responsibility is to design, collaborate, and coordinate with other people.

The Problem

My problem with meetings is that we often forget about psychology when we are holding meetings. I’m not going to go all B F Skinner or DeBono’s Hats on you, but I want to reinforce that we all have DIFFERENT MODES OF THINKING during meetings. Some examples:

Listening to a presentation *
Giving/getting status *
Designing a product or presentation
Negotiating requirements
Making collaborative decisions
Celebrating success *
Giving subjective feedback

Let’s get concrete. It is impossible to get people to do design during a status meeting. Even if you have the same people in the room, the way they behave (taking turns talking, rushing to finish, linear) during a status meeting is fundamentally different from how I would expect them to act during a design session (dynamic back and forth, pausing to reflect, circular)

It’s even worse when you factor in time bound meetings (I added * to them above) for open-ended activities like design, feedback, and collaboration. If you want to kill ideas or suggestions then ask for them during the closing 2 minutes of a meeting.

A big part of the solution is to remember how people are framing your meeting.

If you want decisions but need to get people up speed then plan a clear end to the status part of the meeting
If you want feedback and discussion then don’t throw in a lot of status or one-way presentations.
remember: Any meeting with a power point deck is a PRESENTATION. It is not a discussion.

Agile Meetings

One of the things I like about Agile is that there is a lot of psychology in Agile!

The meetings in Agile are planned so that people are in the right frame of mind for the meeting.

Stand-up (scrum) is a time bound status meeting. It should be tight and focused.
Review is a FEEDBACK meeting and NOT a presentation meeting. I like to have different people talking during the meeting so that it does not put people into a power point stupor.
Retros are discussion meetings. The must be open ended so people are not rushed.
Planning is a design meeting where new ideas are formed. People must be relaxed so they can be interact and collaborate.

It’s even more important to understand that the way iterations unwind is part of the magic.

Reviews reinforce that team member have completed something. It puts them in the frame of mind that they have closed something and are ready to start on new work.
Reviews give feedback to set priorities so that people feel like they know what’s important. Their expectation is that they are working on what’s most important.
Retros build up team spirit. They celebrate achievement and clear the air so the team can collaborate better.
Retros establish team trust. Trust is the single most essential ingredients for good design because people must take risks when they make design suggestions.
Planning brings together the feeling of accomplishment and purpose from reviews with the trust and collaboration from retros.
Planning should empower a team to be in control of their work and be confident that they are on the right track.
Stand-up, when planning works, becomes a quick reinforcement of priorities.
Stand-up should be status that the plan is on track or lead to a discussion (a new focus) for correction.

If meetings are getting you down then consider what type of meeting your are trying to create and focus your effort on that outcome.

Oh, and my #1 tip for more effective meetings

Find ways to be collaborative by sharing screens, co-editing documents, or just rotating speakers. It’s not a productive meeting when just one person has the conch.

Cloud Gravity – launching apps into the clouds

Posted on December 20, 2010 by Rob H

Dave McCrory‘s Cloud Gravity series (Data Gravity & Escape Velocity) brings up some really interesting concepts and has lead to some spirited airplane discussions while Dell shuttled us to an end of year strategy meeting. Note: whoever was on American 34 seats 22A/C – we apologize if we were too geek-rowdy for you.

Dave’s Cloud Gravity is the latest unfolding of how clouds are evolving as application architectures before more platform capable. I’ve explored these concepts in previous posts (Storage Banana, PaaS vs IaaS, CAP Chasm) to show how cloud applications are using services differently than traditional applications.

Dave’s Escape Velocity post got me thinking about how cleanly Data Gravity fits with cloud architecture change and CAP theorem.

My first sketch shows how traditional applications are tightly coupled with the data they manipulate. For example, most apps work directly on files or a database direct connection. These apps rely on very consistent and available data access. They are effectively in direct contact with their data much like a building resting on it’s foundation. That works great until your building is too small (or too large). In that case, you’re looking a substantial time delay before you can expand your capcity.

Cloud applications have broken into orbit around their data. They still have close proximity to the data but they do their work via more generic network connections. These connections add some latency, but allow much more flexible and dynamic applications. Working within the orbit analogy, it’s much much easier realign assets in orbit (cloud servers) to help do work than to move buildings around on the surface.

In the cloud application orbital analogy, components of applications may be located in close proximity if they need fast access to the data. Other components may be located farther away depending on resource availability, price or security. The larger (or more valuable) the data, the more likely it will pull applications into tight orbits.

My second sketch extends to analogy to show that our cloud universe is not simply point apps and data sources. There truly a universe of data on the internet with hugh sources (Facebook, Twitter, New York Stock Exchange, my blog, etc) creating gravitational pull that brings other data into orbit around them. Once again, applications can work effectively on data at stellar distances but benefit from proximity (“location does not matter, but proximity does”).

Looking at data gravity in this light leads me to expect a data race where clouds (PaaS and SaaS) seek to capture as much data as possible.

Jevon’s Paradox

Posted on December 7, 2010 by Rob H

I’ve been finding it necessary to quote Jevon’s paradox several times lately and realized that I have NOT referenced it here. Quite simply, understanding Jevon’s paradox is essential to understanding cloud.

The concept of the paradox is that when we make something more efficient (for example gas in cars), the demand for that resource goes up (we move further into the exurbs because driving is cheaper). Notably, as Moore’s law drives computer efficiency up, we are using more and more computers. Specifically, I have more computers in my house every year even though the efficiency of just one smart phone far (far) exceeds power of my son’s Sinclair 1000.

In cloud computing, Jevon’s paradox points us to the expectation that the rush of applications and activity in the cloud will continue to accelerate. Since I expect competition and Moore’s law to drive increasing gains in cloud efficiency (and therefore customer advantageous price signals) the market will happily convert these utilization improvements into more and more interesting capabilities.

The cloud expansion means that we can sustain more providers entering the market. In fact, Jevon would tell us that more providers will likely INCREASE demand for cloud as competition and capacity put downward pressure on prices. [Q: where will they make up the margin? A: Adjacent Services]

The loser in cloud’s exploration of Jevon’s paradox are non-cloud deployments (Dell strategists are you listening?). These systems suffer because their ability to improve their efficiency is limited.

As I look down the road on cloud, I can see many opportunities for current applications to take advantage of cheaper cloud resources to provide even more value. For example, adding map-reduce analytics to scan a customer’s data can provide tremendous insights. Today, it’s a luxury like flying on the Concorde. Tomorrow, it will be part like hopping the Nerd Bird from San Jose to Austin – just a normal part of our daily lives.

Note: A shout out to Dave McCrory who introduced me to Jevon’s Paradox.

Exploding the Cloud Storage Banana

Posted on November 17, 2010 by Rob H

Storage Banana shows how cloud persistence is functionally diverse and optimized

Internally, my group (specifically Dave McCrory & Greg Althaus) has been kicking around some new ways of expressing clouds in an effort to help reconcile Dell’s traditional and cloud focused businesses. We’ve found it challenging to translate CAP theorem and

externalized application state into more enterprise-ready concepts.

Our latest effort led to a pleasantly succinct explanation of why cloud storage is different than enterprise storage. Ultimately, it’s a matter of control and optimization. Cloud persistence (Cache, Queue, Tables, Objects) is functionally diverse in order to optimize for price and performance while enterprise storage (SAN, NAS, SQL) is control and centralization driven. Unfortunately for enterprises, the data genie is out of the Pandora’s box with respect to architectures that drive much lower cost and higher performance.

The background on this irresistible transformation begins with seeing storage as a spectrum of services as per the table below.

Enterprise: Consistent	Block (SAN)	iSCSI, Infiband: Amazon EBS, EqualLogic, EMC Symmeterix
	File (NAS)	NFS, CIFS: NetApp, PowerVault, EMC Clariion
	Database (ACID)	MS SQL, Oracle 11g, MySQL, Postgres
Cloud: Distributed Partitioned	Object	DX/Caringo, OpenStack Swift, EMC Atmos
	Map/Reduce	Hadoop DFS
	Key Value	Cassandra, CouchDB, Riak, Reddis, Mongo
	Queue (Bus)	RabbitMQ, ActiveMQ, ZeroMQ, OpenMQ, Celery
Cloud: Transitory	Messaging	AMPQ, MSMQ (.NET)
Cloud: Transitory	Shared RAM	MemCache, Tokyo Cabinet

From this table, I approximated the relative price and performance for each component in the storage spectrum.

The result was the “cloud storage banana” graph. In this graph, enterprise storage is clustered in the “compromise” quadrant where there’s a high price for relatively low performance. The cloud persistence refuses to be clustered at all. To save cost and enable distributed data, applications will use cheap but slow object storage. This drives the need for high speed RAM based cache and distributed buses. These approaches are required when developers build fault tolerance at the application level.

Enterprises have enjoyed the false luxury of perceived hardware reliability. Where these assumptions are removed, applications are freed to scale more gracefully and consider resource cost in their consumption plans.

When we compare the enterprise Pandora’s box storage to the cloud persistence banana, a more general pattern emerges. The cloud persistence pattern represents a fragmentation of monolithic, IT controlled services into a more functional driven architecture. In this case, we see desire for speed, distribution and cost forcing change to application design patterns.

We also see similar dispersion patterns driving changes in compute and networking conventions.

So next time your corporate IT refuses to deploy Rabbit MQ or MemCacheD, just remember my mother’s sage advice for cloud architects: “time flies like an arrow, fruit flies like an banana.”

Cloud Gravity & Shards

Posted on October 26, 2010 by Rob H

This post is the final post laying out a rethinking of how we view user and buyer motivations for public and private clouds.

In part 1, I laid out the “magic cube” that showed a more discrete technological breakdown of cloud deployments (see that for the MSH, MDH, MDO, UDO key). In part 2, I piled higher and deeper business vectors onto the cube showing that the cost value of the vertices was not linear. The costs were so unequal that they pulled our nice isometric cube into a cone.

The Cloud Gravity Well

To help make sense of cloud gravity, I’m adding a qualitative measure of friction.

Friction represents the cloud consumer’s willingness to adopt the requirements of our cloud vertices. I commonly hear people say they are not willing to put sensitive data “in the cloud” or they are worried about a “lack of security.” These practical concerns create significant friction against cloud adoption; meanwhile, being able to just “throw up” servers (yuck!) and avoiding IT restrictions make it easy (low friction) to use clouds.

Historically, it was easy to plot friction vs. cost. There was a nice linear trend where providers simply lowered cost to overcome friction. This has been fueling the current cloud boom.

The magic cube analysis shows another dynamic emerging because of competing drivers from management and isolation. The dramatic saving from outsource management are inhibited by the high friction for giving up data protection, isolation, control, and performance minimums. I believe that my figure, while pretty, dramatically understates the friction gap between dedicated and shared hosting. This tension creates a non-linear trend in which substantial customer traction will follow the more expensive offerings. In fact, it may be impossible to overcome this friction with pricing pressure.

I believe this analysis shows that there’s a significant market opportunity for clouds that have dedicated resources yet are still managed and hosted by a trusted 3^rd party. On the other hand, this gravity well could turn out to be a black hole money pit. Like all cloud revolutions, the timid need not apply.

Post Script: Like any marketing trend, there must be a name. These clouds are not “private” in the conventional sense and I cringe at using “hybrid” for anything anymore. If current public clouds are like hotels (or hostels) then these clouds are more like condos or managed community McMansions. I think calling them “cloud shards” is very crisp, but my marketing crystal ball says “try again.” Suggestions?

Rob Hirschfeld

On Computing, Containers, Cloud & Tech Culture

Category Archives: Open Trends