Monday, October 25, 2010

IT organizations in the cloud

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.

Sunday, October 10, 2010

Building momentum

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.

Sunday, September 19, 2010

Getting it right the first time

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:
  1.   Identify roles and responsibilities for governance
  2.   Educate governance body on the service and its capabilities
  3.   Draft usage standards and present to the governance body
  4.   Establish a consensus on usage standards
  5.   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).

Saturday, September 4, 2010

Getting to new and improved services

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.

Saturday, August 21, 2010

Building a desk

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:
  1.   Buy the desk pre-built, selecting basic items such as color and finish
  2.   Buy a kit to build the desk, using pre-defined options for the top, legs, and other components
  3.   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.

Sunday, August 15, 2010

Privacy in the cloud: an oxymoron?

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.