What could be the point?

I recently gave a presentation at the EDUCAUSE annual conference with colleagues from Brown, Johns Hopkins, and UNC-Charlotte on supporting digital scholarship services. The presentation itself was a rewarding experience, and I really appreciate the opportunity to have worked with such knowledgeable and driven colleagues. As someone who mostly advocates for such services rather than provide them directly, I needed to learn a lot to catch up in this area.

Some hours after the event, A colleague from another Big Ten university who had attended our session wrote to me, and he said possibly the most intriguing thing I heard during the conference. Like me, he heads technology services for a college within the larger university, and has been working every effectively to shift scalable commodity services to the central IT organization. He said (I'm paraphrasing), "What if digital scholarship was the primary idea of what we do at the college level, rather than a component of our services?" We talked about it briefly the next day, though we were both mostly trying to wake up, it being 6:30am according to our Central time zone-adjusted selves.

The idea has certainly set my mind going on this. We've shed a lot of our hardware-based infrastructure, and are already considering ways to reduce even our virtual servers to a minimum number as we adopt cloud services for file sync/sharing, virtual desktops, and applications of all kinds. So what if we mostly abandoned the traditional IT philosophy of a standard service catalog and adopted digital scholarship as the focus? Our organizing principle then becomes about supporting as many edge cases as possible, knowing each faculty member or lab represents an edge case. Underneath, we need a set of sustainable platforms to ensure deep technical expertise on our part and increased longevity for the projects built on those platforms. We need to continue to foster partnerships with other groups in this space, like central IT and the University Library, and build ever stronger relationships with our faculty and students. We need to learn quite a lot about digital scholarship and the disciplines we enable. Perhaps most importantly, we need to embrace the primacy of the end-user experience as our focal point rather than consider it the lowest rung of our services and capabilities.

I'm not yet sure how this could work. In fact, this seems like a pretty scary proposition - we've never done anything like this and don't have the skills and experiences already built into the team fabric. But the potential for transformation seems so high that we have to at least try it on and see how it fits. More to come.

Why try to collaborate?

As mentioned in About, I work in higher education, which can be (at least somewhat) justifiably described as highly decentralized when it comes to both business processes and technology service delivery. Efforts to coordinate or centralize either meet with challenges as well-intentioned working groups attempt to reconcile the many disparities among distributed units' processes and practices that have organically grown over several (or many) years. The results can include efforts that start but don't go anywhere, endless meetings about the same conversation, and relatively little change from the end-user's viewpoint.

Sounds pretty grim, right?

Despite the dour description, positive outcomes do arise from all these attempts at collaboration.

1. People get to know one another. Sounds obvious, but in a large (or even) small organization that has multiple silos of information and process, this is not necessarily the case. I have been in any number of meetings where people who should know each other don't. If we can't get this done, it's that much more difficult to get anything else done.
2. People start getting comfortable with the value and costs of collaboration. Again, obvious. But it's much easier to be effective in one's own sphere than to be part of reaching across barriers and making something happen in a larger context.
3. The first two enable repeat attempts to share and collaborate. Even if a particular attempt fails to bear fruit, the relationships and increased comfort level allows the parties to say, "Maybe next time we'll have the right problem to solve/opportunity to succeed."

In technology, the need to collaborate and share is especially important, verging on critical to success. Pressures to compete with great user experiences in the consumer world, keep up with exploding demand, and enable people to seamlessly cross information silos require IT not as a set of discrete systems and services, but as an ecosystem of loosely coupled (and often interacting) applications and data. Getting in the same room isn't the solution, but it's a start.

Taking the leap

It's been too long.

The primary reason for the long gap in posting is the focus of this post. Back in May 2011, I posted on the cloud operations model, building on excellent discussions among the Clouderati. At the time, I provided a few possible outcomes of moving to this model, including:

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

At the time, I was just starting to think about how these might work in my workplace. As a large, distributed enterprise, the cloud operations model seems to make a lot of sense. At the same time, it's not a familiar framework and would require a lot of work and some success to get going. So for the past several months, off we went:

1. Build an initial community: More or less by definition, a cloud-based model requires multiple parties to participate. That meant someone to actually run the cloud and tenants to use it. Thankfully, others had similar thoughts and from there, an internal group started discussing what we wanted to achieve and how we go about showing others this whole cloud thing was for real.
2. Get a cloud, any cloud: For reasons previously discussed here, going directly to the public cloud is not an option. However, we already had the components of a small private cloud, using a minimum of available hardware and software. This allowed our small team to both try out the technology aspects and start identifying the "ground rules" for a more scalable version. During this proof of concept, we also found our community strengthened through shared goals and effort. More to come on this in a future post.
3. Reorient the IT team: Having the cloud is an enabler, not the end-goal. Achieving the second and third bullet points requires change to the organization and reorientation of mission, values, and roles. The last four months have seen a lot of time spent on the question: How can IT deliver high-impact outcomes to the mission of our organization? Historically, we'd spent most of our energy on ensuring basic productivity, which was (and continues to be) core to our mission. But now we can use our move to cloud to start refocusing our time on identifying, articulating, and analyzing organizational needs, and then connecting those needs with existing or new services in our environment or in the marketplace.

So what's next? We just started on items 2 and 3, and though there's a lot of enthusiasm, we need to convert that to staying power. The IT team needs to train on new skills, from systems/applications administration in a cloud setting to business analysis and consulting. We need to spend time with our customers to show them the benefits of the new model and create some successes. Our systems management needs to be simplified to match our needs. These are all reasonable to achieve, and well worth the effort on our way to establishing IT as an enabler for our organization.

Interfacing with the cloud

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:

1. 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.
2. 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

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

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.

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.