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"?

"I Really Don't Know Clouds at All"

Joni Mitchell is best know as a musician, but is she also a 'technology philosopher', ahead of her time?  The growing cloud discussion reminded me of her song "Both Sides Now", and the line "I Really Don't Know Clouds At All"

Do we really have a clear view of clouds? While there is an 'official' definition from NIST*, it's not the same as the definition in business magazines, technology magazines, or tech vendor presentations. The descriptors are all over the place: infinitely scalable, highly available, unreliable, unsecured, low cost, hidden cost, flexible, proprietary ... and the list goes on.
The reality is, they are all true, to a degree. So now what?

Here are five key requirements I recommend you address as you begin your 'cloud journey':

1. 'Risk Posture':  Work with your compliance, security, legal, and regulatory experts to consider items such as:

• Location: What data can reside somewhere outside of my facility, state, country, etc.
• Control: How much control am I willing to give to a third party (think about subpoenas being served to an external provider)?

2. Financial Profile: Determine how you will evaluate the options financially. Key factors include:

• How much am I willing to invest up front?
• How much variability do I want / can I effectively manage?
• Do I want to be able to chargeback (or at least report) at a user / department level?
• Do I understand ALL the associated costs (there are sometimes additional charges for connectivity, etc. that are not well understood / explained)?

3. Service Criticality: Ensure the solution will be capable of meeting your reliability expectations. Contractual terms, while important, are little consolation for critical service failures. When you consider options, make sure you have a full understanding of the technology underneath the solution (e.g., possible failure points, fail-over options, and disaster recovery aspects).

4. Flexibility: Determine the amount of flexibility you want to maintain for future growth, moving to other vendors, etc. While there can be benefits to embracing a specific platform, there are also risks of becoming 'trapped' as new factors emerge.

5. Participation: A powerful option is a 'hybrid' / 'federated' model where some of the service is managed internally, while the remainder is managed by a third party. Determine your ability to effectively manage / operate some of the service internally. This is often a great option for more sensitive or critical functions.

What other requirements are you including in your decision making?

*NIST defines cloud computing as "a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction."

Choose: Transmogrify or Transfigure

Higher Sources of Learning

I lean toward highbrow sources, like comic strips, to guide me on complex topics. 

Calvin and Hobbes often played with a cardboard box labeled 'Transmogrifier'. While Calvin advertised it as able to 'turn you into anything at all', the dictionary gives us a different spin:  "To change or alter greatly and often with grotesque or humorous effect."

Technology Implications

In the context of technology, we run the risk of  'transmogrifying', unless we invest in architecting adaptable solutions that are equipped for:  

• Complexity in the Middle: Plan for dynamic interactions, across a variety of connections, and a wide array of gadgets.
• (Perceived) Simplicity at the Edge:  Expect users to demand stable, easy to use solutions that translate across devices (phone, tablet, PC, etc.)

Fortunately, tools are available, and improving.  Things like cloud services, service oriented architectures, and standards give us the building blocks to create dynamic, adaptable solutions, as long as we invest (time, people, dollars) to architect them.

Choose to Transfigure

Transfigure is defined as "transform outwardly and usually for the better".

      "For the better" or "with grotesque or humorous effect"

Not much of a choice when you put it that way.

What challenges do you face in architecting dynamic, adaptable solutions?

Big Data and The Power of the People

While the alerts may not be as overt as a hazard sign, there are plenty of concerns about the impact of 'Big Data'. Typically, the first reactions include critical technology factors:
  - Where can I store it?
  - How can I  analyze it?
  - How will I report / display it?

Over the past several weeks, I've read a number of articles that encouraged me to step back and realize, we also need to consider the human factors:

• What are customers  generating, and what are they comfortable sharing?
• How quickly can data be 'digested' by decision makers, and turned into action?
• Where does the data link people's behaviors and outcomes?

Here a few of the articles, and I welcome your links and comments, too.

Fast Company: What Happens When Superpowered Customers Meet Smart Touchpoints
Forbes: Big Data: Much Hadoop About Nothing?
HBR Blog Network: Predicting Customers' (Unedited) Behavior
HBR Blog Network: The Big Goal Behind All that Customer Data