Making employees buy their own IT tools sounds like a crazy idea.  Thirty years ago, IT systems were so expensive that most access was through a dumb terminal, which was essentially nothing more than a session screen that allowed you to type in commands that were sent to the computer.   The computer was of course housed in some data center attended by tens of administrators day and night.  Then the PC – remember it is not called the Personal Computer for nothing — revolution of the 1990’s shifted the paradigm again, so that each user had their own software on their own system.  The corporate systems were still accessed through special terminal emulation software, but Microsoft got fat on selling millions of Windows and Office licenses to their enterprise customers.

Over the past 40 years nobody has questioned the wisdom of having a company purchase and control the hardware and software that employees use to do their jobs.  The wide availability and acceptance of consumer devices is opening up the opportunity of resetting the equation again.  It is not only possible, but there are many benefits from taking this approach.  There are precedents in the construction industry.  Most construction workers are expected to bring their own tools.  It makes perfect sense when working with dangerous equipment.  You want to be completely comfortable with the tools so you can focus on doing your job well.  This even extends into the engineering and architectural professions; I have a complete set of drafting tools from my years as a Registered Architect.

From the enterprise perspective, support costs can be substantially reduced.  Keeping track of thousands of devices is a known exercise in futility.  A major broadcasting organization finally paid for an inventory of their workers’ systems a few years ago and found an extra 3000 undocumented systems in the organization.  Another company had a “don’t ask, don’t tell” policy about employee owned devices and now has to semi-support about 11,000 of them.

From the employees’ perspective, using a single device that is used for both home and work, means eliminating nerd belt syndrome – two or more devices hanging from their waist or taking up space in carrying bags.  There is nothing worse than hearing a ring from one of the devices and trying to figure out which one needs to be answered!

Rather than attempting to halt the demand, the smarter path is to embrace BYOD’s by providing a safe and secure framework for their use.  This framework should have two complementary components: a BYOD policy and the technology framework and administration software to enforce it.  An official corporate BYOD policy would not be dissimilar to the corporate security policy.  To make it easier, some companies just incorporate their BYOD device policies directly into their standard security policy that all employees are expected to adhere to.  The key to successful enforcement is the implementation of the proper MDM software.

About the Author

Beth Cohen, Cloud Technology Partners, Inc.  Transforming Businesses with Cloud Solutions

The growing IT best practices consensus is that creating enterprise clouds are smart money for corporations.  Private cloud infrastructures empower user with self-service portals, stable application building platforms, and flexible service delivery models.  In addition, warming the hearts of corporate bean counters around the world, enterprise clouds can save significant amounts of money by maximizing utilization rates of expensive data center systems.  Cloud nirvana is achievable; there are plenty of successful case studies around proving the value.  However, for many senior IT executives just a review of the corporate IT portfolio is a daunting task, let alone systematically determining which applications should move to the cloud, then figuring out the best way to achieve that goal.

The sorry reality is that no matter how well disciplined a company is about its IT governance, the average enterprise has 20 plus years of legacy applications in its portfolio that it needs to manage.  Over time, even the best run company will acquire what one of my co-workers affectionately refers to as, glops and legacy linguini.  We all know the recipe; start with a couple of semi-successful enterprise application implementations (the kind where the company is using both the old and the new systems and cannot shut down either), throw in a few mergers and acquisitions (include a handful of management regime changes and reorganizations just to spice things up a bit), then stir in thousands of undocumented patches, temporary fixes that turn permanent and shadow IT applications.  Bake until solidified into an impenetrable morass of siloed functions and tangled application inter-dependencies.

Fortunately, there are some emerging tools, methodologies and best practices that can cut through layers of ossified applications, and offer real actionable guidance on the right approach to moving an enterprise application portfolio to the cloud.  If you are seriously considering adding a private cloud to your IT portfolio, here are just a few questions to ask about your portfolio to get started:

• How ready are the applications for migration to the cloud? – There are tools available that can drill down within each application to determine the exact amount of effort it will take to make it cloud ready.
• Would moving the applications be operationally disruptive? – Again, an organizational cloud readiness skills assessment provides guidance to how the IT organization needs to change to meet the different requirements of managing an enterprise cloud.
• Are they built on x86 based Windows or Linux platforms or are they Solaris, HP-UX or some other more exotic platform? — Only a few years ago I ran into an ERP system that was still running on a Data General platform. A rewrite of the application was a foregone conclusion in that case.
• How much of the existing portfolio is already virtualized? – Virtualization is not cloud (a common mistake), but being virtualized makes moving to the cloud that much easier. The average enterprise is typically only 30% virtualized.
• Can the application be replaced by existing SaaS applications that offer similar functionality at a fraction of the cost? — Cloud email, document management and supply chain applications for all except the most unique circumstances are far superior to the legacy systems they are replacing.

From the inside undertaking an enterprise cloud project might seem hopeless, but these types of situations are where bringing in outside experts with real expertise in cloud infrastructures and application transformations can really pay off.  I can tell you from hard earned personal experience, we have seen it before and whatever mess your portfolio is in, others were far worse and they successfully moved their portfolios to the cloud.

About the Author

Beth Cohen, Cloud Technology Partners, Inc.  Moving companies’ IT services into the cloud the right way, the first time!

Now that businesses are convinced that they should be moving at least some of their applications and systems to the Cloud, the next hurdle is determining not only how to migrate applications into the cloud, but more importantly, what types of functions to move.  There are some obvious answers, such as test/development, but best practices and standards are still emerging as companies continue to struggle with the definitions and the complexities of available Cloud services.  That process will continue for another few years.  In the meantime, some basic principles can be applied to any IT portfolio Cloud readiness assessment.  By focusing first on a review of the internal applications portfolio, rather than the available Cloud technology valuable insights can be gained about the right Cloud migration approach for your business.

At the 50,000 foot level, any organization needs to evaluate its existing IT portfolio and suitability for the Cloud in context of the organization using the following four criteria:

• Business – TCO (Total Cost of Ownership), ROI (Return on Investment) value to the organization
• Operations – Business processes and efficiency
• Technical – Maturity and ease of adoption
• Security – Access control, regulations, legal, risks and exposure

Business value and objectives should be the primary factor to apply, followed by the others as appropriate.  The relative priority of the other components is going to be driven by the specific industry requirements and organizational business model.  For example, a defense contractor is going to be far more concerned with security, then a manufacturing company, while a logistics company will focus on operational efficiency and partner integration.

These criteria can be further broken down into sub-categories and developed into standardized evaluation matrices and checklists for the Cloud decision.  To obtain a more meaningful outcome, evaluate a spectrum of applications, rather than looking at each application independently.  This common mistake often results in disjointed Cloud policies and SaaS island hotspots in the organization.  Even in a large enterprise with thousands of applications, looking at a sampling of just a few hundred applications can supply valuable governance and perspective to any transformational Cloud project.  By determining the internal IT portfolio priorities, the direction of how Cloud architectures fit into the overall IT strategy for the company.

Once the applications have been mapped against these criteria and a prioritized list of projects created, only then is it time to delve into a discussion about appropriate types of Cloud architectures.  As with anything in the business world, there are quite a few checklists available on the web. Unfortunately, the ones I have seen so far have been difficult to customize, far too complex and hard to customize.  Smart IT executives would benefit from using the services of a Cloud consulting company to help sort through the hype and create customized criteria.

About the Author

Beth Cohen, Cloud Technology Partners, Inc.  Moving companies’ IT services into the cloud the right way, the first time!

Forrester forecasts the SaaS global market will grow from $25.5 billion in 2011 to $159.3 billion in 2020.  With those numbers, there is no question that SaaS applications in the enterprise are here to stay.  The plethora of new SaaS (Software as a Service) offerings can be extremely tempting to business managers who are told they can have a functioning system in just a few days, not the three months that IT is promising.  Of course the reality is quite different, but the biggest challenge is that since business unit decision makers, not technology leaders, are bringing these applications into the enterprise, they do not have a clear understanding of where they fit in the enterprise big picture.  It is not uncommon to find an enterprise that already has a well established and functioning corporate CRM system, has two, three or more rogue SaaS CRM applications lurking out in different marketing or sales departments throughout the organization.

Handled correctly within the IT framework, SaaS applications can significantly increase agility and competitiveness.  However, like any powerful tool, handled incorrectly they can be a ticking time bomb.    While there is nothing inherently wrong with having SaaS applications out at the edges of the organization, having multiple stealth application outside of the control of IT is at the very least inefficient and at the worse represent a serious threat to the security of the organization as a whole.  The main issues boil down to the usual suspects:  business, technical, operational and security (which includes data integrity).  The following are some of the common problems encountered with “ad hoc” SaaS implementations:

• Technical Issues
  • One off” data models that are inconsistent with enterprise standards
  • Poor or missing integration with existing enterprise applications
• Business Issues
  • Contract issues related to SaaS applications that didn’t deliver the promised functionality
  • Poor performance and SLA issues related to up-time, data loss, or service requests
  • Vendor lock in, application, data and/or contract
• Operational Issues
  • Lack of appropriate DR/BC functionality
  • Unclear ownership of support or lack of internal, third party and vendor support services
• Security Issues
  • Privacy, Security problems, access management, information security, and compliance
  • Unclear or missing Identity Access Management (IAM) – No SSO strategy or federated ID management system in place

The headaches caused by these rogue applications can be endless, but the trick is to first learn what the scope of the problem is.  Once it is clear how many SaaS applications are out there, the next step is to spend some time to understand what is driving the business units to install them in the first place.  In some ways that is half the battle, because once that has been determined, then the final step is to develop a SaaS governance process to allow business units to leverage the value of the SaaS approach, but also maintain the integration and oversight that staying under the IT organizational umbrella brings.

About the Author

Beth Cohen, Cloud Technology Partners, Inc. Moving companies’ IT services into the cloud the right way, the first time!