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

Mobility: From the Smartphone and Beyond

How did you get your last sports score, the weather for tomorrow, or the information for that new gadget? Increasingly, you are using your smartphone. In many cases, you have a specialized 'widget' that keeps it updated on your screen - you don't even have to look for it.

While this isn't news, have you considered what this means for you and your company? Here are a few thing to think about:

• 'Landscape':  Think of an index card, not a notepad - an iPhone, not a monitor. The smaller screen requires you to understand what your users / customers want first, and how they can easily get to the next item (hint - think 'tap' or 'swipe' versus 'scroll'). If you just try to 'shrink' your current 'landscape', you'll lose.
• Secure Personalization:  People love 'at a glance' service. The weather icons with current local conditions or small box with the most recent score update. Beyond size, you must have a way to know who they are, and handle it as a trusted friend. People need to be confident that 'private' is TRULY private, and as secure as their bank / wallet.
• Omnipresent:  Alas, people want multiple entry points, but will want the personalization to seamlessly follow them. They will also want the interface to adapt to the change in size and function.

Technology leaders will need an ever growing toolbox to meet this challenge, including:

• 'Big data' platforms for the personalization
• Multi-platform security tools
• A new breed of development skills / tools that loosely couple the functions and user interface

What other things should we be considering?

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?