Tag: Shadow IT

  • DevOps Brings IT Out of the Shadows

    DevOps Brings IT Out of the Shadows

    One of the biggest threats to organizations today is shadow IT—unsanctioned and unknown technologies and applications being employed by maverick users. Shadow IT represents a security risk for your company—the IT department can’t defend and protect technologies and assets it doesn’t know about—and should be eliminated. One of the best defenses against shadow IT is DevOps.

    When I worked in the trenches as a one-man IT department—part network admin, part tech support—there always were one or two individuals who knew enough to be dangerous. As frustrating as it was to deal with completely clueless users who didn’t know the difference between the computer and the monitor and weren’t even really sure where the power button was, those who knew enough to go rogue and reconfigure their devices or introduce new applications and services were a more existential problem for the organization. In today’s era of BYOD and cloud services, shadow IT is a scourge significantly greater than what I faced.

    Don’t get me wrong—I’ve also been on the other side of that equation and I understand the motivation that drives shadow IT. Users just want to get their jobs done, and the people in the trenches know better than anyone what the hurdles are and how to fix them. Requesting new technologies or capabilities from IT is a cumbersome and tedious process at many organizations, so in the name of expediency users just do what they need to do on their own.

    DevOps can help solve the shadow IT problem in a better and more sustainable way, though. There are two benefits that DevOps brings to the table that minimize the potential for shadow IT: More rapid development and empowering individuals.

    First, an IT organization that has embraced DevOps will be quicker to respond to requests from users. Replacing the traditional software development life cycle with a more agile and continuous pace of development means that feature requests can be incorporated much faster.

    Second, one of the cornerstones of DevOps is the underlying culture—the breaking down of silos and removal of barriers and bureaucratic nonsense that get in the way of efficient progress. Essentially, those rogue technologies and applications that comprise shadow IT in other organizations are simply a part of the larger DevOps whole in an organization that has embraced DevOps. There is even a term ascribed to users outside of traditional IT/developer roles who develop solutions: “citizen developers.”

    The 2015 State of Citizen Development Report explains in more detail what a citizen developer is: “Citizen Developers are empowered problem-solvers from the various lines of business who have the drive and determination to engage in app development even though they lack traditional coding skills.”

    That isn’t to suggest that in a DevOps world everyone can just go set up virtual servers, or store data on personal cloud services and that it’s OK. It just means that when users are given the tools and freedom to develop solutions that have the blessing of IT and the rest of the organization, they don’t need to function in the shadows.

    Embracing DevOps and the citizen developer movement enables IT to work in harmony with users to develop solutions that work rather than fighting against each other and ending up with shadow IT servers, applications and cloud services that IT isn’t even aware of. Organizations that are concerned about the impact of shadow IT should look at ways to harness the power rather than just trying to ban shadow IT completely.

  • The Growth in Data Center Uses for Shadow IT

    The Growth in Data Center Uses for Shadow IT

    Shadow IT is casting a long shadow over IT departments as more organizations react to changing demands from their customers, partners and regulators. Groups and individuals outside of IT are taking matters into their own hands by tapping new cloud-based applications and hosted data centers.

    Shadow IT involves any purchase of equipment, software or data center resources for uses outside of production IT. These purchases usually fall outside the IT budget as well. In many ways, this trend effectively cedes the influence and control of CIOs and IT managers to others within their organizations. According to at least one bold estimate, shadow IT is set to make up 90% of all IT purchases by 2020.

    becoming faster and easier to acquire cloud resources that take longer to get with traditional IT processes. It’s therefore hard to hold back the growth of shadow IT. For example, a test engineer who needs some servers for performance testing. Or a product manager who needs some machines for internal training. Setting up a few AWS instances could take a matter of minutes – you just need a credit card. That seriously lowers the motivation to start requesting those resources from IT, explain why you need them, get approval, and then wait for manual allocation or completion of the purchasing process. As everything gets faster, online, and more automated, the line of business cannot afford to wait.

    Let’s examine the main uses of shadow IT to get a better understanding of what is happening.

    Uses Cases for Development and Testing

    Developers and test engineers are under huge pressure to be more agile. Even in organizations that we would never think of as “fast,” the pace changes rapidly. In heavier organizations that spent years establishing well-groomed IT processes, the dev/test consumer’s patience is running low. We are officially at a point where swiping a credit card and expensing an AWS instance has become easier than opening a ticket to request a virtual machine. As DevOps and automation cross borders and become mainstream, the need for speed makes Shadow IT thrive.

    Uses Cases for Sales Enablement

    Another line-of-business activity that’s implementing shadow IT involves the sales enablement process. This includes demos and proofs of concept, along with internal and external trainings, or customer support services.

    Until lately, most demos and proofs of concept were the responsibility of sales organizations, and such work was generally performed beyond the purview of IT. Now fewer companies are staging demos and proofs of concept at customer sites. They are adopting hosted data centers and web-based cloud services that customers and sales teams can access remotely through self-service.

    In recent years, many of these sales demos have been conducted at resellers and integrators, or by building a lab at a hosted data center where the infrastructure and software is housed.

    Uses Cases for Partner Enablement

    Shadow IT is also catching on for partner enablement to facilitate software development sandboxes, certifications, and testing of software-defined networks. Many industries depend on such product ecosystems for their long-term success. With software-defined infrastructure, the software can be easily integrated and controlled using outside tools.

    Most major hardware and software vendors are developing new partner labs. Members of the partner ecosystem can certify performance against the vendor’s equipment and interfaces without making big capital investments in the infrastructure themselves. Some examples include Cisco DevNet and Salesforce’s Force.com.

    Shadow IT Continues to Grow

    The organizations that adopt agility and DevOps are no longer the leanest and most cutting-edge. They can’t get away with a single Amazon instance. They need support for more complexity, more configurations and more context. They need to better mimic production, because more is at stake.

    As more lines-of-business in these organizations need to be faster, it’s becoming more challenging for IT to meet their needs with the Production IT toolbox – whether it is for development, testing, security certifications, demos or support.

    These kinds of use cases for shadow IT are on the rise, meaning shadow IT will continue to be a growth market for years to come. Whether or not shadow IT will consume 90% of all IT budgets remains to be seen, but it will definitely make up a significant portion of IT spending until production IT changes its approach.

    About the Author/Maya Ber Lerner

    image002Ber Lerner began her career with QualiSystems in 2007 and has steadily risen through the ranks in various roles starting as product manager, director of channel development, director of sales for APAC and Israel, senior director of international sales and, most recently, VP of sales, international. Ber Lerner holds a Bachelor’s degree with honors from Tel Aviv University in Biomedical Engineering.

  • Stop whining about shadow IT and do something about it

    Stop whining about shadow IT and do something about it

    Much has been written about shadow IT at the business unit and employee level where the proliferation of cloud applications has all but eliminated IT’s control over what applications are used in their organization. The explosion of public cloud technologies has caused an identical revolt amongst development teams who no longer want to—or need to—wait for IT to spin up the IT infrastructure needed to fuel their development efforts. The reality is public cloud has drastically changed the expectations of developers – even if they aren’t using it.

    Gone are the days where development teams are satisfied with putting in a help desk request for a new server and waiting to access it. Developers now expect IT to provide services similar to what they can get from a public cloud provider. And if you can’t provide it? Then you risk them pulling out a credit card and bypassing everything you’ve built. But just as shadow IT can wreak havoc on data security and IT budgets, there’s a whole new set of problems that can arise when shadow IT hits the infrastructure level. So now that the developers’ expectations for immediate resources have been changed irrevocably by public cloud, what can IT do to bridge the gap?

    Calling a truce: provide self-service provisioning and management

    First and foremost, the obvious one—give developers the immediate access to IT resources that they need to do their jobs. IT needs to leverage its existing investment in virtualization technologies by providing self-service provisioning and virtual machine management capabilities to developers. In other words, get out of the way and give them what they want.

    At the minimum, IT should be looking to setup an internal cloud management system which provides IT an on-premises solution with:

    •     Integration to existing authentication/authorization systems (e.g. Active Directory)
    •     Quotas to control usage by employee/group
    •     Chargeback/showback to provide usage tracking and accounting

    Giving back control is the best way to ease what can be a tenuous relationship between IT and developers. Developers will be happier because they will be provisioning new servers in minutes rather than days and IT can focus on more interesting challenges.

    Abstract away the complexity

    Self-service provisioning is only step one. IT needs to get out of the business of provisioning servers and let developers manage their virtual machines themselves. However, that doesn’t mean that IT should leave developers to manage every aspect of their cloud usage on their own. On the contrary, IT’s job should be to create the tools and infrastructure to ensure best practices within your organization and track IT infrastructure resources to avoid unnecessary infrastructure costs.

    But how? The first step is using a centralized automation and orchestration technology. I won’t get into the religious battle between the various flavors—Puppet, Chef and Ansible are the three most common that we see and they all have their strengths and weaknesses. However, they all provide the type of framework IT needs to empower self-service provisioning capabilities.

    IT should own the base OS images which developers can use for their virtual machines and use an automation framework to provide the means so that developers can easily set up a common set of framework applications (e.g. web servers, databases, monitoring tools, etc.).

    IT can also use cloud management tools to effectively track resources. We’ve seen many instances where customers have discovered numerous unused VMs. By tracking resources and enforcing expiration dates on certain resources, IT can deliver infrastructure more cost effectively.

    Give users choice

    Frankly not all clouds are created equal. And certainly not for all tasks. An internal VMWare virtualization may provide a great cloud—once IT has provided the services mentioned above—for most developer’s needs—but don’t stop there. For example, public clouds, like AWS, Azure, Google, have servers located all around the world.  That makes them ideal for web applications which are going to have geographically dispersed users. Most IT shops certainly shouldn’t be trying to duplicate that capability or prevent its usage. Embrace it instead, where appropriate!

    That doesn’t mean that IT shouldn’t have visibility and control into that usage. IT should strive to create a system which supports a collection of private and public clouds, has unified chargeback/showback and quotas across ALL of the private and public clouds that IT wants to support.

    Abstract Away the Complexity to Support Teams Beyond Developers

    These best practices shouldn’t be limited to developers! One of my favorite use cases that I have seen was an IT shop which provided their sales team with the capability to spin up VMs for product demos. They encapsulated the complexity of 10+ product variations and multiple operating system varieties into a single dialog box.  When the sales manager wanted to do a demo, they checked a couple of boxes in a dialog box, hit submit and a VM was spun up on their internal VMWare cloud which automatically expired 8 hours later. This was a perfect example of allowing a non-technical user to control of their own virtual machines while IT maintained complete control of the underlying technologies.

    Maintain flexibility!

    One final word of caution: the world of private and hybrid cloud is changing very rapidly. IT needs to be able to utilize their existing virtualization infrastructure, typically VMware, today while exploring new private cloud options like OpenStack and preparing for the future of containerization and micro-services.  It’s important to avoid solutions which are locked into a particular technology—which may leave IT behind in this rapidly changing environment.

    There is no doubt that public cloud has led developers to have drastically increased expectations for private IT. By putting in place a cloud management platform backed by DevOps server automation, IT can meet these expectations and stop the growth of shadow IT at the infrastructure level.

    About the Author/Jon Mittelhauser

    Jon Mittelhauser is the CEO of CloudBolt Software. A 20-year Silicon Valley veteran, Jon Mittelhauser has a proven track record of building highly regarded technology organizations from the ground up and helping to architect pioneering technologies. He is considered one of the founding fathers of the World Wide Web. He was co-author of the first widely-used Web browser, NCSA Mosaic, and was a founding engineer of Netscape Communications Corporation.  Mittelhauser was an early investor in Tesla Motors and one of the first Tesla Roadster owner.

  • Beyond the Darkness of Shadow IT

    Beyond the Darkness of Shadow IT

    The concept of consumerization of IT, Bring Your Own Everything (BYOx) and self-service technologies has amplified the amount of ‘Shadow IT’ in development shops. Developers can procure, setup, and start using new components, and developer tools in hours. This is a trend that lurks in the dark. C-suite executives can either ban the trend altogether to stay on the safe side, or venture into new waters and embrace innovations that open doors to unforeseen opportunities, efficiencies and productivity standards.

    (more…)

  • To Be or Not to Be – Shadow IT

    To Be or Not to Be – Shadow IT

    Is it being an innovator, or demonizing business decisions to use other vehicles, and cry foul?

    Sun Tzu, the famous Chinese strategist and philosopher, once said, “If ignorant both of your enemy and yourself, you are certain to be in peril.” These words ring true to the quandary that traditional IT organizations find themselves in today: on one side, hordes of tech-savvy business users are deploying and engaging technology services at an alarming rate, often without any input or validation by the IT team. On the other side, there’s an aging on-premise infrastructure that requires frequent care and stresses the limited resources and budgets of IT staff. In between, sits a group of technology professionals that want to support their users while maintaining the appropriate level of compliance, risk management and security — fondly known as “Traditional IT”.

    Security teams, a part of traditional IT organizations, have begun demonizing any non-sanctioned technology use – dubbing it “Shadow IT – taking a somewhat close-minded view as to how software and services are being procured and utilized in today’s organizations. In the legacy world, IT Security could block or veto projects based on its merit and risk. Business teams had no choice but to work within their constraints, as the security teams controlled the firewalls — the proverbial gates to the kingdom. Nothing entered or left the organization without being blessed through the firewall, which left IT Security in a very advantageous position. Fast-forward to today and we see a drastically different dynamic taking place in organizations: DevOps and business teams are driving buying decisions, or making them without IT approval.

    Why is this happening?

    If you look at how various teams are structured in most organizations it becomes obvious. IT departments, a legacy construct best suited for organizations with few technology-savvy users, are best suited with a role as a service provider. Meaning, they build infrastructure, deploy software and services, and operate utilities as a service to their user base. This could be users in the form of bankers, call center employees, or even software engineers. There is no minimum or maximum level of technology expertise required on behalf of the user, because the IT department is there to offer support and guidance as necessary. This is very much a “thou shall not use technology not provided by IT” point-of-view, because IT is ultimately responsible for the support and user experience of said technology.

    However, IT departments are fundamentally based around annual budget cycles and 3 to 5 year amortizations of capital expenditures (servers, network equipment, etc.). As the quality and variety of software, hardware and SaaS solutions has increased ten-fold over previous decades, we have quickly entered a buyer’s world where multiple satisfactory solutions can be obtained quickly. This is counter to the traditional IT pattern of planning purchases in advance, leaving ample time for procurement haggling. In as little as a year, entire service providers can spring up with scalable, resilient, superior technology solutions — often affectionately referred to as disruptors. These disruptive technology companies move fast, gather feedback from their customers, improve their product/service and deliver new products. If you just spent a million dollars on servers that you plan on keeping for the next three years, it is nearly impossible to justify leveraging a fleet of cloud servers as an alternative just a few months later. The cloud servers could be the right solution for your business — but the pain of wasted capital is too great for most organizations to shake, much less the implied defeat or mistake in judgment by IT management.

    DevOps teams, on the other hand – and much to the chagrin of IT and InfoSec teams, thrive in the chaos of moving quickly and breaking from tradition. This is not done maliciously, but rather out of necessity to reach a peculiar and demanding audience. Years of “buy it now” instant gratification have conditioned the end-user to expect fast, high-quality and competitively priced products. This holds true for the Internet generation now responsible for the buying decisions of everything from inexpensive productivity tools to enterprise-grade communications solutions. Decisions are not made solely on who can deliver the highest SLA or who had the best benchmark score. Agile teams now look for the best product fit, defined by a set of conditions ranging from automation integrations to direction and vision of the vendor. This wide range of criteria falls well outside the traditional IT buying spectrum, and thumbs its nose at the legacy buying practices. DevOps teams buy subscriptions to services that they can change or cancel at any time. They procure products that don’t even have user interfaces beyond an API and JSON output. They buy based on “what can we do with this” rather than “what can this do for me”, which is reminiscent of maker culture.

    A new breed of tools that enable the DevOps teams to do great things while catering to the IT Security team has emerged. DevOps teams tend not to budget for security, and are often too fast moving to build all the requisite capabilities themselves. IT Security is desperate for a place at the table to ensure the safety and security of organizations and its users. This sets the stage for new, emerging technology companies to capitalize on the widening gap that has occurred as the industry shifts from the traditional datacenter model to one of private, hybrid and public clouds. This means no more 3-5 year investments in a security technology and no 3-5 year guaranteed relationship for security vendors.  Emerging companies also have to raise their game to meet the needs of these organizations and prove to be the partner of choice. The uptake to date has been slower as the industry has been slow to detect and understand this shift. Many organizations have legacy investments and don’t want to bring additional complexity to their lives by adding new panes of glass. DevOps teams may directly integrate raw data feeds from new products into their toolkit, but IT teams need solid integrations to existing infrastructure to make the best use of these new products. Without this, they can’t keep pace with the rapid deployments and changes made by DevOps teams, and are left nearly blind to the dynamism of their infrastructure risk and security posture.

    So what is the solution?

    It’s simple. By integrating security more deeply into the DevOps toolchain, and operationalizing security practices the same way we operationalize infrastructure and code issues. This means there is a space to not only bring cloud-centric data down to the legacy investments through connectors and integrations, but also an opportunity for IT Security to enable DevOps by automating common security practices. If the practices and behaviors of Security teams were operating at or beyond the pace at which DevOps teams deploy, then a collaborative environment can be built with security detection, notifications, and even mitigations act as a “safety net” in agile environments. This makes a lot of sense when you realize that the biggest threat to these agile organizations is not malicious hackers or state-sponsored attacks, but rather human error, policy failure, lack of transparency into security practices, and lack of consistency over time.


    About the Author/Tim Prendergast

    evident-headshot200X200With well over two decades of experience pushing the limits of technology, Tim set out to create the first “next-generation” security company, Evident.io, focused solely on programmatic infrastructures (cloud). Tim co-founded Evident.io to help others avoid the pain he endured when helping Adobe adopt the cloud at a massive level.

    Tim’s prior experience includes leading technology teams at Adobe, Ingenuity, Ticketmaster, and McAfee. He holds over 15 years of security experience; 8 years of AWS security experience, with 3 of them defending the Adobe AWS infrastructure from inception to production as an AWS Certified Solutions Architect.

    Connect with Tim: LinkedIN | Twitter | Evident.io