Scaling In

Interfacing with the cloud

2011-09-25T11:28:00.000-05:00

I was having a breakfast meeting with a technology start-up CEO last week, and the discussion turned to user experience and interfaces. He asked me, "What is the best interface you've worked with?" I started thinking through this, focused on my computer, and provided a couple of examples. He nodded, then said, "I'm surprised you didn't mention this", gesturing at our iPhones. After a second or two, I realized the reason I hadn't thought of the iPhone is that I never think of my iPhone - I just use it.

More than Palm's old tenet of "if it takes too many taps, we need to rethink it", the gold standard for interface design should be that the end-user does not need to consider it at all. Rather, the end-user should be so comfortable with using the interface that the focus can then turn to the actual function or process the interface is supporting.

What does this have to do with cloud? Leaving aside the computer-to-computer interfaces so important today, we still have an immense number of Software as a Service (SaaS) applications available for end-users to purchase and consume. Often, these are contrasted with more traditional enterprise applications on the dimensions of cost and feature set, but I think SaaS providers have (and take) an opportunity to also differentiate on interface design, for the following reasons:

The interface is the thing for customers - The ongoing consumerization of IT means purchasing decision-makers are not necessarily IT people, but line-of-business managers who assess based on functional needs rather than infrastructure integration. They don't see the software install, database, or infrastructure - they see only the interface shown to them. By removing the infrastructure from the discussion (other than to demonstrate its ability to provide a reliable service), SaaS providers can focus attention on the user interface and how well it will meet those functional needs.
User feedback is embraced and quickly acted on - Because the application is not distributed to many independent customer infrastructures, it can be updated as often as needed to meet customer requests. For instance, Rally Software, offering a SaaS Scrum project management application, uses Scrum and releases updates every 6-7 weeks; the updates come directly from customer requests.

I realize this is nothing new, and interface design has always been important. But we still have so many interfaces still incredibly non-intuitive and difficult, getting in the way of actually getting things done, even as the iPad, Android tablets, and even Windows 8 offer a new way to think about how to interact with any application. Hopefully as cloud computing becomes increasingly mainstream in the large enterprise, decision makers will demand the gold standard of interface design ("I just use it") and the market will respond accordingly.

Taking time to lift the curtain

2011-08-07T09:57:00.000-05:00

A relative of mine called me earlier this week because she couldn't access any web pages. She had already called her ISP multiple times, but got no assistance. After a few minutes of testing and checking her configuration, I had figured out it was a DNS server issue. Changing to Google's free DNS servers fixed the issue.

As is usually the case, she said, "you're a wizard!" to which I have no real answer. My initial thought was, "no big deal" - pretty standard for someone who works in IT. Then I started to consider how difficult it is to truly adopt the perspective of someone who hasn't spent the past X years in technology - it's too easy to assume that people understand what to do when confronted with a seemingly basic problem.

Why bring this up? Because at the same time, a hot topic is how IT people are increasingly not needed for basic support and need to adopt new higher-value roles. Another is the consumerization of IT, driven by continuing developments in cloud computing. But does the chatter around these topics obscure a widening gap between people who can support themselves and get connected to all these services, and those who cannot? And if so, how to close that gap?

The usual response, which I tend to agree with, is education. Technology is scary to many people, and the first response to the unfamiliar is to freeze up or retreat. Making the unfamiliar and scary less so for customers allows them to re-process what they are dealing with and come up with ways to fit that technology into their business practices.

A blinding flash of the obvious, right? Well, yes, but only in concept. Execution is a whole different matter. To its credit, IT does often include some sort of communication and training plan in any large-scale project or rollout. But what is in the plan? Sending emails, creating web pages, maybe some opt-in training. And while these make offer a wealth of information, they are no substitute for open forums, one-on-one meetings, and required (or at least well-incentivized) hands-on training.

Yes, these are expensive. They take up a lot of time, and need strong leadership to pull off. As the head of an IT organization, I spend a significant amount of time doing just that - conversing with my customers, listening to their concerns, and helping them adjust to new tools. In environments influenced by fear of change, the result (productivity and comfort with changing technologies) is well worth the investment.

The cloud operations model

2011-05-14T08:43:00.000-05:00

James Urquhart posted an insightful article on the false debate around whether private cloud is really cloud. By positing the idea of cloud as both a business model and an operations model, Mr. Urquhart opens the door to a continuum of paths to the cloud, regardless of how risk-taking or risk-averse any particular company is.

I discussed this topic last month based on a spirited discussion on Twitter about the validity of private cloud. I used a lot more space to describe what Mr. Urquhart puts into one paragraph (my emphasis):

[I]f you look at cloud as an operations model, the value of running an efficient resource pool with reduced bureaucracy is highly compelling, even if you can't reach the efficiencies of a larger public-cloud provider. Given the complexities of moving data, applications, processes and everything else IT to the public cloud, an internal cloud service becomes a highly compelling option.

Many medium-to-large enterprises have not only computing power that can be more effectively and efficiently deployed, but also a lot of people performing similar, and perhaps identical, tasks in different departments or business units. This may have arisen from various events in corporate history, be it dissatisfaction with company-wide services, political maneuvers, or grass-roots efforts grown wild. The result is the same - lots of people doing the same job, and that job tends to be lower value (maintenance, support) than what is needed (business alignment, service creation/improvement).

In a cloud operations model, sub-units still build and deliver services to their customers as they do today. The key difference is how and where they build those services. The use of a centralized, on-premise, multi-tenant resource pool, even though it's not as elastic as AWS, changes the game significantly in terms of how people think about IT roles and responsibilities. I submit that going to the cloud operations model can have more impact than the move to the public cloud:

Data center-related purchasing shifts to a single group, who can better negotiate company-wide prices and discounts due to the necessary scale/volume for the resource pool.
Data center management moves to a centralized team, who can focus on building the expertise and committing the time and energy to being great at it.
IT people tasked with delivering applications and services can now do so without spending undue time on underlying infrastructure.
Time reclaimed from reducing data center redundancies and time to deploy services can be redeployed to high-value IT activities that more directly enable business growth, such as researching emerging technologies and business process analysis.

Once this model really takes hold, having meaningful discussions about what, why, how, and when to move to the public cloud can become a lot easier. The business folks have gotten used to a certain decoupling of hardware and services, while the IT organization is better prepared to engage on business-related issues. Most importantly, everyone will have gained necessary experience in rethinking how technology is delivered and managed in preparation for future transformation.

How do you get to the cloud? First, get on the road.

2011-04-09T10:52:00.001-05:00

I follow the clouderati\all list on Twitter to attempt to keep up with what's going on in cloud, especially now that I don't have specific responsibilities or projects in that area. It's generally stimulating, and given the rate of change in technology emergence and adoption, it's only a matter of time before such projects arise.

One running thread has been something along the lines of "Is private cloud really cloud?" Large enterprise infrastructure vendors want you to say, "Of course - it has cloud right there in the name!" while public cloud providers tell you, "Of course not - it fails the definition on any number of levels!" I tend to lean toward the viewpoint of people working in the public cloud - after all, elasticity is a key tenet and it's extremely difficult (if not impossible) to be elastic in one's own data center.

That said, I'm coming around more and more to the idea of using private cloud-like infrastructure as a "gateway drug" for people to eventually move to the public cloud, especially if it fulfills the goal of better aligning IT with what the business actually does. My organization is both large and decentralized, with IT departments at various levels from historical decisions and funding. As a result, we have what you would expect to find in such a place - many data centers and server rooms, lots of fragmentation in data storage and protection, and an abundance of service duplication.

For a number of reasons, the institution is not fully comfortable with moving its data to the public cloud; it would rather store its proprietary (and often heavily regulated) information on premises. At the same time, we (and presumably we're not alone) continually seek ways to both improve our economies of scale and reduce the risk of data and productivity loss for our internal customers. Establishing a multi-tenancy infrastructure in the institution's primary data center (i.e. private cloud) helps in both cases.

The burden of infrastructure management shifts from many IT departments to one dedicated group, where they can concentrate expertise and gain higher server/staff ratios.
The various IT departments, mostly free from hardware, storage, and backup maintenance, can use the gained time to engage with their customers and build/deploy services specific to their needs rather than simply "keep the lights on."
Business leaders gain more bang for their IT buck, which is made visible through more rapid service deployment and productivity increases.

Once an organization reaches its steady state in a private multi-tenant infrastructure, it's natural to ask, "What's next?" And the answer increasingly will become, "Don't upgrade this system, migrate to the public cloud." IT will be able to show a story (with supporting data) of the benefits of moving from traditional infrastructure to private cloud, and then how those benefits can increase again with the move to public cloud. Though it may not be the most efficient way to get there, it may yield enough initial benefits to make a potentially scary migration more like a logical progression.

Being a manager - easy to describe, less easy to do

2011-03-27T10:17:00.000-05:00

The NY Times ran an article a few weeks ago on Google's self-evaluation of its managers and what their employees prize in a manager. A common reaction was, "How could subject matter expertise be at the bottom?", which I can relate to. Another, and possibly more interesting, response, was a blog post essentially dismissing the eight points Google published as "just management, right?" This sentiment is unfortunately pervasive in our culture, going back at least a few decades. After all, everyone knows that the key tenets of modern-day management - results-orientation, communication, coaching, empowering, having vision - are both "not rocket science" and ambiguous enough to avoid any real consequences.

My first reaction was to want to refute such an argument, point by point. Having sat on this for a couple of weeks, I'm less interested in a back-and-forth of the minutiae of the language or even Google's intent in their self-study. I thought instead about what resonates with me as someone in a leader/manager role.

I was drawn instantly to point 7, though it's further down the list. Having a clear vision is not some pie-in-the-sky idea, nor is it the same as having a goal. A vision is a description of an improved future, with characteristics that are achieved through discrete goals attainment. Most people want to be part of something larger than themselves; in addition, people want to know their tasks, whether they enjoy them or not, are contributing to that larger context. Managers are responsible for providing vision and meaning to their team and aligning the team's work to that vision. As initial successes occur, reinforcing the vision helps motivate everyone on the team toward fulfillment.

Though vision is point 7, the six points above it all help support achieving the vision. Managers need to:

Communicate the vision and reinforce its relevance to the daily work
Guide the team's roadmap to align projects and operations with the vision
Act as a mentor to team members and define/guide individual goals that support the vision
Align individual goals and growth with both the vision and career development needs
Set expectations, empower team members to act, and expect results that align with the vision
Provide regular and targeted feedback to help people learn and grow
Know your team members well enough to help them better understand the team vision and support their needs as they arise

Easy enough, right? And yet stories abound with examples of bad management, and with good reason. Management is a classic "easier said than done" case. It requires constant thought, consideration, and action, and a deep understanding of both oneself and every person on the team. And it may not work out in all cases; after all, understanding people's behavior and motives is imperfect at best, and gaffes are bound to happen. That said, watching a person or team attain a goal they previously thought out of reach, and knowing you helped them understand they could get there, is pretty darn great.

For reference, here are Google's eight points (via NY Times):

IT as a customer-satisfying service

2011-03-06T10:48:00.002-06:00

I recently spent a few days in meetings with some of my colleagues and one of our enterprise vendors. The discussions themselves were very productive, and we spent a lot of time talking about "IT as a service." In most IT conversations, this concept tends to focus on delivering IT applications and resources to end-users in a manner that enables self-management, access from anywhere, and a consumption-based financial model. The public cloud, for instance, is emblematic of IT as a service - it addresses all three factors in a way that benefits customers and providers alike. In a decentralized enterprise, IT as a service tends more toward providing IT resources centrally and enabling downstream admins or end-users to build services on top of those resources (e.g. a private cloud).

This approach helps balance many organization's needs for economies of scale and support for specific business requirements, and makes a lot of sense to me. However, delivering technical functions is only part of providing a service. Too often time isn't spent on the things that ensure customer satisfaction:

Responding quickly and personally to incoming requests
Following up on initial response with the appropriate communication and action
Setting expectations for resolution and following through on those expectations
Ultimately addressing the request quickly and enabling the customer

It's not that people don't think these are important. Certainly, when any person is the customer in such an interaction, these become vital. Ever deal with an issue with your cable, Internet, or phone company? Then you probably can pinpoint when you've been disappointed and on which item(s). And stories abound in general about how terrible customer service is across industries, or at best, inconsistent.

So what makes these so hard to do from the provider side? Or more importantly, what makes these so hard to do consistently? Again, it's not that people don't think it's important. I've rarely met anyone who didn't want to provide at least good service, and most want to offer great service.

More often than not, what gets in the way of providing great service is attempting to provide great service. Stay with me here. For (a somewhat extreme) example, the team may work very hard to resolve an unplanned outage by hunkering down in the server room and getting things up and running again. But at the same time, customers are waiting anxiously for any word on when they can get back to work. If no information is making it to the customer, than is the team providing great service? If you're on that team, you tend to think you are - after all, you were tirelessly laboring on behalf of your customers. But the customer perceives the following:

Service is down! I'm going to get behind on my work and have to make that up!
What's going on? When can I get back to work?
Is anything actually being done?
Finally! We're back up! What took so long?

The result? Customers may not appreciate the effort the team went through to restore service, and the team may resent the under-appreciation. Generally speaking, this tends to happen when the team focuses on the first and last bullet points - respond quickly, then address and enable. In between are the equally critical and achievable tasks of communication and expectation-setting. Each person addresses these tasks a little differently, but I've noticed some common themes among people that excel in this area:

Daily routines that enable communication - "Daily" is key here. At least once per day, emails need to be answered, calls need to be made, and task management systems need to be updated. This can be at any point in the day (beginning, middle, end), but it needs to be every day. A routine done 2-3 times a week is too easy to let slide in an area that requires a lot of discipline. Check out http://dailyroutines.typepad.com/ for some interesting examples of scheduling one's day and setting routines.
A running to-do list that gets updated every day - You have to know what you're responsible for at any time, and keeping it in your head (and not in writing) usually leads to some amount of slippage. Having a master list, perhaps fed from your task management systems and emails, is very helpful for keeping track of open items. It also allows you to cross those items off the list when they're completed, so you know what you've done as well.
Communication whenever possible - Typically, any day contains pockets of a few minutes where a quick check-in or update can be completed. You may be waiting for something to happen or be ready to transition from one big task to the next. Use some of these times to update yourself on inbound requests or information, and update your customers and colleagues so they can better manage their own expectations.
Continual evaluation of one's own service to customers and colleagues - Despite the measures above, it's still possible that something is slipping through the cracks. After all, things do happen throughout the day that are seemingly aimed at undermining schedules and planned tasks. Regular 5-10 minute recaps of your day or week can help you remember anything that wasn't accounted for.

These items don't make up a perfect solution, but it can help reduce the incidence rate of saying, "I'm not sure where that's at. Let me get back to you." The people around you notice and appreciate the effort of your knowing what's going on and making sure they are also up to date on any given situation. Over time, these tasks become faster to complete and require less effort, allowing you to both manage the technology and enable the customer. In the end, customers are more satisfied with their service and those providing the service are more satisfied with their work and the value they add to their organization.

Companies like Nordstrom, Enterprise, and Rackspace build their business strategies around differentiating on customer service; the question is, shouldn't everyone?

Leading change, starting with yourself

2011-02-06T09:50:00.001-06:00

About two hours after my last post on changing the IT organization, I realized I had started from articles on strategic change to go toward tactical moves in team change, but I hadn't talked about the real place to start: with oneself. Possibly the most important lesson for any manager is that you cannot change another person; you can only change the situation for that person in the context in which you have influence. He/she must then determine that change is necessary and that effort will be taken to achieve the change.

And yet we talk about change as something that can be imposed on an organization from above. Task forces are convened to create pithy messages and educate everyone on why change is great and life will be better. Perhaps goals and rewards will be realigned to provide incentives for "getting on the bus." And these are necessary, but cannot be the end of the story. At the end of the day, each person will look to his/her immediate supervisor and teammates for leadership by example, and that's where change really needs to happen.

Too often we get either overly satisfied or complancent with our own behaviors, routines, and ultimately performance. Then, when something comes along to shake that up, we double down on "how it's always been done", making any effort to improve that much more challenging. This isn't because people are bad or lazy; it's just who we are. We are creatures of habit, and breaking habits is very difficult. But hard doesn't equal "shouldn't be done." If people are looking to you to set an example (regardless of position in the hierarchy), you need to ensure you are doing your part to help yourself and your team.

The key is understanding what change is necessary and committing to changing yourself appropriately to support the overall effort. This doesn't mean suppressing your nature or "not being yourself" - instead, find ways to integrate new behaviors with old so that you can still be comfortable with how you present yourself and interact with others. This also likely means asking questions of others to gain clarity, requesting (and receiving) candid constructive criticism, and being very conscious of your actions on an ongoing basis. You may not like the answers you get and may resent those who give them. You will almost certainly find yourself a little drained from the effort of always watching and checking yourself.

Again, none of this is easy to do, and very few of us are born leaders with the requisite talents and skills to guide others toward an improved situation. But people can tell when you're working to change, and will both appreciate your effort and start thinking about their own changes to make. We all lead others in some way, and we all have people who take their cues from us, so are you going to let them (and yourself) down?

IT means change, and change means people

2011-01-29T11:00:00.000-06:00

An ongoing discussion with colleagues (and in most IT organizations, I suspect) is how best to use the people and resources at hand to deliver services and support to customers. While many on the outside look at IT as being all about technology, the reality is IT leaders and professionals need to continually examine themselves and their teams when figuring out what's next. As Brett Anderson at CIOUpdate.com puts it, "it always comes down to people" when IT change is in the wind.

In the not-too-distant past, IT professionals could find a niche specialization, lock themselves in an office or back room, and happily work in a virtual vacuum for years or decades. Now, the trend toward unified infrastructure, managed IT services, and cloud computing have all forced the question of "what are our IT people actually doing?" to bubble up, and appropriately so. Many services that once required specific and local controls to add value, such as messaging and collaboration, have both become commoditized and increase in value when allowed to take full advantage of network effects. The results are predictable: more institutions are shifting commodity (and sometimes competitive) services to the cloud or other third parties, and IT organizations are getting a little lost in their focus as their world has started to transform.

The general response from experts has been, "Retrain your people and focus them on business-facing issues." Great in theory, but not exactly easy in practice. Though not quite as drastic as turning manufacturing workers into knowledge workers, telling someone who has spent 10+ years in say, systems administration, that now it's time to be a business analyst is not going to help you or your customers. Offering training or guidance isn't enough either; what if being a sysadmin was the end goal for that person? It takes relatively little time or effort to develop routines and habits, and faced with (possibly extreme) change, those routines and habits become both havens and crutches. My hunch is that any IT organization facing change (i.e. almost every IT organization) contains people with varying levels of ability, knowledge, and willingness to redefine themselves in a new context.

And to be clear, we're ultimately talking about people changing themselves. Communicating visions, mission statements, or value lists are necessary, but likely will not on their own accomplish the kind of shift from "support the technology" to "enable the business" that is increasingly required. Even hands-on management has its limitations, as a key tenet of management is that a person cannot change another person. The only lasting change for a person is one that is self-realizing and self-actualizing. A leader's role, then, is to create a situation for each person that helps him/her to understand both what change is necessary and how to start moving in that direction.

If a vision of the post-change organization has not been communicated, that needs to be done. That post-change vision also must include some detail about the roles that are most valuable to the business and what those roles entail. At least as important is communicating the incremental improvements on the road to the end-state, so people can both see how the organization will get to the end and start to understand their role in doing so. Feedback should be encouraged and the incremental steps may need to change over time to accommodate shifting external conditions, though the end-state should remain consistent.

Leaders and managers then need to commit to one-on-one interactions with each person to engage in a personalized feedback loop and aid in understanding new roles and responsibilities as they arise. This will also help managers to assess the person's ability and willingness for change, and create the optimal situation accordingly. Like most management techniques, fairness will not mean equality here; be prepared to adopt different approaches and time commitments for each person. Issues may range from developing analytical skills to improving verbal communication to overcoming fear of failure, and managers must be ready to help address them all.

At the same time, leaders need to find opportunities to extend some of the same techniques into a group setting and have people start helping each other to change together. There is a lot of value in peers finding shared meaning and finding ways to solve common problems, as this ultimately helps people to truly internalize the organization's vision/mission/values. You know you're on the right track when your team comes to you with shared ideas for improvement that they have already started to execute on. Encouraging those results lead to the desired virtuous cycle of continuous improvement.

Re-reading the paragraphs above, it still sounds too easy. It's not - and it's hard because real personal and behavioral change is the hardest thing anyone can do, and your ability as a leader to effect such change is minimal. But it's also the most important thing that can be done to enable the organization to move forward, and often yields more than enough reward to justify the effort.

Who needs to be convinced about cloud availability?

2011-01-16T11:55:00.001-06:00

In the wake of Google's announcement that their SLA for Google Apps is now 99.99%, with all downtime (planned or unplanned) counting toward the SLA, the question has arisen: is service availability still a valid reason to avoid cloud services? At this point, the question may be less a matter of numbers and more one of perception and education. For whatever reason, people tend to believe two things about the availability of the technology they own/use, especially in the workplace:

It should just work, all the time, without any issues.
If I can see/touch it and know the people who run it, it's more reliable and I know issues will get fixed more quickly.

These sentiments remain prevalent across both technology consumers and IT professionals. Google's announcement speaks to the first point - IT is seen as a utility that is always available to be consumed, like electricity or water. This point is the more rational of the two, and cloud providers tend to aim at educating potential customers about the results of building an infrastructure that understands and accounts for component failure while continuing to provide services. SLAs and uptime figures are published and cited to support providers' arguments, and they generally meet or exceed people's expectations. Indeed, millions of people use a cloud service all the time - Gmail, Facebook, Twitter - and already use these services as utilities: always on and available when needed.

But what about the second point? Why is such value and importance placed on knowing exactly where the technology is and who runs it? In many organizations, end-users tend to know and (hopefully) trust their local IT staff, which makes them more confident that when something breaks, the IT team can be counted on to fix it. People also like to know that they have one or more specific IT people they can contact if something goes wrong, and that they can influence or control the IT people to get the problem fixed.

IT organizations are also complicit in reinforcing the stereotype of the IT organization that can fix anything and jumps at every issue. The idea of the IT "hero" or "wizard" is long part of our culture, to great apparent emotional benefit. After all, who doesn't want to feel like a hero sometimes, especially when being perceived that way can help ensure IT headcount and investment? This tendency absolutely benefits both parties in terms of customer satisfaction, but also presents challenges in moving toward a model that includes the cloud (or any third-party managed solution).

So cloud providers' challenge is two-fold: persuade IT organizations that infrastructure maintenance is not where they can add the most value to their organization; and then help IT to convince their consumers that local doesn't always mean better when talking about service delivery. Helping IT reconsider its position in the organization may require providers to seek partners that focus more on technology strategy, as Google and Microsoft have begun to do, and craft messages in their opening pitches and materials that help IT management visualize their new role and value. If providers can clear the first challenge, IT will likely champion addressing the second.

IT organizations in the cloud

2010-10-25T11:24:00.003-05:00

With all the talk about the technological and financial aspects to the cloud, there seems to be surprisingly little about the organizational implications of shifting services into the cloud. If you don't have as many servers, do you need so many systems administrators? What about software developers or quality assurance people?

The easy, but not necessarily best, answer is eliminating those positions (and therefore the employment of those people). While that is perhaps tempting, a better approach is to consider what roles you'll need to best manage and support your business needs as the IT environment evolves, and then match the smart people on your team to those roles.

Reconsidering the IT mindset

Moving services (or establishing new services) into the cloud is like writing software for the iPad or Android - it requires a very different mindset to manage properly. In particular, a cloud-based service or product is thought to be very easy to support and very fast to turn on. In addition, cloud service providers are constantly releasing new features, driving demand for those features to be enabled in your environment. As a result, end-users' expectations of IT responsiveness for support, changes, and new features will only increase as services are moved to the cloud. Moreover, if IT manages cloud as it has other technologies, end-users are more capable than ever at going around IT to get what they need - indeed, now they can just sign up for a service over the Internet and get people using the service without IT even knowing about it.

To avoid this, IT needs to become more proactive than ever at driving service management to the end-users. IT needs to effectively sell itself as the best channel for acquiring cloud services because it understands both the business and the technology better than anyone else. This isn't a new concept - IT has had to become increasingly business-focused and customer-facing over the past decade. What is new is the ease of acquiring IT services without the IT department's involvement.

Roles and redeployment

The odds are high that your IT environment will move incrementally (and likely not fully) into the cloud. As such, your existing applications and infrastructure people will still need to continue supporting the data center and in-house applications. At the same time, you should start to shift some of your people toward the following roles that will enable IT to become more of an asset to the company for both cloud and in-house services:

Service Desk- On a day-in-day-out basis, end-users will continue to work most with the Service Desk team. In addition, the ease of configuration often provided in cloud services means that more tasks can be moved to the Service to improve first-call resolution and overall customer (and job) satisfaction. Consider augmenting the traditional service desk analysts with application specialists who can serve as subject matter experts and points of escalation for support.
Business Analyst- It is increasingly crucial that IT understands business needs, which are rapidly changing as customer demand shifts and technologies improve. Rather than wait for the business to declare their needs, engage directly with each department through frequent meetings and hallway discussions to make sure that (1) their needs are heard and understood by IT, and (2) they understand that they can rely on IT to "get it" and deliver the desired solutions.
Quality Assurance- Just because you didn't develop it doesn't mean you don't have to make sure everything works before going live. Your QA people understand how to write and execute test cases to ensure a minimum of issues when releasing a new service or feature, which will help in building confidence in moving to the cloud.
Network Administrator/Engineer- Cloud services require network/Internet connectivity, which is now a mission-critical infrastructure component. IT may spend more time focusing on network performance, monitoring, and maintenance to ensure access to corporate applications.

As you evaluate these and other roles, consider the strengths of your existing team members and identify those that can start evolving into these roles. Next, determine all of the change factors (compensation, reporting structure, etc.) as a result of any reorganization. Then start engaging one-on-one with team members about the possible opportunity to expand and evolve his/her role into the cloud space. Positioned correctly, the response may well be enthusiastic beyond your expectations.

Building momentum

2010-10-10T08:22:00.000-05:00

It's been over a month now since I started my new role as an IT leader. In that time, I've focused on meeting people, learning about the institution and its expectations of IT, and understanding what we do and how we've gone about doing it. It's provided me with key insights when considering both immediate next steps and the overall path forward.

Organizations of all sizes and shapes tend to figure out a way of getting things done and stick with that path, largely out of famiilarity. While this can help to improve the precision of task completion (i.e. the same task is done the same way each time), it also can close the door to different practices and methods. I've long thought that once a group of smart and curious people start really considering their options, they tend to arrive at a new and interesting way to get things done. Getting started with those first rounds of consideration, then, are key.

Like anything else, the leader's role is to motivate others and create the right situation for the team to succeed. This is not an overnight activity - it takes significant time and effort (proportional to the size of the organization) to both communicate a vision and get everyone actively excited about the possibilities of participating in that vision. Moreover, the leader must be consistent in the message and continually find concrete examples that support the vision.

The primary positive effect of this is momentum - the team gets excited about the opportunities to grow and renews its commitment to its mission. You may also find, as I have, that you get excited as well - having these conversations and getting positive responses is motivation to keep working toward creating the situation for continuous improvement and high performance. A motivated group is probably the most important part of what comes next.

Getting it right the first time

2010-09-19T10:06:00.000-05:00

I came across an excerpted transcript of a podcast on HP's cloud management software, which included this statement by Robin Purohit, Vice President and General Manager of the Software Products Business Unit for HP Software & Solutions:

If you think of Agile and the pace at which now new application innovations are bring rolled out, it really means that you have to get things right the first time.

I was struck by this initially because "getting things right the first time" seems antithetical to Agile, which is based on a philosophy of rapid, incremental improvement. At the same time, there's also the realization that once a policy or process is released, making changes to that policy or process is very difficult, and such change probably cannot keep up with the rate of change in technology. This is especially true in the cloud, where providers constantly release new features and functionality, almost without warning.

Although the source article was ultimately about management software, this holds even more true when talking about upstream processes such as governance and standards definition. Moving to the cloud means empowering end-users with a greater ability to shape his/her environment than in a traditional IT setting. If there isn't at least a basic set of guiding principles to abide by, you can be sure that in a few months the company's account will contain much of the same clutter and inconsistency as is often found in areas like file shares and document management systems.

Defining standards of usage for cloud-based services should be similar to doing so for other services:

Identify roles and responsibilities for governance
Educate governance body on the service and its capabilities
Draft usage standards and present to the governance body
Establish a consensus on usage standards
Communicate usage standards as part of the roll-out and ongoing support

What does change is the mind-set everyone involved should adopt when going into this process. Rather than ask, "How can we control how the service is used?", the focus should be on "How can we best empower people to responsibly use and extend the service?" Understanding how the service can and will be employed to share data, create mash-up applications, and otherwise fit into regular processes is key to creating a set of standards that people will want to adhere to. Trying to exercise too much control will result in the workarounds and rogue setups that frustrate both end-users and IT.

Back to the beginning - "getting things right the first time." Your governance structure and standards don't have to be perfect before deploying a service. They should be based on pragmatic understanding of the service, meet the most critical needs to protect the company from legal action or financial vulnerability, and be straightforward enough for everyone to understand and comment on. Feedback should be captured and used to help hone usage standards. Ultimately, your organization should have a usable and fairly created set of standards that are internalized by end-users and will implicitly abide by, reducing efforts for maintenance (such as data gardening and access auditing).

Getting to new and improved services

2010-09-04T09:50:00.000-05:00

I've been spending a lot of time recently thinking about providing IT services effectively and efficiently and how to make improvements along both dimensions in any given situation. To start, let's look at IT responsibilities in two major categories:

New/improved services - business analysis, projects, research, development
"Keeping the lights on" - break/fix, service requests, planned maintenance

The first category is where IT really adds value, as a team that can both understand the business' needs and provide robust and ever-improving solutions that increase the "top line" of performance. Unfortunately, IT tends to spend only a fraction of its time here, largely due to the effort needed to satisfy the second category.

"Keeping the lights on" consist of a series of challenges that have largely been solved within the industry. Quick searching for any facet, ranging from authentication/authorization to service desk management to configuration management, will yield results for processes, tools, and methods. In fact, it's almost overwhelming to consider all of the available options.

The goal is to optimize the efficiency of this category. No one gains a competitive advantage from "keeping the lights on", so we should spend the minimum in resources to achieve the organization's needs for support and maintenance. Bear in mind, however, that doing so will be different for each organization - for instance, some organizations accept a remote call center approach for efficiency, while others demand a high-touch, in-person support experience. When evaluating an environment for efficiency, you should consider the following factors:

Variety of technology to support and ability/need to standardize
Importance of support characteristics, including speed of response and resolution, interaction types (email, phone, in-person), and environment context
Automation of common tasks

Ultimately, some balance of these factors are required, and not everyone is going to be happy with the outcome. When considering such an evaluation and potential change, inclusion is critical - involve at minimum the following people:

The people who actually fulfill these tasks, such as end-user support, systems/network administrators, and application support personnel
Key end-users that require a significant portion of IT's effort for support
Business leadership that can help articulate overall technology goals and objectives and provide context for technology strategy

Finally, be clear about the benefits of possible change. Essentially, any time not spent on "keeping the lights on" can be used for new and improved services. An end-user support person who isn't fixing an email problem for the umpteenth time can be researching and consulting on the value of mobile technology or finding out about new requirements ("wouldn't it be great if I could..."). A systems administrator who isn't manually patching servers can instead enable new features for existing services or identify new technologies based on customer feedback. An environment that can spend time on real improvement is better for the end-users, better for the IT team, and better for the organization.

Building a desk

2010-08-21T09:32:00.000-05:00

I was talking with colleagues recently about the various types of cloud services and realized that it's not exactly easy to articulate the types - after all, it's all cloud, right? During the discussion, I hit on the following analogy: let's say you want a desk. You have three basic options:

Buy the desk pre-built, selecting basic items such as color and finish
Buy a kit to build the desk, using pre-defined options for the top, legs, and other components
Buy the raw materials and build the desk from scratch to your specifications

In the cloud, option 1 is equivalent to Software-as-a-Service, or SaaS. What you want is basically ready to go, and you can make minor configuration changes to better suit your needs. You will probably also pay less for use of such a standardized service.

Option 2 is analogous to Platform-as-a-Service, or PaaS. You're given a larger range of options to develop a more customized experience within the provider's range of options. For instance, you may have only 1-2 options for programming language, database platforms, or integration with other applications. You'll also pay more for the service because of the necessary development effort, but it may be worth it to gain the functionality you need.

Option 3 is equivalent to Infrastructure-as-a-Service, or IaaS. Starting with "raw materials" such as CPU, RAM, disk, and network bandwidth, you can build a complete server farm in the cloud. You have full control over the operating system, security, data, and applications in your IaaS environment to configure and customize to your fullest advantage. However, you'll need not only developers but systems and network administrators to manage the environment, raising the cost yet again.

Ultimately, your needs (and those of your company) should determine which cloud service type is best for any given service. Because the cloud ecosystem is rapidly changing, what works today may be unnecessarily complex tomorrow. As long as your data and applications remain portable (by using standard protocols and languages), you should be able to continually move to the best service for your specific (and evolving) requirements.

Privacy in the cloud: an oxymoron?

2010-08-15T12:37:00.002-05:00

Eric Schmidt has repeatedly asserted that the notion of privacy is coming to an end and that people need to simply change their ways. While I've long believed privacy on the Internet is incredibly hard to maintain, the issue of privacy - particularly as it relates to personal and corporate data protection - needs to be considered by anyone using a cloud-based service.

What is being posted on the Internet?

I'm consistently amazed at what people are willing to post online, even amid the clamor for privacy on the Internet. While some have locked down their Facebook/LinkedIn/Twitter accounts, many people continue to upload and post information about themselves that could be damaging at some future point in time. Moreover, that feeling of freedom in the personal realm easily transfers into the corporate arena. I remember having to be more careful than usual with whom I share information with to avoid it going up on Twitter 5 minutes later because some people just want to share everything.

It's critical that companies have not only policies, but also training (with examples) on responsible corporate data stewardship. If people don't internalize when it's appropriate to share information, they're more likely to inadvertently disclose that information.

Is it really more secure when it's on your computer(s)?

I've talked to different people who are uncomfortable using the cloud for data storage because "I want to control and know who can access my data". After many years in IT, I'm confident that even when a company owns all its IT assets, people don't know who has access to what data. Permissions get added, but never removed. Poor processes and procedures lead to people long gone from an organization still having access to data. IT people the end-users have never met, like sysadmins, DBAs, and programmers, often have access to data because of inherited administrative privileges. Often, this adds up to a lot of people.

In addition, according to the Digital Forensics Association, almost half of all data breach incidents in the past five years occurred because of laptop theft. Of those, about 1/3 are stolen from the place of business. In the financial industry, penetration into the corporate data center by an outsider accounted for the vast majority of incidents and records disclosed.

What does this all mean?

To start, end-users and admins alike need to be well-versed in how to protect IT assets and data from being taken by an outsider. Organizations also need to make sure to include physical security as part of the overall data protection strategy to help protect against theft. IT then should enact measures to log and audit all data access, including itself.

Most importantly, organizations need to determine how best to protect data at rest and in motion and understand their own capacity to execute on those requirements. IT and business leaders needs to take an honest look at the company and identify both what data is truly critical and what investment they're willing to make to mitigate the risk of a breach. It may be that a cloud provider, who must ensure customer data is unavailable both to its administrators and to other customers, has invested more in security than your company has and can offer a more secure and cost-effective solution. Decision-makers who are still locked into the narrow "if I can see the server, I know where my data is" view without training end-users and understanding all available data protection options are costing their companies in more ways than one.