Lessons from Shoes

There is a pile of shoes by my front door. Having lived in Florida for over 18 years now, they are mainly flip-flops, but there are a few others, too: Sneakers, 'yard shoes' (a.k.a. worn out sneakers), etc.

Maybe this is corny (I'm sure my kids would agree), but it made me think about the diversity of influences in my life, and the shoes associated.  Let me explain...

Boots - Steel toe, cowboy boots, etc. Chewing cactus when you're thirsty, getting thrown from a horse, barbed wire, shovels, and lawn mower. I learned that hard work, even when it's unnoticed, should be done with excellence because that's simply how work is done. 

Athletic Shoes - The dynamics of coaches, team-mates, and competitors. The mixture of victories, defeats, encouragement, tough discipline (in particular, running lines after a particularly bad game). I learned that often success relied on different roles and various forms of motivation.

Comfortable Shoes - Teachers and health care professionals that had to be on their feet all day. Feeding minds, healing broken bodies, comforting the hurt and frustrated. I learned that investing in people is worth it - even if you can't measure it in your bank account.

Dress Shoes - The shoes of corporations and churches (at least when I was growing up). I learned about the 'real world' of business. Negotiating, higher revenues, lower costs, tough decisions. Most importantly of all, I learned about God, faith, grace, and the truth about love.

Flip-flops - My personal favorite.  I learned that sometimes, you just need to relax, see the beauty of the outdoors, and let your (quickly disappearing and graying) hair down.

The key point - I'm the product of diverse people and lessons. Each critical to my development. Some formal, some informal. Some fun, some painful or tough.

What did I leave out?  I'd love to hear your perspective!

What you DIDN'T learn in junior high...about clouds

Over a year ago, I jotted down my thoughts on making decisions about 'cloud' solutions.

While I referred to NIST (Link to NIST's definition), I thought it would be useful to offer a simple model that you might use for discussions with your colleagues, boss, or boss's boss.  Plus, it may help identify opportunities for further investigation and use.

For simplicity, you can describe 'clouds' with three main questions:

• What's special about it?  Characteristics that differentiate cloud services from traditional services.
• Where is it?  The location of the control, the actual systems, etc,
• How 'tall' is it? What components are provided?

What's Special About It?

Mainly, flexibility and adaptability.  'Cloud' architectures are focused on the ability to quickly morph to the needs of the users and owners.  Examples include:

• Access: Use the services from any device, and any network, at any time
• Scale: Quickly and effectively add more functions, users, computing power, storage, etc.
• Functionality: Acquire as individual pieces, pre-assembled components, or complete solutions.
  NOTE: The section on "How 'tall' is it?" will describe this further.

Where is It?

Many people immediately picture something that is 'out there' - out of my facilities, out of my control...  As a result, they quickly dismiss it, and miss the benefits.  In fact, there are three general 'locations':

• Private: I own it. Fully owned and controlled for a single entity / business.
• Public:  I rent it. Another firm owns and controls it, and let others use it, typically for a fee.
• Hybrid: Integration of owned and rented.  The private components are blended with public components to deliver the full, flexible service.

How Tall is It?

This is probably the most complex part...

• Software as a Service: Ready to useAn all inclusive service.  The free e-mail services are good examples. They provide the e-mail software, underlying and connected functions, as well as the supporting hardware. All you need is a device, and enough network connectivity to reach it.
• Platform as a Service: Some Assembly RequiredProvides one or more pre-assembled components that can be used to create a service.  An example would be a 'database as a service'. The service provider delivers a fully functioning database, including the necessary storage, computing, and database software. However, additional components and integration is typically required to create the entire solution.
• Infrastructure as a Service: Do it YourselfDelivers Individual infrastructure components, typically computing or storage. In this model, other infrastructure, software, and integration is needed to 'assemble' the full solution.

While the full journey will include variations on these themes, complex issues, and tough decisions, this should prepare you to start.

What are your suggestions for starting a 'Cloud' journey?

Riding the Waves of Chaos

I'm blessed to live close to the Atlantic Ocean, where I can frequently visit the beach, and watch the waves. While the general patterns of the tide are somewhat predictable in terms of timing and height (predictable does NOT equal uniform),  the waves themselves can vary dramatically, and the wind adds its own 'spin'. This drives different rates of erosion and rebuilding. Sometime, a major storm will drop in huge loads of sand, and at other times it takes huge bites. More frequently, the changes are subtle. Sometimes, people intervene to make changes.

So what does this have to do with technology leadership?  Let me suggest a two parallels:

• Unpredictable:  While we can partially predict / plan for specific components, the overall system is somewhat chaotic. In the context of technology, we experience interacting cycles of development for the sub-components (servers, storage, networks, etc.).  Each cycle can be somewhat predictable, but the overall effect is somewhat chaotic.
• Sometimes Constructive, Sometimes Destructive: With diligence, good leaders can set a course for these 'waves' to create constructive outcomes. However, the 'best laid plans' will occasionally be thwarted due to an unexpected entry, or an unfortunate 'mixture' of things.

As I've worked in the IT industry for over 20 years, a few ideas have developed to deal with these challenges:

• Establish a Solid Foundation: Prioritize and protect the critical (it will differ by situation), change carefully, regularly re-evaluate / confirm.
• Keep Planning, But Don't Over Plan - For the critical, plan carefully, long and deep, but don't apply the same rigor for everything. That would prevent you from learning about future risk scenarios, that your end users will request / 'find' for you.
• Allow for Errors: As much as possible, leave some 'slack' between compoents that will give some cushion for errors and wiggle room for changes.
• Manage Expectations: Make sure your partners, end users and executives recognize that 'one size DOESN'T fit all', and include them in identifying opportunities and priorities (e.g., where can we try something new, where can we take more risk, where do we need to eliminate risk, etc.)

What are your recommendations for managing through the "chaos"?