Category: The Business of IT

The Business of IT: Insights into IT for fun and profit.

Do you have what it takes to build and run your own private cloud?

Post author By Shlomo Swidler
Post date September 24, 2012
1 Comment on Do you have what it takes to build and run your own private cloud?

Building and operating a private cloud ourselves is simple, right? Give our experienced IT folks a budget for hardware and software, a clear mandate, and deadlines, and we’re likely to succeed. That’s what we’ve always done, and it’s worked out tolerably well. Private cloud isn’t so different from running our own virtual machine environment, and we do that already, so why wouldn’t we succeed? I hear this sentiment expressed often so it seems to be a widely held belief. But it’s wrong precisely 97.73 percent of the time – I measured. Unfortunately, too many organizations act on this mistaken belief and experience unnecessary hurt as a result.

My good friend Keith Hudgins made this point cogently in his presentation at the CloudConnect conference in Chicago. Keith is one of the few people who really knows what it takes to build and run a cloud: he was part of the core team with me building KT’s public cloud service in South Korea, and he is currently Senior Cloud Engineer at enStratus where he helps enterprises get their private clouds to work properly. Keith’s presentation was sobering for the audience members, several of whom said they plan to reevaluate their private cloud initiatives as a result.

If you want to succeed at your own private cloud you need to consider these four critical aspects: your users, your competition, your skills, and your technology. Know these four and you have a fighting chance to make it. If not, get help – or prepare for disappointment.

Know your users

Different users need different applications, and your cloud must be designed to support the required applications. Private clouds might have three different types of users:

Regular desktop users, the kind of user most likely found in your Finance, HR, Sales, and Marketing organizations, will need your cloud to support the applications your IT department currently supports already: CRM, accounting, ERP, and business applications your IT department is already familiar with.
Software R&D staff will need your cloud to support the development environment, tools, and deployment processes they’re already using. This group will also likely need training to properly architect and operate reliable applications in a distributed environment.
IT staff will need your cloud to support core capabilities such as backup, directory management, and file sharing.

Ask your users what applications they are using and what they need the cloud to support.

Know your competition

Odds are your users already use public cloud services, and – like it or not – your own private cloud will be competing against those public alternatives. How well do public cloud services meet your users’ needs?

How reliable is their service? How does this compare to your own historical reliability?
How easy are they to use? Do public cloud service customers need multiple levels of corporate approval to acquire resources, or is the ordering and fulfillment process seamless and extremely short – a few minutes at most from order to delivery? Can you deliver the same or better usability?
How good is their support? Are there multiple sources for expertise and communities where users can share solutions and experience?
How rich is their ecosystem? How easy is it to employ a vast variety of tools and seamlessly integrated value-added services?

Determining how well your users’ needs are met by existing public cloud alternatives will give you a good idea of what you need to provide in order to achieve successful adoption of your private cloud.

Know your skills

The skills required to build and operate a cloud are not taught in classes, they’re learned by experience. These include:

System administration. Okay, this one is taught in classes, but the issues you’ll experience in a cloud environment are much more complicated and at a larger scale than you will normally encounter elsewhere. Keith suggested that OpenStack and Eucalyptus will be a challenge for your team if they lack linux administration skills.
Storage management skills are critical because storage is the most complicated technical aspect of a cloud. Keith emphasized the importance of NAS and iSCSI setup and management experience.
Networking is a key element of the cloud and networking expertise must be a part of your core cloud engineering team.
Automation will dictate how quickly you can recover from problems, so you must be experienced in its use and integrating automation tools into your workflow. Identical inputs (that is, identical hardware revisions) must always yield identical outputs, and that is only possible at a large scale with automation. Keith pointed out that automation takes time to produce. Make sure your team is proficient with the automation tools that work best with your technology choices.

Get these skills if you don’t have them. They will influence your choice of hardware and software.

Know your technology

Cloud is powered by technology, so you’ll need expertise in at least the following four technical areas to build and run it yourself.

Cloud Management Software is the layer that provisions cloud guests and sits between the API and the hypervisor. If you can’t explain the differences between the four major cloud management software options – CloudStack, OpenStack, Eucalyptus, and OpenNebula, then you do not have the expertise to choose the right one for your needs.
Storage, Keith pointed out, is by far the most complicated technical aspect to get right in a cloud. Local guest storage is the simplest to build and operate, but limits the range of applications that can be easily supported on the cloud. Attached storage increases flexibility at the cost of complexity. And object storage requires lots and lots of disks. Your options will be influenced by your choice of cloud management software, and any change to the default configurations will require serious development and testing to get it right.
Hardware and the way you manage it is the most important choice you can make. Of all the components in a cloud the hardware is what is going to break, so the ease with which you can replace hardware will dictate the maintenance headache. Keith provided some hard-won tips: make sure your hardware vendor can supply identical hardware down to the BIOS revision, create (automated) procedures to verify or reject hardware as it is delivered, and diligently avoid hardware inconsistencies since they greatly increase the complexity of the endeavor.

Your choices in the above three technology categories should be guided by your needs, but remember: you can only choose wisely if you have appropriate expertise in these technologies.

Do you have what it takes?

The above four aspects are critical to successfully building and operating your own private cloud. There are other success factors – know your strategy, know your business model, and use effective project management – that are part of any successful technological change. But the above four are critical in any private cloud initiative. So, how do you rate on these aspects?

Odds are, you don’t have the expertise required to do it yourself.

Tags cloud computing, cloudconnect, operations, private cloud

The Business of IT

Where is the value?

Back in the early days of computers, or so the legend goes, when an entire room housed less computing power than in today’s iPhone, a large government agency had a serious problem: their computer system stopped working. Though it was only three weeks since the system had been certified, the startup sequence refused to complete, leaving the agency lacking critical operational capabilities. Work on the project ground to a halt while every engineer on staff checked and rechecked wiring, tubes, and relays to find the issue. But two weeks of troubleshooting amounted to nothing, and the Director of the agency was beside himself with frustration. He decided to hire the worldwide expert on such computer systems, a retired professor who was known for his sense of humor.

The professor arrived on site in a white lab coat, was briefed by the Director, and immediately asked to be given access to the computer room. Once there, he proceeded to walk around the room from cabinet to cabinet. The Director and his staff watched with increasing curiosity as the professor paused before each cabinet for a moment, scratched his beard, muttered under his breath, and moved on to the next cabinet. Finally, after forty five long minutes of this, the professor stood up more erect, smiled at the Director and his staff, withdrew a piece of chalk from his coat pocket, walked over to one machine cabinet and marked a large “X” on the side of the cabinet. “Your problem is in here,” he said confidently. And, sure enough, as the technicians opened up the marked cabinet, they discovered a subtle wiring issue that had been missed by all previous inspections. Gratefully, they fixed the problem and were able to resume operation. “Please, send me your bill – whatever it is, I’ll see that it is paid promptly,” said the Director.

The professor sent a bill to the agency, a one-line invoice for “troubleshooting: $1000”. Unfortunately, as government policy dictated, the Director needed a detailed itemized invoice, and he was forced to delay payment and request the proper details from the professor. The professor’s corrected invoice arrived, and it read as follows:

One piece of chalk, with which to mark the problem: $0.01
Knowing where to place the mark: $999.99

The real value to your customers is in knowing how to fulfill their needs. All the rest is a commodity.

Tags consulting, value

The Business of IT

Wanted: Change. Generous Reward.

Post author By Shlomo Swidler
Post date July 25, 2012
No Comments on Wanted: Change. Generous Reward.

Simon Wardley recently satirized the typical response of corporate IT departments to technology change as follows: Ignore, ignore, ignore, “no”, “no”, “I said ‘no,’ dammit”, “Oh no”, “Oh, f**k”. It reminds me of the classic Toys-R-Us TV commercial from the 1980s featuring children singing about not wanting to grow up. Resistance to change is not unique to children or to IT departments – it is a feature of every organization. How can you help your organization avoid being stuck, and instead drive change before it’s unnecessarily painful to “grow up”? The key is urgency. Growing up is a good metaphor for organizational change: both are normal, both feature resistance, and in both the stakes increase over time. Immature people, like immature organizations, do not reliably achieve their goals. And the longer that inertia dominates, the further behind they remain. Failure to adapt – getting stuck – can be fatal, as it was for the Eastman Kodak Company. In personal as in organizational growth the pressure to change – the urgency – is fostered by discomfort. To increase urgency you need to cause people to feel discomfort with the current state of affairs. John P. Kotter’s seminal work Leading Change offers several kinds of tactics to increase urgency:

Show that the present isn’t working: Allow a crisis to happen, publicize poor results, force encounters with unhappy customers, publicize lost opportunities.
Change the metrics: Create performance targets that are high enough and/or broad enough they can’t be reached with business-as-usual.

These tactics to increase urgency all work by fostering discomfort with the present. A client found himself spending inordinate lengths of time evaluating opportunities and procrastinating a decision on which ones to pursue. When I showed him how his lengthy decision process was limiting the number and quality of opportunities that presented themselves, he realized that he could grow his business significantly by streamlining this process. He saw the urgency of addressing the issue, we worked together to fix it, and his business has grown threefold since.

Creating a sense of urgency is the first step in a successful change program. Kotter describes further steps to a successful change effort, but urgency underlies them all.

In short:

Ouch! Now, change.

Tags consulting, delivery, strategy

Cloud Developer Tips The Business of IT

Developing Means Delivering

Post author By Shlomo Swidler
Post date July 17, 2012
No Comments on Developing Means Delivering

An informal survey of my application developer friends revealed four main types of motivations driving developers. These four types of motivations are represented in this diagram:

Individual developers can be motivated more or less altruistically. Individual developers can also be focused on the external manifestations of success – such as appreciative customers – or on the internal manifestations – such as more power or money. The diagram above is not a judgement of “better” or “worse” motivations – it is simply meant to capture two personality factors and their expression among individual developers. Also note that developers may have different motivations at different times, or even simultaneously in combination.

Just as individual developers can have varying motivations, organizations can also be more or less altruistic, and focused more internally or externally. Internally focused organizations spend an undue proportion of their energy and resources doing work (or inventing work to do) that will not be visible to the outside world, while externally focused organizations measure their results based on their effect on the outside world – market share, profit, and customer satisfaction.

Where do you rate your organization on the above diagram? Most business leaders want organizations firmly motivated by providing value to the customer, and software businesses are no different. Developing software is all about delivering value. Your software development efforts can only provide value if they are successfully delivered to the customer – and in today’s “as-a-serivce” world, that value is constantly provided via the internet. This means that you should spend significant effort ensuring your customer can actually reach your service to receive the value. It means automating your deliveries. It means measuring and improving your delivery speed and success rates. It means involving your customer early on so that you know the value they seek and so you can provide it. It means making sure all your teams work together to get this to happen.

Because ultimately, it means a developer’s job is not finished until the customer has derived value.

Tags delivery, developer

Cloud Developer Tips The Business of IT

Software Delivery Operations

Post author By Shlomo Swidler
Post date July 16, 2012
3 Comments on Software Delivery Operations

Like companies producing any kind of offering, software companies require three elements in order to successfully deliver: knowing what to build, knowing how to build it, and knowing how to deliver it to the customer. When each of these three functions – research, engineering, and delivery – does its job independently, you get slow progress and uninspired, sub-par products. But when all three functions work together in a customer-centric fashion, you get excellence – in implementation, innovation – in concept, and world-class results – by delivering those two to the customer.

With the explosion of internet-based services in the past decade delivery has by necessity become an ongoing activity. And so in recent years much attention has been devoted to integrating development with technical operations – DevOps. DevOps integrates into a single team the skills of how to build the service and the skills of how to deliver it. But, as pointed out earlier, DevOps teams often lack the most critical element: the customer’s involvement. DevOps teams can build and deliver really fast, but don’t know what to build.

Integrating development with the customer-facing functions (marketing, sales, etc.) without technical operations results in an organization that knows what to build and how to build it, but doesn’t know how to deliver it to the customer. This organization is full of ideas – even innovative ideas – and implements them, but they don’t see the light of day. I call this a “feasibility practice” – it can show you what is feasible but it can’t deliver it to customers.

Teams that know what to build and how to deliver it to the customer, but not how to build it, also do not provide value to the customer. Such teams are close to the customer both on the inbound (understanding the customer’s needs) and the outbound (explaining the company’s offering) directions. Marketing sits squarely in this space: it knows what to build and how to deliver but can’t transform that knowledge into value for the customer.

As an executive leading a software delivery effort, make sure your organization occupies the very center so it can understand, build, and deliver the right value to the customer. The customer is here in the center as well: he participates in validating the ideas, critiquing the implementation, and accepting the delivery. It is only here that your organization can achieve excellence, innovation, and world-class results.

Tags delivery, devops, marketing, operations

Cloud Developer Tips The Business of IT

The missing layer

Traditional descriptions of cloud computing and the various cloud operating models – IaaS, PaaS, SaaS – focus on the locus of responsibility for various layers of the system: facilities, network, storage, servers, etc. But these descriptions typically omit a critical element. Can you spot it in the diagram below?

The missing layer is the only layer that really matters – the customer. Ensuring that your application can actually be consumed – that delivery can be successful – is a critical part of providing your value. Your application’s facilities, network, and storage may be running properly, but will your customers actually benefit? Without a properly staffed, trained, equipped, and managed operations team, your service won’t last long enough for customers to care. If your customer is important, then so is your operations team.

Tags delivery, operations

The Business of IT

Being Good and Being Known for it

Post author By Shlomo Swidler
Post date July 3, 2012
No Comments on Being Good and Being Known for it

The owner of a home-based baking business once described his marketing strategy to me as “my cookies speak for themselves.” True, they were delicious cookies. But he completely neglected marketing so his customer base never grew beyond friends and family, and his business failed as a result.

At a recent client meeting I was reminded of that baker. The CEO of a fledgeling tech business said to me, “our differentiating factor will be our superior service quality.”

“Wonderful!” I said. “So I’d expect to see significant investment in engineering and quality control. Is that the case?”

“Yes! Here is our R&D and quality program…,” and he showed me.

“That looks reasonable,” I said, after glancing at it briefly. “Tell me about your marketing.”

“Oh, we hardly need any!” the CEO replied. “Our customers will love our service quality so we don’t need significant marketing.”

I was immediately concerned. “Let me show you something,” I said to him. And I drew the following:

Being good and being known for it are both essential. New businesses begin in the lower left quadrant. At first there is no product so it’s not good, and nobody knows about the company. Here customers are neutral about your offering: if they knew more they’d know it wasn’t good – and if it was good they still wouldn’t know it. In the upper left quadrant you’re no good and customers know it, so they leave. In the lower right you’re good but nobody knows it, so you lose opportunities to do business. The goal is to be in the upper right quadrant, where you’re good and customers know it, so you grow.

A business will traverse the playing field as its quality and reputation change over time. Sometimes quality will suffer or improve, sometimes reputation will have ups or downs. The key factor in achieving success is the ability to nimbly correct course, heading always toward being good and people knowing it. Identify improvements and deliver them to your customers quickly – and make them aware of the improvements. You’ll need agile product development, minimizing the time between concept and delivery. You’ll need to measure your customers’ perception of your quality. You’ll need to empower every employee to satisfy the customer as quickly and completely as possible at every level. The net result of enabling quick course correction will be that you get good and you get known for it – and you grow.

Thankfully, this CEO was convinced by my explanations. He agreed that “being known for being good” is as important as “being good” and I helped him craft his marketing, development, and customer support efforts accordingly. The cookies will speak, and he will make sure people hear them.

Tags consulting

The Business of IT

How I helped by refusing work

Post author By Shlomo Swidler
Post date June 7, 2012
No Comments on How I helped by refusing work

A very good repeat client introduced me to his own customer, CEO of a fast-growing company, with the words “you should talk to Shlomo – he does wonders.” When I get an enthusiastic referral like that – which happens often, as most of my business is via referrals – I move fast to see how I can help.

The CEO and I met and began to explore important areas of his business that I typically help with: usage of cloud resources, leveraging the data collected, streamlining processes and team dynamics. The discussion was progressing quickly – in fact, too easily, too rapidly – toward defining a potential project. I sensed something was wrong. He couldn’t describe why he wanted these things to get done; all he could say was, “this is the next issue we need to tackle.”

“Tell me what your rate is for doing these things and we’ll get moving immediately,” he finally said. In the past I would have jumped at the offer – what could be easier than business that practically lands itself in my lap after only thirty minutes of discussion? But, thankfully, I’m constantly learning from the past. My motto is “make new mistakes,” and I had learned the perils of undertaking work without comprehending the motivation behind it – without understanding the “why.”

“Joe,” I said, “I’m not going to work with you on any of that.” He stared at me in wide-eyed shock for a moment. Had I not known he was an elite long-distance runner, in top cardiovascular shape, I would have feared the worst. I continued: “You’re too close to the business to see what’s really going on and what areas need the most urgent attention. That’s why it’s hard for you to explain why these items are important. With your permission, I’ll lead you through a brief series of questions to help us both ascertain the areas of true priority for your organization. Then we’ll be able to jointly determine the best way to work together to achieve those priorities.”

And so we did. We began with these three questions:

How much of your own time is spent resolving day-to-day issues versus establishing and communicating direction and priorities?
If your business volume were to triple tomorrow, what about your organization would break?
If you were to ask your engineers, your support staff, your accounting staff, etc., what their biggest headache was, what would they answer, and would you be surprised by their answers – and why?

These questions helped Joe step out of his day-to-day role and think about the business from the outside, as a doctor would observe a patient. From this vantage point we observed the symptoms that the patient exhibited – the areas in which the organization was not healthy. There were many. We both agreed on the diagnosis: the underlying problem was the organization’s inability to take on new customers because its accounting functions could not handle the additional work. Then we discussed the course of treatment. Joe suggested introducing an automated billing system.

An automated billing system would certainly have alleviated the problems, but I sensed that there was still something more fundamental to explore. I asked Joe, “how can your billing system be directly beneficial to your customers? Why should they care?” Joe thought for a moment, and then he said excitedly, “you’re so right! We need to integrate billing into the customer interface!” Joe’s product is all about simplifying the use of multiple aggregated services, and therefore simplified billing is part of his product’s key value proposition. He realized that he was missing a core element of his product, one that would also enable the company to grow profitably.

We had come a long way from “help me implement these next few things we need done,” and were now discussing how to help his company achieve its strategic objective: to grow profitably. The tasks we had been discussing originally would not have contributed to this goal significantly, and Joe acknowledged that those immediate issues of reducing cloud usage costs and leveraging collected data were illusorily urgent. And he thanked me for pushing back on his request to tackle those issues.

Joe and I are currently discussing various options for helping him build his critical billing capability. He would not have realized the real priority, the true “why” he needs to address, if I had said “yes” to his initial proposals. And my involvement in helping him achieve strategic objectives is much more valuable, and much easier to demonstrate, than extensive work on non-strategic tasks. I prefer the former, and so does Joe, and all my other clients as well.

Tags consulting, strategy

Cloud Developer Tips The Business of IT

Roundup: CloudConnect 2011 Platforms and Ecosystems BOF

Post author By Shlomo Swidler
Post date March 14, 2011
No Comments on Roundup: CloudConnect 2011 Platforms and Ecosystems BOF

The need for cloud provider price transparency. What is a workload and how to move it. “Open”ness and what it means for a cloud service. Various libraries, APIs, and SLAs. These are some of the engaging discussions that developed at the Platforms and Ecosystems “Birds of a Feather”/”Unconference”, held on Tuesday evening March 8th during the CloudConnect 2011 conference. What about the BOF worked? What didn’t? What should be done differently in the future? Below are some observations gathered from early feedback; please leave your comments, too.

Roundup

In true unconference form, the discussions reflected what was on the mind of the audience. Some were more focused than others, and some were more contentious than others. Each turn of the wheel brought a new combination of experts, topics, themes, and participants.

Provider transparency was a hot subject, both for IaaS services and for PaaS services. When you consume a utility, such as water, you have a means to independently verify your usage: you can look at the water meter. Or, if you don’t trust the supplier’s meter, you can install your own meter on your main intake line. But with cloud services there is no way to measure many kinds of usage that you pay for – you must trust the provider to bill you correctly. How many Machine Hours did it take to process my SimpleDB query, or CPU Usage for my Google App Engine request? Is that internal IP address I’m communicating with in my own availability zone (and therefore free to communicate with) or in a different zone (and therefore costs money)? Today, the user’s only option is to trust the provider. Furthermore, it would be useful if we had tools to help estimate the cost of a particular workload. We look forward to more transparency in the future.

As they rotated through the topics, two of the themes generated similar discussions: Workload Portability and Avoiding Vendor Lock-in. The themes are closely related, so this is not surprising. Lesson learned: next time use themes that are more orthogonal, to explore the ecosystem more thoroughly.

In total nine planned discussions took place over the 90 minutes. A few interesting breakaway conversations spun off as well, as people opted to explore other aspects separately from the main discussions. I think that’s great: it means we got people thinking and engaged, which was the goal.

Some points for improvement: The room was definitely too small and the acoustics lacking. We had a great turnout – over 130 people, despite competing with the OpenStack party – but the undersized room was very noisy and some of the conversations were difficult to follow. Next time: a bigger room. And more pizza: the pizza ran out during the first round of discussions.

Participants who joined after the BOF had kicked off told me they were confused about the format. It is not easy to join in the middle of this kind of format and know what’s going on. In fact, I spent most of the time orienting newcomers as they arrived. Lesson learned: next time show a slide explaining the format, and have it displayed prominently throughout the entire event for easy reference.

Overall the BOF was very successful: lots of smart people having interesting discussions in every corner of the room. Would you participate in another event of this type? Please leave a comment with your feedback.

Thanks

Many thanks to the moderators who conducted each discussion, and the experts who contributed their experience and ideas. These people are: Dan Koffler, Ian Rae, Steve Wylie, David Bernstein, Adrian Cole, Ryan Dunn, Bernard Golden, Alex Heneveld, Sam Johnston, David Kavanagh, Ben Kepes, Tony Lucas, David Pallman, Jason Read, Steve Riley, Andrew Shafer, Jeroen Tjepkema, and James Urquhart. Thanks also to Alistair Croll not only for chairing a great CloudConnect conference overall, but also for inspiring the format of this BOF.

And thanks to all the participants – we couldn’t have done it without you.

Tags cloudconnect