CIO Toolbox Archive

Do the Math!

John.Weigelt

Published: December 11, 2011Posted in: CIO Toolbox, Cloud, General

I just came across yet another security pro recommending private audit of a cloud services provider facilities to get comfortable with the operations. Really?! It seems that the security and privacy professionals recommending this need to catch up on their reading and perhaps a little bit of math.

Fundamentally, cloud services are all founded on the principle of “scale.” Microsoft’s “Economics of the Cloud” whitepaper discusses the many ways that scale contributes to the supply and demand side economics of cloud services provision. In my blog post “Special is Extra” I explored how special requirements have the potential to increase the costs associated with the cloud service. Enterprise class cloud services providers therefore look to use standard approaches across their environments to provide scale at lower costs to customers. Standard approaches often include third party audits to test compliance against recognized approaches such as SAS70, ISO 27001, FISMA and HIPPA.

Now consider a cloud service provider with 10000 customers using geographically distributed resilient facilities. Full compliance audits against any recognized audit standard is a lengthy endeavor, even when all the supporting processes and paperwork are in good order. Audits can often last several months. So even if customers engage auditors with cloud services experience, these private audits will not be single day affairs and will require many days on site. If we were to be very optimistic and suggest that each audit would require a week on-site, with approximately 200 working days a year (no weekends, holidays, round down for easy math), that would leave 40 potential audit slots. At any one audit slot, there would be 250 (10000/40) individual customer reps going through the cloud facilities. The number of individuals could be far higher since each company would be represented by more than one person.

Let’s consider the impact of this from a security perspective. We quickly see that this practice, even if practical, would greatly reduce the assurance of the cloud services and increase the costs of the services (due to the added staff required to assist the 250 audit teams each week, to shepherd the teams through the facilities, conduct clearances and reviews of all visitors etc.)

As you consider your enterprise class service provider, review the independent audit reports against your compliance requirements. Rest assured that the independent experts that conducted these audits did so on your behalf and on behalf of all other customers using the service.

How Large is Your Project?

John.Weigelt

Published: October 18, 2011Posted in: CIO Toolbox, General

A few years ago I was interviewing candidates for a project management position on my team. There were quite a few local candidates with fairly similar experience and nothing really stood out between them. One CV was particularly intriguing. It seemed the candidate had been the overall project manager for a US Navy guided missile frigate. You have to admit that being at the helm of a $2 billion dollar project sounds pretty impressive? But is it really? Is it complex? Or simply complicated? It certainly is a lot of money.

While we have a tactile sense of the enormity of say a ship and a general feel for the wide variety of parts that need to come together so that this mass of steel, plastic, glass, etc. eventually floats, we don’t have the same sense for IT projects. My conversations with senior leaders in government have uncovered uneasiness for the large IT project. This unease is often as a result of experience with less than expected outcomes from previous projects. The Sept 2011 edition of Harvard Business Review suggests that IT projects are more prone to experience “black swan” style outcomes of cost overruns and managers don’t often properly plan for these eventualities.

I guess the first question IT managers need to ask themselves is: “Is my IT project LARGE?” Largeness is relative and needs to consider a number of factors. Some of these factors are:

Is the project complex or simply complicated?

How many stakeholders are involved?

Is this simply a technology effort or is it a policy or culture changing experience?

Have you done this before and at the same scale?

While I certainly didn’t invent the idea, I’ve long been an advocate of converting large projects into a program with many small discrete projects. It’s like taking a million dollar effort and dividing it into 1000 $1000 projects. Not only does the poor performance of any one small element have a much smaller impact, it also helps build agility into the overall program delivery. Of course there may be one or two absolutely critical pieces that can make or break a project, these can be explored early in the process so as to help inform further decision making.

Another key element is evidence based decision making. It’s often been said that if “you’re not measuring it, it’s not getting done.” Measurement is fundamental to understanding how you’re doing; If you’re on track or if things are going off the rails. And it’s also important to measure the right outcomes as well. On time and on budget are important, but not if you’re not driving business outcomes. Sometimes the best decision in reviewing the metrics is when to stop. I really like the advice of Daniel Rasmus where he proposed that stop doing lists are as important as to do lists. By collecting solid metrics about how each stage is doing, organization can quickly pivot and pursue different approaches.

There are no doubt hundreds of other pieces of advice for how to deliver successful Large IT Projects, so an exhaustive list here is probably not possible, but one last important element is communication. All organizations can benefit from a comprehensive communications program around the activities that they are looking to accomplish. Governments can benefit by proactively reporting the many small successes as a program progresses so, that when small setbacks occur, there is an established body of evidence around the due diligence and sound decision making that led to that point. Private sector organizations can benefit to keep their customers and shareholders confident in their offerings or business. I’ve been disappointed lately with how good version one products with a ton of innovation have been torpedoed through poor communications around their launch. Simple messages around the company’s long term commitment to the direction or that customers should feel confident that their provider will take care of them as they embark on the newer direction would go a long way to solidifying success and addressing a hostile media.

Organizations are successfully delivering IT projects to deliver innovation, increase productivity and ultimately become more prosperous. Fundamental to their success is not biting off more than they can chew to make sure that their project is just the right size to challenge the status quo while not overwhelming the operation. As you explore your next IT project, you need to ask yourself, “Is my IT project too large?”

Hearsay and Other Crimes against Innovation

John.Weigelt

Published: July 26, 2011Posted in: CIO Toolbox, Digital Economy, General

Innovation remains firmly at the top of mind of many leaders as they look to take their enterprises further, do more with less or otherwise transform their operations. Remember that innovation takes many forms and, as the Boston Consulting Group reminds us, can include:

New to the world products or services that create entirely new markets;
New offerings that allow expansion into new customer groups;
New offerings for existing customers;
Incremental changes to existing offerings; and
Lower production costs for existing offerings.

Unfortunately, people and organizations often resist the change that innovation brings. As change agents looking to adapt to the ever changing world we find ourselves in, be alert to these top enemies of innovation.

Hearsay: I find this the most frustrating of all the inhibitors of innovation. Myths are easily perpetuated and it seems fear, uncertainty and doubt (FUD) spreads like wildfire. Innovators often find that they have to think about all possible angles, address every conceivable risk and consider even the indirect stakeholders. Detractors only need to insert one unsubstantiated question or unresolved doubt to add additional roadblocks to delay or upset the initiative. In many cases the doubt has been introduced by restating popularized folklore, leaving the innovator to do the work to disprove the mythology.

Languor: This closely related relative to hearsay refers to the reluctance to do the work on the part of both the innovator as well as the detractors. Now that I’ve been tuned to some of the statistical tradecraft in the marketplace, I’ve been sure to dig a little deeper to get the full context or meaning behind what being reported. Unfortunately, I’m finding more and more people aren’t going the extra step to find what’s really going on. Perhaps it’s the pace of business that keeps people from doing their own validation, but this missed step is critically important to appreciate fact from fiction and properly inform the innovator’s agenda.

Unexercised Empowerment: How many times have you heard: “I can’t do that”, or “I’m not allowed”? It seems we’ve all been conditioned to respect authority to such an extent that we project a belief of constraints placed upon us from up on high. I’ve even found myself contemplating a veto of even a small activity because of some unconscious constraint along the lines of “that’s not how we do things”, or “that’s not your responsibility”, only to come to my senses and lend a helping hand. How often have you been at a team meeting to hear about some of the concerns of your teammates only to realize that the change was completely in their grasp, they simply needed to seize it.

Take a moment to think about the innovators that you know and the successes they’ve achieved. I’m sure that you’ll find that they are champions at fighting the crimes listed above.

Considering Compliance When Adopting Public Cloud Services

John.Weigelt

Published: June 16, 2011Posted in: CIO Toolbox, Cloud, General, Policy, Privacy, Security

Cloud computing processes and technologies offer organizations the opportunity to transform their approach to IT services delivery and ultimately transforming their overall services delivery. While several characteristics fundamental to cloud computing are relatively novel to these solutions (e.g. elasticity, transparent scalability, usage based billing) there are some aspects of cloud services, especially in procurement, that organizations will be familiar with. Many organizations are using public cloud services for their service delivery. While the path each has taken to implement cloud services has been different, there are some activities that they have commonly performed:

1. Select a candidate service (capability) that will provided – While many CIOs have included “moving towards cloud services” in their strategies, actual implementation of these services requires that CIOs and their service delivery leaders go well beyond the concept and take a detailed look at what services and information holdings they plan to host in the cloud. For existing services, organizations should take the time to examine how their user community is actually using the services over and above to the official purpose of the system in question. This will help identify any unexpected categories of information that need to be supported. Organizations should also take the time to think about and almost predict how their community may find alternate uses of new services that they are looking to deploy in the cloud. This will help avoid any unintended consequences.

2. Assess the compliance obligations for the service (PCI, FOIPPA, PHIPPA, SOX etc.) – The output from the first step should be a clear understanding of the services and information that will be transitioned to the cloud. Since all services are governed by legislation, policy or standards, it is essential that a fulsome analysis of the compliance obligations be carried out by a compliance team composed of a partnership between the service owner, legal and IT organizations. It is often the case that several compliance regimes will apply to an individual service.

3. Take a realistic look at how the organization conducts business today (Mobile devices, Internet presence, partner connections, POTs, social network use etc.) – While any change in how an organization delivers its services provides an opportunity for improvement and to address gaps that have arisen over time, a balance must be struck not to over-engineer the solution. Instead of taking a blank slate approach to delivering services via the cloud, successful deployments have taken a look at the current service delivery environment and examined the differences that the cloud services introduces. This approach effectively addresses arguments for security, privacy, availability etc. that deal with absolutes.

4. Conduct a preliminary Privacy Impact Assessment (PIA) and Threat Risk Assessment (TRA) – Now that a clearer understanding of the services has been developed; there is an opportunity to conduct preliminary TRA and PIA. These assessments identify the information assets, the threats to those assets, the safeguards required and provide an insight into the remaining risks that need to be addressed before the services are deployed. These preliminary reports go beyond technology based recommendations and will help identify policy, process, people and publication safeguards/controls for the services. Should the organization determine that the remaining risk of their planned deployment is too high, there is an opportunity to go back and revisit the approach and add additional safeguards. Organizations can also look to hybrid models where the sensitive information remains on premise and a less sensitive portion of the service is migrated to the cloud.

5. Pilot the service – The very nature of cloud services provide a great way to deliver new. Because you only pay for what you use, organizations can quickly and cost effectively get access to cloud services so that they can investigate how they could work with their plans. These pilots/prototypes can be done at the same time that the policy/compliance work is being done.

6. Assess the potential risk delta in moving to new cloud model. – The preliminary PIA and TRA provide the foundation for the business assessment for the adoption of cloud services. It should consider the current operational environment and the planned cloud end state. It is essential that the risk be considered in the context of the current ways that the services are performed since starting from a blank sheet or ideal world scenarios can introduce scope creep explosion which will extend far beyond the project in question.

7. Conduct a detailed review of the Service Level Agreement, including a mapping to current service levels. – The Service Level Agreement is the cornerstone safeguard for effective outsourced service provision since it describes the expectations and obligations of both the service provider and consumer. Several organizations have made the case for cloud services to their senior management based upon the service enhancements over their existing service delivery capabilities (e.g. availability, capacity, discoverability). Organizations should take the time to fully describe their service expectations and avoid sending poorly understood services to cloud providers. A sure recipe for failure is where a poorly understood service is tossed into the cloud since both parties won’t know what’s expected leading to discontent.

8. Build out the business case. – Successful deployment of any full service ultimately relies on a solid business case. While cloud services do have the potential for organic, bottom up growth because of usage based billing, fully sustainable solutions are supported by solid business cases. The biggest challenge experienced with business cases is accurately capturing the current total cost of ownership. Organizations generally underestimate the current costs because it is often difficult to get full access to the various direct and indirect costs associated with a service.

9. Decide and manage the risk – Ultimately the decision to maintain status quo, adjust a service or deliver a new service comes down to a risk management decision. All of the activities described above help develop the evidence for the line of business leader to make an informed risk decision.

Canadian organizations are beginning to take advantage of cloud services for their service delivery initiatives. Those that have been successful in deploying have generally performed these high level steps to tease out and address the risks and opportunities associated with their move to the cloud.

Publishing for Access

John.Weigelt

Published: January 5, 2011Posted in: Accessibility, CIO Toolbox, General

Let’s face it, when you’re authoring stuff you want your thoughts to reach the broadest audience possible. You want to make sure that your ideas get to your audience just as you intended without missing any valuable content. In short, you want your content to be accessible. Despite a variety of tools and guidelines, there are still too many materials on the web that are inaccessible across the diverse products that people use to connect to the information that they need.

If we think a little bit about the people we are trying to reach, we quickly realize that they access the web using smartphones, tablets, slates, video game consoles, televisions, notebooks, screen readers, braille displays and even desktop computers. Some authors might simply shrug and note that if someone can’t see their blog post on a portable device that their readers will come back to visit on their desktop at a later time. I have to disagree that readers will come back and more importantly suggest that there are a number of people that rely on a single way to access the stuff that you post. I’ve heard first hand of the frustration experienced when information is not accessible by people who rely upon specialized tools to use their computers.

There are some very easy ways to prevent the frustration.

1. Think about the different ways people might get at your information – Awareness is often the first step to making information accessible. So consider the individual reading your materials on the small screen of a phone or having the information read aloud by a screen reader. If you haven’t experienced the ease of access tools (e.g. Narrator, Magnifier, High Contrast, etc.) give them a try (just press the Windows key and “u”)

2. Appreciate the details –There are a few things that authors should consider when creating content that can be consumed across a variety of devices. Considerations such as providing textual descriptions of the images or making sure presentations build and flow correctly. A common gotcha is saving a document as an image file thereby losing the ability to have it narrated by a screen reader.

3. Consider the tools at your disposal – As with many other communications technologies, there are a number of techniques available to help you reach the broadest audience possible. Some of these techniques vary with the role that you might have; be it a software developer, a web designer or content creator. A common pitfall is to look narrowly at one approach, say a web only model, and inadvertently restrict other useful techniques (for example, downloadable content not generally covered by web techniques can easily be made accessible as well)

a. Developers – I know that this is a broad category with any number of interpretations. In this context I mean the community that builds tools that leverage technical specifications for protocols, document formats, markup languages, application programming interfaces etc. Developers have the responsibility to leverage the accessibility functionality in those protocols, APIs etc that they leverage in a consistent way. There is plenty of great advice out there for developers, including the advice found on MSDN.

b. Designers – Designers establish the frameworks or templates for content developers to contribute to atop the software applications created by developers. (Of course one person can have all three roles). Designers are responsible for establishing frameworks or structures that simplify publishing content that is accessible across a variety of different devices. Examples of considerations for designers can be found in the W3C recommendations for Cascading Style Sheets.

c. Content creators – Content creators are the largest community since, after all, don’t we all create content? Content creators are responsible for making sure that the information that they create includes the details needed to make it accessible across the wide array of devices and format in today’s computing and communications environment. Microsoft Office 2010 includes an accessibility checker for Word, Excel and PowerPoint to help everyone create documents that are accessible to everyone.

4. Test it – Once you have created your content and are ready to publish it or send it out, test it out to make sure that it is consumable using a wide variety of tools. This might mean grabbing one or two different devices to have a look, or it might require formalized certification or conformance checking against government standards such as the US Section 508 or the W3C Web Content Accessibility Guidelines. As with any compliance review, organizations should look beyond the checklists to ensure that they have provided meaningful access to their content.

I’m sure that you’ll agree that the awareness, understanding, create and review processes listed above fit well with the normal content creation process and so won’t unduly impinge on the regular day to day routine. Just some small extras that will help you reach the broadest audience possible, be they the person next to you on the plane reading their mail when their device should be safely stowed or that other person having it read aloud to them.