When Is Offering Services "In the Cloud" a Good Idea?

Companies such as Google, Amazon and even Microsoft have shown that providing key IT services such as email, compute and office productivity software successfully as online "on demand" services. This has opened the floodgates across the market, with more and more services these days being provided to consumers and businesses in an on-demand delivery model.

I recently was at a large multinational company that was trying to determine how best to offer their software as an online "on-demand" service.  While they have a rather unique set of challenges before them, there were still a set of questions that I felt any company who might be considering moving into the online delivery model should really ask themselves before taking the plunge.

What are the Drivers for Making the Move?

This question is not as silly as it may sound.  Sometimes a business gets excited or ahead of themselves and the market, whether from reading about online service successes in other industries in the press or a Gartner analyst report.  While moving your products "online" might be that key angle that might help you beat your competition or gain significant market share, you need to look at how big of a leap it might be for the market and your customers.  If customers are familiar with using your software through thin clients or clean latency agnostic web service calls, and/or you are already losing sales because the up front costs and hassle for equipment and IT support for your customer is just too high for them to bear, then it might be a great move.  If, however, you are providing more traditional thick clients, and/or are providing software that tightly integrates with other internal software and systems, you may want to do much more legwork to see whether or not providing your services in an externally hosted manner is viable.

What is the Market Landscape?

Have you been confronted with requests to provide your services in an on-demand online way?  Are there competitors in the market who have offerings that are provided in a Software as a Service model? Have you seen customers wanting to move more of their costs from capex to opex?  Are there challenges with customers who want to see their costs more accurately reflecting their usage in order to get away from the trap of having to cover arbitrary license fees or having to scale up for some peak load that happens for only short periods during the year?  Are your customers frustrated at the level of skill and customer service that their own internal IT departments provide?  Any of these may be a good reason to seriously consider creating an on demand offering.

If, however, your customers are all scared by the concept of externally hosted solutions, either for security and control reasons, or worse they feel threatened that you might take away their jobs, you might need to ask yourself whether the market is ready yet for such an offering.  While it may still be possible, if you find yourself constantly in a missionary sales mode to potential sales leads who really like your software but are extremely skeptical of an online delivery model, you may need to either significantly bolster the strength of that model (and the way you sell it), or back away from it for the time being.

What is the Legal/Regulatory Landscape? 

Many businesses have to work within a rather tough legal and regulatory environment. Whether it is banking, medical, utilities, telecommunications, broadcasting, aerospace, government or some other industry, each has its own peculiarities with systems, security and data handling that needs to be well understood before diving in.  Some of these, such as safe harbor rules, severely restrict where data can be held and who can handle it how, often with not just organisational boundaries but even geographic and political boundaries as well.  They are complicated and often tough to deal with.  However, there are very few that, with awareness backed by solid systems, controls and policies in place to handle them, that cannot be overcome.  It is often a bar that is set extremely high, often by people who are scared of or highly skeptical of any software that sits outside of systems that they can physically touch and stare at the blinking lights on the chassis.  I have dealt with many of the toughest ones out there. In more than one instance I found myself in situations where the regulator was at first convinced it wouldn't work.  It was always tough, but by understanding what they were looking for and why we always managed to get through.

If you provide solutions for these sorts of industries and cannot effectively speak to and prove your compliance, you will either need to put in the investment to be able to do so or not offer them.  As a side benefit of getting your act together is that it not only helps strengthen you message, but if you do it right it can help you understand if you can provide your services effectively.

Can Your Software be Sold Profitably as a Service?

Providing service offerings is hard.  You need to get a lot more things right in order to ensure that you can not only provide a service that customers want to buy, but that you can make a profit while doing it. The first thing that you need to understand is if your service is perceived as usable by your customers in an online delivery model.  This means that you need to understand how they will access it, how they will work with it, and what sort of performance they will be expecting.  When I was at Yahoo!, we used to look very closely at people's behavior to better understand what their expectations were for product performance.  We noticed that people had different expectations depending upon what they were doing. If they were reading text they would have different expectations than toggling through an interface, and different again for consuming feeds, which even varied on the type of feed, and again there were differences in expectations of performance for watching videos.  When we began to understand these, it heavily influenced our architecture and deployment models.  We could perform a variety of very neat tricks that made things look and act responsive, even over dodgy internet links.  We even became sophisticated with how we would pair and serve solutions, and how and where we would host them.  Without understanding more about our customers, we would have just been stabbing in the dark.

Another aspect is what does the cost structure look like for running your service.  Are you able to provide your services in a multi-tenant way, or do you have to have standalone setups for each customer?  Does your service require beefy and expensive systems that significantly stairstep your costs or can you scale horizontally with cheap systems?  Do you require expensive software licenses and vendor solutions that significantly push up your costs?  Can you match these costs to a sensible charging model that doesn't simply look like a pile of up front costs like they would see if they hosted it internally, yet still allows you to make a profit, even if it is down the line?  If the charging model is use-based, can it be sensibly measured in a way that actually ties to a customers usage (and optimally to their sense of value) and not an itemized list of the underlying systems, licenses and support costs? Many get this wrong, which is unfortunate.

The final elements are arguably the most important, which is are you and any partners/suppliers you are dependent upon capable of providing a sufficiently high level of service for your customers while being cost competitive and without destroying your bottom line?  Providing your services as an on-demand utility pushes customers to expect a far higher level of service than they could cobble together themselves.  They expect that you are going to be responsive and reliable, and are not going to lose their data or lock them out.  They do not want to have to think of or ever be concerned about what IT ugliness might be going on underneath the covers of your offerings.  They will want the services to always be available when they want them.  They will also want things like upgrades to be seamless and not require any effort or inconvenience on their part.  These are all very difficult to meet, however are often what can make the sale if you can confidently provide it.

Do you have the skills/know-how to Build and Support a Service?

Building and supporting a SaaS solution is very different than doing it for the same solution offered as shrinkwrap software.  You are now responsible for running the service, meaning that you can no longer hide behind a customer's internal IT group and environment.  You are responsible for designing, building and supporting the full stack that provides the service, and are expected to do it at a level far superior than any standard IT organisation.  That is hard, and requires a very different approach and thinking end to end.

First, you need to ensure that you are creating a design and architecture that is resilient and supportable. You need to think about how tightly coupled various subsystems are with each other.  You need to think about every way that your service can fail and try to ensure that it will fail gracefully if not seamlessly.  You will have to think through how to instrument up your entire stack to allow for better monitoring and management of it.  You will find that this will need to be far more than just heuristics style monitoring, but also will require understanding usage patterns and how the various subsystems perform on their own and with one another.  You need to think about how you handle data, how you can manage and ensure its integrity, and how you can clean things up and keep any necessary separation between users and customers.  You need to also think through access management at all levels, both within the service as well as across the entire service ecosystem, including the infrastructure.  Related to this, you will need to think through all security elements, including things such as intrusion detection, denial of service attacks, security perimeters, and how to ensure the sanctity of your environment.

Then there are the build and deployment aspects that need to be thought through.  How large and frequent are releases?  How are things built, packaged and configured?  Are deployments manual or automated, and can they be rolled back and reproduced?  How upgradable is the service and infrastructure, and does it require downtime?  How are changes sized up for their risk levels, and who makes those decisions?  These all sound fairly straightforward, though most companies get these very wrong.

Finally, do you have the skills and staff required to run and support your service operationally?  Can they monitor it and ensure its uptime and integrity?  Can they handle incidents and requests quickly and effectively?  Are they well versed in security and service continuity, always thinking about the safety of the environment and how to make it more robust yet still manageable?  Can they effectively work and coordinate with suppliers, ensuring both incidents as well as requests are handled quickly and seamlessly to both you as well as your customers?  Are they constantly aiming to and are able to continually improve the service and how they are able to manage it?  Have you thought through how your customers will engage with you from an operational and support standpoint across the service lifecycle, including onboarding, during run, as well as some eventual offboardings that may happen?

Final Thoughts

Software as a Service solutions are the way of the future.  It democratizes the market, lowering the barriers of entry for both customer as well as supplier.  It greatly reduces the level of cost and friction between customer and supplier, and should allow for customers to experience a level of quality and resilience that they cannot afford to provide internally.  However, it requires a great deal of end-to-end thinking in order to create a successful SaaS offering.  

Are You Aware of Your Differentiating Assets?

A week ago I had the pleasure of being invited to a private talk with Sir Jonathan Evans, former Director-General of MI5, on the theme of Digital Security. While many of the topics of the evening were quite pertinent to so many of the recent news events, there was one item in particular that really stood out. Evans stated that one of his missions was to try and reach out far and wide to government ministries, universities and corporations and ask:

“Are your important assets understood and secured from theft and sabotage?”

How many people and companies have properly asked themselves this question? How many can actually explain why those assets are important, and to whom? Do they differentiate you or your firm from the rest of the market? How many target the acquisition of those assets and then know once they have them? To take it even further, how many can articulate whether or not those assets that they have are effectively exploited?

These are questions that apply not only to businesses, but also to each and every one of us in our private lives as well. Let’s step through and explore a little more.

Assets

The first place to start is to look around at your assets. Assets are those things that have qualities or capabilities that can be somehow exploited to provide value. Assets can be physical (like tools, vehicles, property), financial (monetary instruments and credit), human (not only headcount, but also skills and culture), intellectual (which is not just things like patents, but also includes knowledge as well as data that has the ability to provide knowledge and indicators), and relational (these are usually things like commercial relationships or standing contracts that might allow for preferential or enhanced access and treatment not ordinarily available to others).

Most people and firms will go to some lengths to put in measures to secure physical assets. This is the reason for elaborate locks, alarm systems and guards. They may not do the best job of securing and tracking these and thus experience lossage, sometimes with severe consequences. Similar measures are often used for financial assets, which unless you are working with billions in financial instruments or are large enough to have your own Treasury Department, might be mostly outsourced to banks who are also simultaneously putting some of it to use for investment returns.

Human, intellectual, and relational assets, however, are far more elusive. Many companies only pay lip service to the value of their people. In some industries and areas people may be fungible enough that losing people has relatively low impact. However, as competition and innovation become ever faster and more knowledge dependent, losing staff becomes ever more costly. Often there are important skills and relationships that go into really making a product that are neither visible nor necessarily easily transferable to other staff. Understanding these dynamics, and putting in sensible safeguards to build staff loyalty and prevent poaching is important. For most companies, the best people are often the first to leave when conditions deteriorate.

Intellectual assets are even trickier. They are often invisible even to those within an organization. Theft through unauthorized analyzing or copying by external parties rarely leave any trace, even though the theft of such assets can have a significant impact. However, intellectual assets are even more vulnerable to two bigger scourges: tampering and neglect.

Tampering

It is rather easy to tamper with intellectual assets. Whether it be tweaking source code, fiddling with configurations, or twiddling with data without some form of tracking you are tampering and may not even realize it. Most tampering may be inconsequential, but occasionally unexpected mayhem may ensue, especially if the tampering is malicious. Tampering can not only cause vital systems to fail, but when it affects data and metrics can cause incorrect conclusions to be made that lead to disastrous actions being taken. Troops can be sent the wrong way. Investment firms can dump or buy assets that cause market instability and damage the firm. Companies can dump or damage their products, services and supply chains. The FDA has even warned recently that many medical devices and hospital networks can be tampered with, flooding patients with insulin or causing pacemakers to dysfunction.

Few properly think about and assess the dangers of tampering, with even fewer putting safeguards in place to minimize the risk of it happening. This doesn't mean that one needs to develop a high level of paranoia about everything, but there is value in understanding how exposed your assets are to tampering.

Neglect

Lack of awareness and neglect are potentially even more harmful. Data and assets are lost all the time, often disappearing through faulty storage, handling and backup. Many people know that NASA has lost large amounts of data from the early space programs, including the Apollo lunar missions, due to an inability to recover data stored on the 7-track reel-to-reel tapes used at the time. While that is an extreme case, I have run into many companies who have lost source code to critical systems due to general mishandling and improper source code control systems. In several instances I have personally witnessed, this has cost companies millions and severely hamstrung the business. I have also seen many cases where lost knowledge of systems, software, and even test harnesses built long ago have caused huge amounts of mayhem when they have later needed to be updated or replaced. It has been suggested that this may be part of the cause for the embarrassing mainframe outages at RBS/NatWest where people were locked out of their bank accounts for days on end.

Awareness of your assets and capabilities will help with ensuring that neglect does not become built in. It takes a great deal of effort to build in this sort of awareness, especially in large and well-established businesses. However, there are ways to gather and audit that can be put in place to first understand the size of the problem, then steadily fix it over time.

Differentiators

For both companies as well as individuals, both the understanding and being savvy with utilizing your assets is what differentiates you from your competitors. This is why it is important to both understand as well as protect and enhance them constantly.

I have seen many businesses outsource large chunks of their business to outside firms. For non-core and undifferentiated parts of the business this often makes sense. However, I have seen large numbers of firms also outsource core, near-core, and differentiating parts of their businesses, only leaving the executive suite and some minor elements of sales and marketing within the business. Without careful oversight this can be extremely dangerous. I have seen cases where companies have become so dependent upon one outsourcer for a key piece of the business that losing them would mean that the business would stop, perhaps catastrophically. I have also seen where the business ultimately ends up in competitive situations with the outsourcer and are incapable of competing cost effectively. Outsourcing Research and Development means that without very careful shepherding you risk becoming beholden to the outsourcer for innovative progress. Outsourcing customer service and support can potentially risk losing control over the level of quality of contact with the customer, potentially harming both reputation as well as future sales. The quality of these services are often differentiators to your customer in the marketplace.

Businesses need to think through what are their differentiators, and whether they are effectively protecting and enhancing them.

Awareness and Exploitation

It is key to be aware of your assets, not only what and where they are but also whether they are understood and secured from theft and sabotage. As they are not always obvious or visible, it often requires regular effort to ensure that they are accounted for and used effectively. Both individuals as well as businesses should regularly take stock of what they have, and determine whether and how they are used to effectively differentiate you from the rest of the market.

The Confusion of DevOps

"What we got here is... failure to communicate."

                              -- Captain of Road Prison 36,  Cool Hand Luke (1967)

I am noticing more and more frequently these days that the term "DevOps" is being used to describe a staff position or department and sets of tasks that can best be described as deployment configuration management and automation.  The role seems to have been derived from so much confusion that has come out of a mixing of the heavily related Continuous Delivery, Infrastructure-as-Code, Service Engineering, and DevOps movements that have been swirling around in various forms for the last several years.  While it is difficult to talk about any one of them without referring to elements of another, the fact that they have all somehow been combined into a new job family is not only disconcerting, but may potentially represent a general misunderstanding of the larger issues that exist between IT and the rest of the business.

Businesses constantly seem to be struggling to come to grips with the constant changes that are happening across the business, especially in IT.  Business leaders barely had come to grips with the whole concept of the Internet, Just In Time manufacturing techniques and multimodal telecommunication methods when suddenly the Agile and Lean movements, Continuous Integration, virtualization, elastic computing, and on-demand software services arose.  Each of these innovations has demanded significant changes to interactions, behaviors and understandings of people across the organization.  In return they deliver ever faster and ever cheaper ways of innovating and serving the market. 

Mainstream businesses have struggled to understand many of these concepts, and are only now beginning to seriously make many of the necessary steps to adopt them.  Few have gotten far enough along to really effectively handle them while also absorbing the next wave of change that is already on top of us.  This next wave includes not only the significant changes at delivery and run that come with Continuous Delivery, Infrastructure-as-Code, and Service Engineering, but also more advanced topics such as the flows and collaboration required to actually achieve what is aspired to in DevOps, the complete mindset change that comes with Outcome Delivery in the Product Development space, and changes arising in the legal contract and financial spaces.  This next wave is building upon the knowledge, learning and expertise created by successful pioneers from the earlier wave. 

Anyone who has made significant inroads into these next wave approaches knows that true power in them requires proficiency if not mastery of earlier concepts.  Continuous Delivery is not terribly effective if neither Continous Integration or the short iterations of Agile methods are in use.  DevOps is really the next step in collaboration.  It further blurs the remaining team boundaries to eliminate any remaining friction and gaps in roles and responsibilities that negatively affect service health and continuous improvement. It simultaneously shores up and strengthens the professional rigor that once organizational boundaries tried to uphold. The mindsets that are established in the earlier movements, such as frequent and rapid adaptation to feedback and working collaboratively in cross functional teams, are all important prerequisites.

Businesses are finding themselves in an uncomfortable spot.  They are realizing that they need to make massive changes in order to stay competitive.  Yet so few people within their ranks properly understand these new ideas enough to effectively implement the changes required by them.  There just simply doesn't seem to be a nice and neat place to handle this sort of change in the traditional organization.

So they create one.

In the past some companies simply made the move to outsource their IT in the hopes that the problem can become that of their outsourced partner. Some may still opt for this option in light of these challenges. This often only makes the problem larger by putting entire corporate entities and business profit models between IT and critical business functions.  Many of these companies have learned that IT is in fact a critical capability within their business, one that can only effectively be outsourced when doing so neither impedes business change nor lets go of the company's value add in the marketplace in a way that leaves the business completely hostage to the outsourcer.

Perhaps it is worthwhile to look deeper into the industry to see what is going on.
Much like the mess that is "Cloud Computing", the term seems to be pervading ever further across the industry, to the point where it is being used so frequently that otherwise intelligent people are starting to give in and use it to get a point across.  

By packaging "DevOps" into a nice compartmentalized role in the organization, many businesses seem to be tipping their hat to the problem and hoping that filling those roles will somehow accomplish what is needed with little additional need for change.  This is similar to the relatively recent fallacy that buying VMWare and virtualizing your legacy server estate will allow them to avoid the legacy architecture headaches and somehow give the organization "Cloud Computing".  These water down not only the meaning of the movements, but also provide fodder for those who are actively resistant to change by creating compromising stillborn half measures they can point at to say they aren't real.

Having been brought in time and time again to sift through the damage and placate the injured in such poorly implemented change efforts, I hope that this half-baked compartmentalized trend will somehow reverse and not damage yet again another great set of ideas.

I am speaking at Agile 2013

I have been very busy over the past few years honing my arsenal of techniques for creating high performing services and organizations.  In particular, I have been actively working with clients in live situations methodically trying to capture the key essence behind my most effective techniques.  Having seen so many otherwise smart people struggle for so long, I hope to add to the collective knowledge out in the industry to not only help others but to also hopefully reduce the amount of dysfunction that so many have to deal with on a day to day basis.

The talk that I will be giving at Agile 2013 covers one of the elements that I have discovered, which is how to find and improve flow and transparency across an organization.  I have found that many of the techniques I use, including looking for places where friction develops and queues build up, places where communication breaks down or is misinterpreted, and where there are knowledge gaps that form across organizational siloes, have very similar analogues in Lean.  The spirit and mindset that has been built up in the immense body of work within Lean can, when added to both the technical and architectural techniques that have been steadily arising from XP and elastic computing as well as the rapid product development techniques that have been coming from HotHousing and Lean Startup, go a long way to helping IT organizations improve and better serve customers.

Human Cognition - Cultural Bias Beyond the WEIRD World

Anyone who has lived for any length of time in a culture that is different from the one they were originally raised probably noticed differences, sometimes subtle, in the way that those in the different culture observe the world and things around them.  The more different the culture, the sharper these differences become.  Many people simply discount these differences are quirks.  What scientists are beginning to find is that these "quirks" are often significant, and the differences challenge long held assumptions of human psychological universality. A recent write up in Pacific Standard (found here) goes into detail on what scientists are beginnning to find.  Both the article as well as the research study behind it are an excellent read.

In short, it states that the "generalized standard" for the vast majority of human psychology, cognition and behavior research studies in the world's top journals is based almost entirely upon people who come from Western, Educated, Industrialized, Rich, and Democratic societies (WEIRD).  What scientists are now finding is that there is substantial variability in the way that different cultures perceive the world, from fairness, cooperation, spatial reasoning, categorization and inferential induction, moral reasoning, reasoning styles, self concepts and related motivations; and that population groups from the "generalized standard" are particularly unusual and frequent outliers compared to the rest of mankind.  Americans in particular fall at the extreme end of the scale even within the unusual population of Westerners, making them "outliers among outliers".

This brings into question a wide body of underlying assumptions, ones that form much of the foundation of societies.  If there are fundamental differences in the fabric of how people from different cultures observe the world, how can this be reconciled within the rules that make up everything from civil norms, the ways that people do business, and even education?  Might it even be possible to exploit the potential richness of different mental models within a business or community to make it a business or community more successful?

While different models can and do cause confusion and misunderstanding, they can also provide a richness that spurs creativity and innovation.  Perception that is different than your own is neither necessarily better or worse than your own.  It is simply different.  Exploration of these differences allow you to see potentially useful concepts that otherwise you may have missed.  People, from businessmen to the intellectually curious, have studied concepts as far ranging as Japanese business practices to Buddhism and Eastern mysticism. Steve Jobs, someone that many find to be a creative genius, was inspired by Zen Buddhism.  Others have been heavily influenced by experiences they and their families have experienced, from famines and depressions to wars and idealogical conflicts. They all leave imprints upon the way people approach problems, and being aware of them and their impact upon your mental models goes a long way to allowing you to not only better understand yourself, but also to help open yourself up to other models as well.

Those who are open to exploring often find entirely new ways of thinking, allowing themselves to question the previous certainty of the world around them and opening up entirely new opportunities that they would have otherwise completely missed.

Can businesses also take advantage of this?  Many businesses talk about diversity, but more often than not retain a certain rigidity to their own internal culture.  Opening up to different models, not in a soft HR-led politically correct way but in a much more scientific approach, may allow businesses to be both more innovative.  They also may help companies spot potential "perception misalignments" that may introduce risks to the business.

I apologize, but we appear to be separated by a common language

 "I apologize, but we appear to be separated by a common language"
  -- overheard in the hallways of an international corporation

The role of communication is enormous in the modern world. It has become the backbone of entire industries, allowing for ideas to spread ever more quickly, merge with others to create completely new paradigms, all while destroying many of the monopolies of old. In many fields the speed of communication is the new arms race. However, as we all become ever more interconnected, we increasingly have to run the obstacle course that is our unique backgrounds, cultures, mental models, and even speech patterns. While mental models is a big enough topic for another post, I thought it would be worthwhile to start with the joys of communication in what many mistakenly think of as one consistent and unified language: Modern English.

For those of us who were (un)fortunate enough to grow up with English as our native tongue, one would think that we would be seemingly blessed with the fact that our language is becoming ever more ubiquitous, especially in booming fields such as technology and business. While it is definitely great to be able to convey thoughts and ideas in your first language (as those of us who have tried to in a language we came late to knowing can attest), the infinite flexibility, adaptability and regional differences of English have opened a myriad of opportunities for misunderstanding, confusion, hilarity and very occasionally complete system failure even between native speakers. What are non-native speakers to do? 

Having now lived and worked internationally for a long time, you encounter misunderstandings and lost meaning amongst people almost every day.  After a while, you have to learn to watch your language and to check to see that you were understood, especially when using cultural references. Amusingly, one of the places where I have found some of the biggest and most dangerous misunderstandings were amongst those native to the supposed birthplace of the language:  England.

If you are from a large and fairly cultural and linguistically homogeneous place like Canada/US (where I am from originally) and Australia/New Zealand (where my wife is from), you might occasionally run into communication problems if people are either non-native speakers, not American/Canadian or Kiwi/Australian, or have one of a very small number of challenging regional dialects (such as Cajun, Newfoundland English, Deep South, and some New Yorker and Bostonian accents).  It is generally very rare for the misunderstanding to last long, and (unless it is a Québécois trying to be difficult) rarely does it devolve into complete communication breakdown.  Perhaps it is due to the relatively recent settlement of these countries and the rise of modern media that has helped.  Regardless, this homogeneity gives a false sense of certainty that what you say will be understood, at least for the way you meant it to be.

Across English speaking country groups the confusion really begins.  Even though the language and structure is more or less the same, and even many of the literary and media references are mostly shared, regional terms and cultural references are often lost. Between the North American cluster and the Australia/New Zealand one there are occasional misses, though whether it is due to similar historical backgrounds or the more direct nature of the cultures to quickly catch and fix these usually keeps these to a minimum.

This all seems to go out the window in the UK.  While one would expect some differences between Wales, Scotland, Northern Ireland, and England, there are also significant difference across England itself, sometimes even between two towns that sit right next to each other.  There are the many better known dialects such as Cockney and Geordie, but there are also many dialects and subdialects across Yorkshire, the Midlands, East Anglia and across the south.  These dialects are far more distinct than those found in the Americas.  Few speak the BBC English that many outsiders would be familiar with.  There are also differences between people from different classes, even those from the same area. The class boundary is a particularly odd one for Americans who, despite all of the recent press lamenting growing socio-economic gaps in the United States, simply have little grasp of the class concept. 

While this is all rather confusing for a foreigner, many English also suffer from a similar problem that many Americans have:  they expect by default that everyone will understand what they are saying.  The empire once was strong, and it is technically called "English".  But even when there are plenty of examples within one's own country that hint that this assumption may be flawed, it does not seem to affect the prevalence of complete communication breakdowns, many that often compete with Monty Python sketches for their absurdity. 

This becomes a huge problem in business, especially within multinational companies.  I have seen time and again language subtleties causing misunderstandings that derail teams, projects, and even big initiatives.  All of this affects morale and trust, let alone the productivity and success of the business.  Assumptions that everyone understands what you mean can be extremely dangerous, even, as with the English, everyone happens to come from the same country.

I have found when trying to convey and idea or concept, that it is always good to test in a non-threateningly way, whether it is by asking questions back of people of their thoughts or what they think they might do in response to the new information, to see whether it was really grasped.  This also works well the other way, which I use often.  That way drift can be caught early, leaving far less room for wild and dangerous surprises later. 

This can go further, and certainly is not restricted to just English speakers.  When looking at the health of a company, it is also useful to look at the means for which people communicate.  We all have stories of misunderstandings developing because someone misinterpreted something said, especially if a low bandwidth medium such as email was used.  Teams and companies also suffer when communication quality is not up to the mark.  I have personally seen very bad situations develop, not only in English and polyglot companies, but also in German and Spanish speaking ones as well.

People who have to interact with one another often work much more effectively together when they know each other well enough and both sides have the ability to further develop communication links. This allows people to better understand each other's context, and correct small misunderstandings at a ground level very quickly. 

Visual indicators, whether they be facial expressions, pictures, or even trends on a graph are also high bandwidth ways to convey complex information.  They work quickly and can be very effective to communicate concepts from diagnostics to thoughts to emotions, bringing truth to the old adage that "a picture is worth a thousand words".

Companies need to pay attention to the quality of communication across their organizations.  Without doing so, they risk creating a tower of incomprehensible babel and failure.
 

Release Batching - When is it a Problem?

I have seen quite a few flame-ups, particularly in the Kanban community, around release batching. It is a subject that I have spent a considerable amount of my career addressing.

Most IT Operations teams abhor and resist change. Change usually brings with it uncertainty and the potential for sleepless nights around a failed service. As it is often impossible to replicate the exact production environment in a test setting, there is a real risk that changes have not been tested adequately. There is also the problem that changes often mean a service outage is required, directly affecting customers.

What makes this worse is the fact that most software engineers as well as IT Operations people are less than sufficiently diligent with properly utilizing configuration management techniques in order to track the changes they make.  It is always far easier to hack in a change directly into a production system than it is to write it, check it in, package it and release it properly while managing all the dependencies.  But such changes cause configuration drift  that makes even the most ideal situation where development and test hardware is identical to production still produce different behaviours.

Release batching is the way that many organizations try to solve this conundrum.  By piling up all of the changes into one big release, the number of change events goes down.  This gives false security to the IT Operations people, who feel that they can heavily man those few events and field all the failures at one time.  It comforts the testers, who feel that they can spend the time to test through all the various changes.  It also allows the developers to be a bit lazier about the way they check in code and manage builds, as there are long periods where they have to code and fix builds.

But all of these supposed benefits not only hide dysfunction, but take value away from the business.  The longer that code is sitting waiting to be shipped, the longer it is sitting not being used to provide value to the business.  While the code is sitting, assumptions that were made that resulted in the code being written are not being tested, and even if they were correct at the time the moment may have been missed and the  market may have moved on.

The idea that fewer big changes means less downtime is also flawed.  Bigger changes, by definition, usually mean that more has changed.  More changes often make for more things to potentially go wrong.  It also means that when something goes wrong, the haystack you are having to dig through to find the problem is far bigger.  The idea that QA is going to be able to catch all defects, especially with large changes, is also flawed.  The measure of defects found is a gauge of how effective your QA team is at finding them against an always unknown metric of the total number of defects.  It is not a particularly good indicator of the number of defects in the code, the quality or maintainability of the code, or even the amount of problems you might encounter when releasing the code.  Lots of changes mean an exponential increase in the number of potential test cases required to find issues.

While pull mechanisms such as Kanban help capture an understanding of flow within the development phase, release batching tends to counteract much of the benefits by hiding dysfunctions under a false security blanket.  Difficulties in configuration management and automated deployment are solvable, and can be tackled incrementally to reduce release cycle time.  By moving progressively towards a system of continuous delivery, ever smaller changes can be understood, tested and released, allowing for very quick feedback and even faster rollback in case of problems.  Changes become far more atomic, risk becomes better understood and easier to manage, and pull can ultimately be achieved across the entire product lifecycle.

The Importance of a Vision and Flexibility

As the world keeps increasing the rate of change while the barrier to entry into the market fades steadily away, many leaders today seem perplexed by the ability for some companies to go from success to success, adapting swiftly to the ever quickening changes in the market while never compromising themselves. When they study these companies, what they often miss is the idea and power of freedom within the ranks to improve and self organize themselves within the scope of a powerful shared vision that they are working towards. This isn't the vision statement drivel that so many companies produce and then ignore, or the command and control orders that get barked down the ranks that don't invoke or allow for thought and creativity. It is an overarching set of high level and far reaching goals that runs deeply throughout the blood and soul of a company. These goals should be very relevant to the industry the company is in. They must be espoused by the executives and be part of the values that they live and are guided by day to day. Finally, though most importantly, the vision needs to be both real and, at the same time, is so bold and far reaching as to be nearly impossible to achieve.

Taichi Ohno's one piece flow is one example of such a vision. Ohno professed the ideal of creating an environment of ultimate flow, where there were no batches and only what was purchased by the customer would be made. This is extremely difficult to do in manufacturing, especially in the vast complexity that exists within automobile manufacturing where Ohno worked. It also goes completely against the commonly held belief, and the beliefs within modern accounting, of optimizing through maximal utilization of factory capacity rather than optimizing on the flow of the pull from a customer. Yet the power was not solely contained within the vision itself. The workers in the trenches and their line managers had to internalize the vision. They did not wait for a list of orders of what exactly to do to come from above so that they could carry on like mindless drones, but instead organized and challenged themselves to use their own experiences and knowledge to continually look for ways to improve their area and the business in the direction of that vision.

The workers on the ground have a critical amount of understanding and control over what is going on. They also are the raw material that can be coalesced to a form that is far mightier and wiser than the traditional corporate structure made of a few brains and many mute and dumb hands. Without their alignment to a vision or a free hand in finding ways of improving towards the goal, progress will be extremely difficult. However, at companies such as Toyota (where Ohno hailed) and Honda, line managers create goals that lead towards the vision, while the employees are given leeway to achieve those goals in the best way they see fit. This allows for what Ikujiro Nonaka calls "reflection-in-action". It creates a world where the collective creativity of the employee base can be harnessed, opening up entirely new possibilities. Such flexibility moves the company away from rigid and less efficient structures and concepts that may have unknowingly become obsolete. It removes the unintentional inhibition of the flow of communication, experimentation and the development of new ideas by allowing for knowledge to flow and recombine in new ways across the organization. This flexibility of thought and structure also has the magic of providing room for new meaning for work and a feelings of ownership to develop for staff that not only helps the company but brings with it pride and a real buzz about work that can be felt on the shop floor.

The strategy of vision with flexibility exists and is the key to success in many other areas, from self organizing nonprofits, to open source projects, to much of the way the US Armed Forces works. It is enshrined in modern manoeuvre warfare, and the concept of decentralized command structures expects that rapid changing situations may out pace communications and create gaps in the knowledge within the chain of command might have. This thus puts the need for lower levels to understand overall intent and adjust themselves on the fly in the battlefield accordingly in order to ensure success. This doctrine is even more pronounced in the Marine Corps, Special Forces and other elite units where flexibility and dynamism from the men in the field is even more important, down to the expectation that they will be "T shaped people" that have many well rounded skills and can adapt immediately to new roles to fill in any gaps that develop as conditions change.

There are several characteristics that each of these types of organizations possess that aids them in their success. They each have a big vision that is professed by all members ("save wildlife", "create the ultimate operating system", "win the war"). They will have somewhat more defined missions and campaigns formed in the upper and middle ranks that lead in the direction of the big vision. Within those missions/campaigns, the people on the ground are able to work in a mesh and organize and change tact to adapt to changes and opportunities as that can be exploited as they develop to lead towards achieving the desired goal. Any lack of flexibility and/or deep understanding of intent and vision quickly gums up the gears. Nonprofits and open source projects fragment as people walk away from them, much like customers will walk away from a business that no longer meets their needs, while such failure in the armed forces is much more lethal. The natural reaction of many large organizations to this is often to become even more rigid and prescriptive, insisting upon tightly defined roles and handoffs that not only deter collaboration but go to further accelerate the feeling on the ground of a lack of ownership and control over their destiny. While work might seem to be progressing to management, the workers themselves become detached, leading to an even greater lack of response to change, greatly harming the organization's long term health and profitability.

The struggle to move away from the more traditional command and control structure that exists in most companies to such a new and different way is daunting and scary for many. The feeling of delivering orders and directly managing people is a bit like a security blanket that somehow feels more certain than simply guiding and coaching. It pushes organizations to trust their employees more and value their knowledge and intellect rather than insisting upon treating like mindless children that need to be told what to do. It also forces thought leadership, and for leaders to step up and provide a far reaching strategic vision rather than spend all their time in the instant feedback of the tactical. Until leaders accept their new role and free and leverage the collective wisdom of their staff, they will doom the organizations that they lead to slow and cumbersome mediocrity, capital destruction, and gradual irrelevance.

Constraints of the Cloud Provider: The Operator's Dilemma

As one who has worked on building and operating on-demand services for many years, there are several areas where I feel most mainstream thinking around cloud have not yet sufficiently developed enough to allow operators to efficiently and effectively provide services for their customers. This frustrates me greatly, as having worked either for or with the often quoted but still poorly understood top Internet service companies out there (like the ones that start with "Y", "A", and "G"), very advanced techniques have been created that when used properly largely overcome these challenges. These approaches are in many ways very different than the traditional industry methods that so many vendors tout, so different that they often turn traditional thinking completely on its head and thus are not hindered by limitations that most of the industry have taken as law. This has left me either chuckling or exasperated as so called experts who have never worked for those sorts of companies jump up and down and insist that the world is flat and that there are dragons at the edge of the horizon.

While I can (and, if my friends and colleagues have their way, probably will) write books on the subject, I will try and first lay out some of the key constraints that I see must be overcome in order to really provide effective and efficient cloud services, whether in the large or in the small.

* flexibility and agility of the stack- this is the one that seems to befuddle people the most, and the one that many companies unnecessarily jam in a hypervisor to coarsely "tune". Service providers usually experience peak and trough traffic demands, with the occasional spike or "super peak" event interspersed. Understanding how customers use the service, including the standard load period, amplitude, how the load manifests itself (CPU, I/O, memory, bandwidth, etc within particular parts of the stack), and (if possible) peak and trough times allows a provider to calibrate not only the size and type of required capacity, but how quickly demand can increase. Providers can build out to fully accommodate for peaks or spikes, but that means that for much of the time there may be underutilized resources. At very small scale this might not be much of an issue, but at large scale, as well as when resources are otherwise very tight, this can be unnecessarily costly.

If a provider wishes to respond to load increases and decreases in a more dynamic way, they need to be able to bring up and down more capacity quickly, as this response time determines whether the end user experiences degraded service or an outage. The biggest challenge here usually comes down to the how finely grained the unit of capacity is. Most people treat the OS "unit", whether it is on physical hardware or a virtual guest, as the one (and sometimes only) building block. This is unnecessarily limiting, as it does not easily allow for scaling that discretely addresses the bottlenecked resource. Mechanisms for building and bringing up and down an OS "unit" are cumbersome outside a virtualized environment that has an image library. Without the right frameworks building a server can be slow and error prone, especially if the physical equipment is not already on hand. Within a virtualized environment, images are not always well maintained, and the instrumentation and service management tools are often either inadequate or improperly used.

Finally, agility needs to be provided in a way that is resource-effective and reliable. It must not require large numbers of staff to respond and maintain, and infrastructure changes need to be known, atomic, reproducible, and revertible as much as possible to maintain consistency and reliability. Agility also needs to include the relocatibility of infrastructure and services for contractual, legal, regulatory or other business factors. I have seen many companies get these wrong, or worse hope that by merely adopting industry practices such as ITIL without developing any deeper understanding or refinement of the underlying services and environment will magically improve agility, reliability and resource-effectiveness. Until this is overcome, the service will never approach its cloud-like potential.

* Data Classification and understanding- I covered this in an earlier post. Understanding the nature and usage of the underlying data allows you to work through how best to approach dynamism within your stack. Without this understanding, data can become stuck, fragmented, inconsistent, or insecure, and negatively affect the reliability of the service.

* Interconnectivity- a truly dynamic cloud infrastructure needs to efficiently and securely communicate both across the components within the infrastructure but also with the end user community. This means that networks must be flexible, dynamically scalable, and have minimal latency (often referred to as "near wire speed"), as well as manage to also create secure "pipes" for moving data. This poses challenges as traditional network topology is often either rigidly dedicated to enhance security or flat and insecure. Also, dynamic storage networks are still in their infancy, as can be seen by the as of yet lack of one definitive winning standard, despite the hype around FCoE and iSCSI.

* Power- this constraint can be defined in any number of ways, whether by power, cooling, space efficiency, or redundancy. As compute power continues to grow and miniaturization improves, achieving effective compute densities in a cost efficient manner is quickly becoming an industry of its own. Innovations such as the Yahoo Computing Coop and Google's shifting datacenters are far out in front. Others battle with lower compute densities, more moving parts, and therefore higher overall costs. Not addressing this limits the availability and cost effectiveness of cloud.

* Security- this constraint is more about perceptions, with some additional sophisticated understanding of the usage of the underlying service, than the problem that many hawkers of "private clouds" will have you believe. This is not to say that many cloud providers have already figured this out. In fact, some are only slightly less sloppy than the standard IT department. Better providers will understand the dynamics of the underlying service, will properly classify and segment where applicable data within the service. They will also properly track and audit access to the data to ensure proper handling.

Where security becomes a more interesting challenge is in the Contractual, Legal and Regulatory (CLR) arena, where requirements may be introduced that are less about security and more around data handling and locale. There is still a great deal of FUD that has built up due to the constant challenges that have arisen in the consumer space. As technology, understanding, and the legal and regulatory landscape evolves, this should improve to allow for customers to enjoy the power of the cloud.

Cloud and the Edge Device: What about the User

(Those who know me know I have had my hands more than a little full the last couple of months. Hopefully, things will settle down soon enough so that I have more time to devote to this.)

While a lot of the discussion in the last year or so has concentrated on the infrastructure and service side of Cloud, arguably the biggest effect upon the whole stack will be driven by what happens on the edge. As more and more people acquire, use and become comfortable with smart phones, tablets, and various roaming laptop form factors, demands for speed, flexibility and portability of applications and services to such mobile devices will skyrocket. No longer will road warriors want to have to be tethered to the office or a wired network to be productive and stay connected to the business and friends. They will also steadily have less and less patience for those "sticky situations" where applications and/or the data they need is "stuck" on a system in the office. While some might see a VDI approach as a way to overcome this, it is a far from perfect hack that twists a traditional paradigm to create a stop gap intermediary layer rather than have the edge device communicate directly with the wanted service itself.

The first place to go in order to best understand the edge is to look at the constraints that exist there. The first is connectivity. In the early days of the Internet when line speeds were measured in Kbps it was impractical to run data hungry applications, and it was not until broadband became more widely available that applications like streaming media became popular. Wifi, LTE and 4G will go a long way to do this with mobile devices however reliability and any latency issues will still need to be addressed. Uneven coverage, clogged masts and backhaul, as well as coverage holes and shadows must be dealt with through further improvements in the technology as well as presentation resilience of the service on the edge device itself.

The second constraint is form factor. While people have different thresholds for what they are willing to carry and use, it is clear that the edge device needs to be lightweight and relatively easy to carry and stow away while still being big and powerful enough to use comfortably. The advent of devices like the iPhone and iPad have just begun to cross the threshold for many. However, insufficient processing power, fast connectivity, and the proprietary nature of iOS have limited the eventual revolution thus far. This has driven the market for specialized applications, but has not yet quite opened the floodgates towards showing what might be possible with cloud services. As it is now clear there is a strong demand for these devices, I expect rapid improvements in technology, as well as the spread of more open operating systems such as Android, should allow operators, consumers and cloud service providers alike to rapidly hone in one this sweet spot and create an even larger market and drive ever more innovative usage patterns.

The third constraint is power. As people are always on the go, and wifi connections are generally power hogs, battery life is critical. As form factor is also important, these batteries must be small and lightweight, yet powerful, long lasting and easily recharged. While I have been impressed with the iPad (though not with any of my other mobile devices), a lot of progress still needs to be made here.

Finally, the last constraint, which I view as perhaps also the biggest opportunity for Cloud, is security. As regulators start to create ever harsher laws for the loss of data, it will become ever more important to tighten the amount of data that is allowed to reside on mobile devices. This may mean either creating a much sharper tiered storage policy towards sensitive and personal data that limits the amount that is actually stored on the edge device. If connectivity, power, and form factor are improved, this will allow for less resident data to exist on the device. Data can also be keyed back to, or have holes punched in it like a puzzle to be filled by, a central cloud service to allow it to be accessed in whole. As the other constraints are slowly pushed back, there will be ever more creative ways that this can be addressed.

The Art of Data Classification and Management

Anyone who has tried to build and manage dynamic infrastructure and services knows that data handling is one of the most complex parts. While it is slowly becoming more and more obvious to people how to generalize and template infrastructure, operating systems, application and service stacks, many still get stuck on how best to deal with the underlying data. Data for them feels unduly "sticky". Due to its size it is often difficult to dynamically move en masse, it changes frequently enough, its nature is often poorly understood, and to people who treat systems as a black box is unpredictable enough ways to make people nervous.

This uniqueness is a very serious problem. It also highlights one of the biggest weaknesses of most companies that try and tread into the cloud space, which is not understanding the nature and uses of the entire ecosystem. Being able to deploy, move around, and even virtualize systems is novel and potentially useful, but without a true understanding and model for the end to end service and how it is used gaps form that limit the usefulness of cloud, or worse run roughshod over the service quality expectations of the user community. This increases the amount of FUD against dynamic services and muddies the water for people to truly realize their real strengths.

Back to data. In my experience, the nature of data in any system can and should be understood, tracked, and put into classifications for better management and usability. One form of classification is the dynamism of the data. Is is static, either not changing at all or very slowly over time. Things like birth dates fit into this category, as your birthday never changes. Is the data dynamic, meaning that it actively changes, and the patterns of change can be captured, tracked, and replayed 90%+ of the time? Most common transactions in a database will fit this pattern, which is why redo logs and heavy tuning of their application and the way they are replayed on backup or replicate databases is an important skill in an HA environment. Is the data interstitial, data that is caught between the customer and the system or service that the customer is interacting with? This is the data that will almost certainly be lost if the underlying service goes away during the interaction, and needs to be minimized to an amount that the customer is willing to accept. Understanding the patterns for which the customer interacts with the system, and the types of states that the system can be left in during an outage help not only set customer expectations but also allow for a much better understanding of ways to more dynamically manage an environment in a way that maximizes service quality, resilience, utilization and cost effectiveness. Mapping the data across these classifications helps with the understanding of the environment in ways that greatly improves the effectiveness of targeted data management techniques.

There are other classifications that may be useful as well. Is the data relational or block? Is it big (such as media) or small (simple text)? Is the data latency tolerant (RSS feeds) or intolerant (financial feeds)? Is it quickly processed/rapid access (transactional system or distributed hash table) or batch (such as data processing in a map reduce or data warehouse cluster)? Is the service distributed globally or centrally located? Is data tolerance absolute or resilient to lazy updates? Does it need to be secure or have other regulatory or legal constraints that need to be taken into account while storing and handling the data? Each of these and others help with understanding the end to end system and allow for a much more targeted battery of approaches and tools that can be used to manage the environment more effectively. Often I build a matrix of sorts that allows for people to map and understand the nature of the various types of data to assist with such targeting and break the mindset that all data is created (and thus treated) equally, or the worst and most common mistake that it must be all treated at the same lowest common denominator.

Building Effective teams

Team building is a lot more difficult than most make it out to be. It is not something that one can easily learn in a book, or in a team building exercise for that matter. It is something that requires collaboration, understanding, time, and patience for it to occur. It tends to come together in the more stressful times, and much like a family involves conflict, misunderstanding, shared successes and failures, and a common thread that pulls everyone together. It is also something that must live and breathe like an organism, for while there might be a nominated leader it takes constant feedback, leadership and effort from everyone to succeed.

I have been part of attempts to build many teams throughout my career. In fact, I really enjoy building them, bringing out the best in people, and building a greater organism that brings with it friendships and learning. Some teams have come together and through thick and thin achieved amazing feats, while others behaved worse than a random list of names on a piece of paper. Some acted like elite special forces units, some like an eccentric family, while others like two year olds on the first day of nursery school or worse strangers on the Tube. While building a team isn't necessarily something that can be done in a prescriptive way, it in time be a lot like cooking. In fact, like Iron Chef, it is almost like being given various, sometimes almost random, ingredients to combine in various ways to attempt to create a delicious feast.

The best teams were rarely made up of the best from a talent and skills perspective, but rather those who were willing to put in the heart and effort, against the odds, to help the group. They came together naturally rather than being artificially put together based on some formula. There were always missing skills, things to learn, and stuff that looked set for failure that sometimes did. Roles sometimes seemed fuzzy, and would sometimes change frequently to keep the team balanced and on track, as well as sometimes providing the added benefit of ensuring that experiences (and pain) were shared. Nicknames often were given to people, places, things and ideas (I have had many bestowed onto me). Bread was broken, drinks shared, ideas constantly flowed, and it was quite normal for work and personal life to intermingle at times. I have had many key strategies and architectures drawn on a series of napkins and the back of random junk mail at people's homes and at random family style restaurants. Disagreements would abound. In fact, impassioned arguments always seem to be one of the biggest signs of success. Working through the heat of passion of people who really cared and who were allowed to confront each other in the desire to find the best way through. Ideas, discussion, and feedback must be constant, like blood flowing through the body. If feedback doesn't flow, or worse puddles in a silo, the team dies.

Teams have been of a wide variety of sizes. I have had organizations of many hundreds, and sometimes consisted of several teams, but I would not call any of the organizations themselves a "team". Organizations can pull together through alignment to a common vision, series of working groups and aligned teams, and occasionally "nested teams" where there might be some folks who have a natural knack for being able to be members of or straddle more than one team that has related goals and can cross pollinate both to create something that is far more than the sum of the parts. From experience the team itself is usually between 6 and 12 people, preferably 8 (+/-2), which seems to follow a lot of the common anthropological data on effective human groups out there. A team with any more than 12 never seems to gel, as it allows for people to overly specialize, or hide/be overshadowed by others.

Above all, the most important item is having a common purpose or goal that everyone shares and believes in. The shared thread, whether it be a project, a product, or a transformational mission, must be shared and believed in by everyone. That doesn't mean that people can't have different interpretations and opinions, even strong and contradicting ones. They also do not necessarily have to agree on the particular path. However, the belief in the high level end goal needs to be the same, and must be nearly a mantra. If it is not, like the two year olds the team will never gel.

Service Engineering and Service Management: The Forgotten Elements of the Virtuous Circle of Success

The understanding of the importance of the customer's role in ensuring fit for purpose products has improved significantly over the past several years, as has to some extent the interaction between developers and the customer community. However, in the many years that I have been building highly scalable services, one of the biggest challenges I have faced is developing an appreciation and understanding of the roles that Service Engineering and Service Management play in developing and ensuring an effective service. Ensuring that these two groups are ever present in the conversation, either as separate entities, or as roles within more traditional Engineering and Operations organisations, has rarely come easily. This oversight is one of the more costly sins that limits the effectiveness of organisations to truly exploit and achieve what is possible with cloud services.

To help appreciate the functions these two roles play in the ongoing collaborative discussion that develops and improves services, let me describe what each in my experience has looked like when implemented effectively.

Service Engineering

Service Engineering is perhaps the most difficult to describe, as the functions of the role span a variety of traditional roles, including Release Engineering, as well as IT Operations. Working in conjunction with the development community, this group develops the frameworks that transform bare metal and bits of byte code to reproducible on demand services that can flex within the constraints of the business. They are, in essence, the providers of the foundation of the service. They ensure that there is effective physical inventory, and that configuration information is authoritatively captured in a way that allows for reproduction as well as traversal for better understanding of dependencies. They design key elements of the datacenter, including networks, storage, and compute, and look for standardization and modularization where possible. They manage automated OS, hypervisor and application installation and configuration. They ensure effective application packaging, and consistent and repeatable builds and installations of the entire stack. They usually understand breadth and depth of the stack, and try and provide as much of an ant farm approach to providing visualization. They have a very keen eye towards service performance and tuning, and can often be found better understanding kernels and database design. They are sometimes called "Systems Engineers", "Reliability Engineers", "Release Engineers", "Operations Engineers", and "Infrastructure Engineers".

Service Management

Service Management provides the management wrap around a service. They develop and tune monitoring systems, service desks, dashboards, and other items that provide a better understanding of the performance, health, and help capture and understand patterns that may be of use for the rest of the organisation, as well as the customer. They help developers and service engineers develop hooks and harnesses that they can interrogate to better understand, collect, merge, interpret and roll up key aspects of the service. They need to understand dependency trees, understand what is most meaningful to customers, engineering, and the business, and effectively represent it as this information is critical to effective service exploitation, risk management, and contractual reporting. They understand and tune IT Operations support processes and change management, and must work especially closely with Service Engineering to capture and help coordinate any automated changes.

Engagement in the Lifecycle

Both of these groups provide the key elements for which a service is provided and managed. However, they mostly produce what most would consider non-functionals, which are the items that are not very whiz-bang for the business, and are simply assumed to be there by the customer. They are usually poorly understood, rarely invested in, and ignored like plumbing until it breaks. They are typically blindly squeezed as a cost line, and are sometimes viewed as a form of janitorial function that can do magic voodoo with computers. Business people often fear putting them in front of customers, afraid that they will scare them with their quirkiness, or that they might reveal something about the infrastructure that might terrify them. Good engineers understand their importance, but often do not have enough cycles to work with them while they work on more feature development. QA often misses that effective Service Management captures much of the same sorts of data, albeit usually unfortunately only in a production sense, that they need to assure the level of product quality that is expected. These Service teams themselves often under appreciate their own role if not shown the light.

By bringing these teams to the table, there is a much more effective grasp of the entire service lifecycle. Service Engineering can help understand the demands for flex and agility and provide both the understanding, as well as grounds and execution needed to provide it. Service Management can help with understanding the services themselves, whether to better understand user experience, user exploitation, code and service quality, as well as performance and capacity, and present these back to each of the key audiences in ways that are most meaningful to them. Working together with the rest of the players within the lifecycle, they can rapidly and continuously improve. They can reduce waste, and delight customers through collaboration and preemptive service management.

Inventory of the Cloud: It’s Just Vapor Without It

Imagine you run a logistics business, complete with warehouses, lorries, ships and cargo aircraft. However, you quickly notice that your customers are completely up in arms. They are saying that it seems to take absolutely forever for deliveries, and even when they eventually are made they often are delivered to the wrong place or are the wrong items. Your staff say they are moving everything as quickly as they can, but there just are not enough hands or vehicles to deal with the demand. They point to some of the warehouses where there are packages stacked high in the parking lot. Just at this point, a critical order from your most important client hits. You realize that not only do you not know where the inventory is, but aren’t even sure where the vehicles to transport it are, or how much capacity each of those vehicles can hold.

There can be no argument that this is an extremely ineffective way to run a logistics business. Logistics requires knowing where everything is at any given time, whether it is product, capacity or capability. A mom-and-pop operation might be able to manage their operation in their head or with intuition, with perhaps only a couple sets of hands that handle a package from beginning to end. As soon as the number of moving parts increases beyond what one can easily see and count, and the number of actors involved increases beyond a small handful, tracking becomes difficult and the business can no longer be managed so informally.

I would argue that a Cloud service provider has exactly the same challenges. A traditional IT house can probably manage a small pile of applications on a few dozen servers with a small handful of people who all know each other. Tracking and managing of rather simple services with a smattering of dependencies can usually be brute forced to resolution by restarting and tweaking various bits. However, the scale and dynamism of Cloud causes the number of dependencies to not only explode, but also becomes impossible for anyone to track the entire constantly changing dependency map in their head.

Much like a logistics company, what is required are means for managing and tracking all forms of inventory as they flow and change throughout the service lifecycle. The first form of inventory are facility capabilities. Logistics requires always knowing the various qualities of warehouses and distribution hubs in logistics. Logistics companies have learned, much like some more advanced Cloud companies, that warehouses and hubs need to flex to the needs of business dynamics. While there will always be some core facilities, large contracts or changes in regulations require the ability to flex capabilities up and down, either through building temporary facilities or stationing container yards in strategic locations. Cloud requires knowing the location, capabilities, as well as real time capacities and environmentals of datacenters. Flexing these sorts of facilities has become increasingly important with the shifting nature of the global economy and regulatory landscape around data protection and taxation.

The second form of inventory are those capabilities of the workhorses of each of the respective industries. In logistics this would be the lorries, ships and aircraft. The capabilities, configurations and locations of these assets must be constantly tracked to allow the business to know how best to service their customers, both when the capabilities are available as well as when they are carrying customer product. Missing a lorry with refrigeration capabilities in a particular location could mean the difference between whether or not a product is delivered fresh. If a ship rather than an aircraft is available, delivery speed is compromised in exchange for bulk. In Cloud, this second form of inventory would be the servers, virtual machines, networks, and storage. Without understanding and constantly tracking at this level could hinder an organisation from maximizing its capabilities, or worse lead to service failure.

The third form of inventory are the actual packages themselves. Whether this is a physical package as in logistics, or a software package and its configuration in the Cloud, these are both in fact little more than mechanisms that are dynamically configured to handle the actual items that the customer cares about. The contents of a single package can be meaningful in itself, or only useful when bundled with other packages of relevant components. They come in all sorts of configurations, though standards exist in both industries (albeit much more nascent in IT) and are preferred. The quality and knowledge of those configurations, as well as the attributes attached to the package, whether in a shipping label or a software configuration, will heavily determine the level of success or failure of the job from the customer’s perspective. The customer can manage the quality of service through paying for higher or lower service levels, and can prioritize more important things over the less important.

All this might sound like a bit of a stretched metaphor, but there is one other detail that these two industries share. Both these industries look to heavily track and tune all of these forms of inventory, and their optimisation throughout the system is absolutely key for success. However, while the customer might be curious about the details of the inventory, and may even have a hand in creating and managing the package, none of these things is what is perceived as the actual thing of value to the end customer. In fact, the customer only cares that the service was delivered on time, at an acceptable price point, with the quality and security that they would expect. Both industries must never lose sight of this, but all the same they must know that inventory configuration management are their means for managing the service.

Cloud Doesn’t Necessarily Mean a Hypervisor is Involved

I spend a lot of time speaking with customers, vendors, analysts, and "cloud providers" about IT Cloud services. It never ceases to amaze me how many equate Cloud with a guest Operating System running under a VMWare or Xen hypervisor. This incredibly narrow view not only entirely misses the point of Cloud, but focuses on a particular instantiation that has an incredibly low barrier to entry into the market.

Let me provide an example from another field that most people would understand: transportation. Imagine you were to describe transportation. You might talk about moving people and/or things, individually or together, long or short distances, fast or slow, by air, ground and/or water. You might cover some of the various methods, like cars versus trains, ships versus barges, helicopters versus fixed wing aircraft; or the ways that they are powered, like petrol versus coal versus diesel versus wind or some such. All are valid ways to describe such a topic. One might argue that focusing in on any one segment could hinder your understanding of the topic.

Say that people started to equate transportation with a petrol powered bus, not only ignoring but eliminating all the other options out there. Immediately there would be problems. Some people would complain that a bus doesn’t help them easily move things that are not people, and that transportation must be a bad thing because sometimes buses get overcrowded, too slow, or don’t go where they want to go. Companies start labelling themselves “transportation leaders”, because they too can easily go out and get a bus and a driver, and add their own pinstriping or unique seats to their offering. Potential customers start to roll their eyes and say “transportation was so yesterday” because they too dabbled with buying their own bus but couldn’t see what all the excitement was about when they packed their employees in and out of it.

This might sound silly, and so does equating Cloud with a hypervisor. Cloud is the ability to consume a service, whether it is a simple infrastructure service like an OS on a hypervisor, or a much more complex one like CRM or billing, that a person or company can consume on demand (i.e.- as soon as one wants it, like electricity or telephony) as much or as little as they want, when they want it, and know that it will work predictably within certain service level thresholds (electricity will be there, with the right wattage; bandwidth will be there with the right agreed throughput with acceptable interference and uptime). The power really comes from the speed, cost, and flexibility that those services can be provided. It needs to be as easy to build out one’s back office by simply going to a web page with a credit card and selecting where your customer information is (say, in Salesforce), tying it to logistics information (provided, say, by UPS) and accounts receivable (provided, say, by HSBC), into billing, inventory, and integration platforms that can flex as demand shrinks or grows. It should also be easy to immediately select and provision IT and telephony items for a new office, as well as creating and rapidly resizing a new web presence in a far flung market to support the waxing and waning of new marketing campaigns.

A guest operating system under a hypervisor can provide some of these capabilities, much like a petrol powered bus can provide some transportation capabilities. Cloud is far more than that.