Technology Easy Sell

Benefits and Risks
Technology is not like buying a time share, thank G-d. 



We examine the costs and the benefits, and it either works and provides us a tangible competitive benefit or it doesn’t.



“You can’t be competitive without modern technology, you’ll simply be out of business.”



At the end of the day, you don’t want to be sold a worthless bag of goods from a no good (not genuine) salesperson. 



Read about it here in my new article in Public CIO. 



(Source Photo: Andy Blumenthal)

>A Turning Point for the Government Cloud

>








Los Angeles is moving to the cloud, according to Public CIO Magazine March 2010, and “they are the first government of its scale to chose Gmail for the enterprise.”

“It turned out that Washington D.C., was using Gmail for disaster recovery and giving employees the option to use it as their primary e-mail.” But LA is implementing Gmail for more than 30,000 city employees (including police and fire departments) as well as planning to move to Google Apps productivity suite for everything from “calendar, word processing, document collaboration, Web site support, video and chat capabilities, data archiving, disaster recovery and virus protection. “

CTO Randi Levin is leading the charge on the move to cloud computing, and is taking on concerns about cost, data rights, and security.

  • On Cost: “The city estimated $5.5 million in hard savings form the Google adoption, and an additional $20 million savings in soft costs due to factors like better productivity.”
  • On Data Rights: Nondisclosure agreement with Google includes that the data belong to the city “in perpetuity,” so “if the city wants to switch to another vendor after the contract ends, the city will be able to recall its archived data.”
  • On Security: “Google is building a segregated ‘government cloud,” which will be located on the continental U.S. and the exact location will remain unknown to those outside Google. The data will be “sharded”—“shredded into multiple pieces and stored on different servers. Finally, Google will be responsible for “unlimited” damages if there’s a breach of their servers.

LA conducted an request for proposal for software-as-a-service (SaaS) or a hosted solution and received responses for 10 vendors including Google, Microsoft, and Yahoo. Google was selected by an Intradepartmental group of IT managers and a five year contract issued for $17 million.

Currently (since January), LA is conducting a Gmail pilot with about 10% of its city employees, and implementation for the city is slated for mid-June.

Additionally, LA is looking into the possibility of either outsourcing or putting under public-private partnership the city’s servers.

And the interest in government cloud isn’t limited to LA; it is catching on with Google Apps pilots or implementations in places like Orlando, Florida and within 12 federal agencies.

Everyone is afraid to be the first in with a major cloud computing implementation, but LA is moving out and setting the standard that we will all soon be following. It’s not about Google per se, but about realizing the efficiencies and productivity enhancement that cloud computing provides.

>Comments from OMB’s Chief Architect: Kshemendra Paul

>Recently, Kshemendra Paul, Chief Enterprise Architect, at the President’s Office of Management and Budget (OMB) made the following critical comments to me about business cases and pilots and incorporating these in the Systems Development Life Cycle:

“I was online and came across your site –
http://usercentricea.blogspot.com/2007/08/system-development-life-cycle-and.html.

I had two comments I wanted to share. First, I would recommend you highlight a business case step, a formal decision to move out of select/conceptual planning and into control. While this is implied, it is such a crucial step and we don’t do it well – meaning that we don’t force programs to work through all of the kinks in terms of putting forward a real business case (tied to strong performance architecture).

Also, this is a step that is inevitably cross boundary – either on the mission side and for sure on the funding side.

Second, I’d like to see more emphasis on smaller scale rollout or piloting. The goal of which is to prove the original business case in a limited setting. Nothing goes as planned, so another objective is to have real world data to refine the over all plan.”

I completely agree with Kshemendra on the need to develop business cases and do them well for all new initiatives.

Organizations, all too often, in their zeal to get out new technologies, either skip this step altogether or do it as a “paper” (i.e. compliance) exercise. Symbolic, but wholly without intent to do due diligence and thus, without any genuine value.

Therefore, whenever we plan for new IT, we must ensure strategic business alignment, return on investment, and risk mitigation by developing and properly vetting business cases through the Enterprise Architecture and Investment Review Boards.

It’s great to want to move quickly, get ahead of the pack, and gain competitive advantage by deploying new technologies quickly, but we risk doing more harm than good, by acting rashly and without adequately thinking through and documenting the proposed investment, and vetting it with the breadth and depth of organizational leadership and subject matter experts.

Secondly, as to Kshemendra’s point on doing pilots to prove out the business case. This is an important part of proofing new ideas and technologies, before fully committing and investing. It’s a critical element in protecting the enterprise from errant IT investments in unproven technologies, immature business plans, and the lack of ability to execute.

Pilots should be incorporated along with concept of operations, proof of concepts, and prototypes in rolling out new IT. (See my blog http://usercentricea.blogspot.com/2007/08/conops-proof-of-concepts-prototypes.html)

With both business cases and pilots for new IT projects, it’s a clear case of “look before you leap.” This is good business and good IT!

>CONOPS, Proof of Concepts, Prototypes, Pilots, and Enterprise Architecture

>

User-centric EA seeks to implement successful IT governance for the enterprise. As such, it seeks to ensure that new systems not only meet users’ requirements, but also that organizational investments in new IT are successful.

There are a number of ways to phase in a new system to help ensure its success for the organization.

By first developing a clear definition of capabilities (CONOPS), and moving from proof of concept to prototype and to pilot, risk is mitigated on new system implementations and more systems are successfully brought to fruition. This phased systems development approach helps User-centric EA meets it target architecture and transition plan for the organization.

  • Concept of Operations (CONOPS)—evolves from a concept and is a description of how a set of capabilities may be employed to achieve desired objectives or a particular end state for a specific scenario.”
  • Proof of Concepta partial solution to a problem intended to prove the viability of the concept. A proof of concept may involve a small number of users acting in a business (non-IT) role using the system to establish that it satisfies some aspect of the requirements for the complete solution. The proof of concept is usually considered a milestone on the way of a fully functioning prototype.
  • Prototype—an original instance of some thing serving as a typical example for other things of the same category. A prototype is built to test the function and feel of the new design before starting production of a product.
  • Pilot—an initial roll out of a system into production targeting a limited scope of the intended final solution. The scope may be limited by the number of users which can access the system or by the business categories affected or the business partners involved or other restrictions as appropriate to the domain. The intent of a pilot project is to validate that the system is working in production as designed and limiting the business exposure if it is not.”

Note: Definitions of proof of concept, prototype, and pilot project were adapted from Wikipedia. The Definition for CONOPS was adapted from Navy Warfare Development Command (public website).