devopsy.kinsta.cloud

Tag: Shadow IT

  • 5 Steps to Avoid Shadow IT Around Low-Code

    5 Steps to Avoid Shadow IT Around Low-Code

    Shadow IT is far more pervasive than most CIOs think. Cisco Systems estimates that a typical firm has 15 to 22 times more cloud applications than authorized by the IT department.

    While shadow IT solves problems in the short-term for a select few, undocumented software ultimately encourages tribal thinking and siloed departments. This can stunt reusability, slow down new developer onboarding and lead to insecure points of failure—all antitheses to a DevOps culture.

    Simultaneously, new low-code tools are emerging that promise to reduce the programming burden from developers and enable citizen developers to create business applications on their own. But what happens when advanced users know better? Perhaps they’d rather code a quick function in Python or use another framework they’re more familiar with. If not properly governed, low-code platforms could easily be circumvented and lead to shadow IT.

    As many tech leaders can attest to, enforcing companywide standards can be tricky. I recently chatted with Jay Jamison of Quick Base to see what tactics organizations should take to avoid shadow IT when introducing low-code tooling. Here are five general tips CIOs can apply to reap low-code benefits while curbing shadow IT.

    1. Earn Developer Trust

    Focus on integration and open backends to earn developer respect

    Want to win the hearts of developers? Focus on integration. Many engineers don’t care about a shiny user interface and would rather interact with data models programmatically. As I’ve covered before, open API access is the secret sauce for low-code platforms.

    Choose a low-code platform that provides high-performant and secure RESTful APIs that use JSON. With open access to data models and low-level mechanics, advanced developers will feel less inclined to subvert the platform. What’s great about HTTP APIs is that they’re agnostic, so developers can interact with them from whatever language or environment they’re comfortable with.

    2. Govern and Set Permissions

    Establish access management policies with fine-grained permissions

    To avoid the emergence of shadow IT, software leaders must apply governance over data models, users and application privileges. These permissions should be fine-grained, to the field level. To do so, managers require an application lifecycle management functionality to edit these permissions. Such a governance layer would grant “tremendous power and control to IT and the business,” said Jamison.

    On low-code governance patterns, Jamison notices companies often lean toward one of two extremes:

    1. IT-centric: IT is leading the software models and only IT users can make changes.
    2. Operation-centric: IT acts as a governance body and building is pushed into business domains.

    Selecting which model to use is often based on the organizational culture and individual team member capabilities, noted Jamison.

    3. Encourage Collaboration and Knowledge-Sharing

    Build an easy path from mock-up to production

    Companies adopt low-code tools because they require something “quick and adaptable.” Yet, getting different operating teams at the same table can be difficult. Without high-quality collaboration, low-code could introduce a bottleneck.

    “Many teams must come together,” Jamison said. “How will this be productized; how will the workflow be tracked?” Companies truly require an effective collaboration model if they are ever to regularize their data models and assign access roles.

    To get everyone on the same page, Jamison recommended starting with a mock-up everyone can use as a reference: “Create an online chart to map out workflows and stitch it together in a collaboration space.” Business strategies can create detailed plans, and then builders can transform this into a prototype.

    4. Document and Reuse

    Encourage departments to document processes and expose reusable tools

    If users are sharing documentation via Excel and email, you know something’s wrong. Undocumented software is unmanageable software. Jamison reinforced the need for a “control layer” to localize documentation and encourage platform-wide governance standards.

    “Like buildings in a cityscape, some apps are more significant than others,” Jamison said. CRM applications may be entirely purpose-built for niche settings, while others, such as a team registry application, could be reused across an entire corporation. Increasing tooling reusability, he noted, requires teaching and training of documentation and change management practices.

    5. Adopt a Platform-Based View

    Standardize on a single platform and embrace a low-code culture

    The more teams use low-code, the more they think on low-code terms. As teams become more proficient in low-code, their mindset becomes: “How can low-code solve that problem?”

    By adopting a platform-based view, low-code becomes a utility to drive consistent data flows and workflows. To achieve this, it’s probably best to standardize around a single, companywide low-code platform. Otherwise, you risk inviting more unstandardized practices.

    For example, Jamison described how a large-scale manufacturer operating hundreds of plants worldwide uses a low-code platform to audit all plants’ quality in real-time. Other traditional non-IT businesses with a global footprint could similarly return a net value from consolidation on a single low-code platform.

    Will Low-Code Increase Shadow IT?

    It’s difficult to enforce any new tool, and some users will inevitably circumvent standard processes. However, by demonstrating the benefits of shared collaboration and low-code creative potential, leaders could stem shadow IT and the adverse side effects therein.

    By talking their language and saving time, low-code tools could win developer faith and encourage platform use. In review, here are some other ways to avoid shadow IT side-stepping around low-code:

    • Show some-code: Win developer’s hearts by talking on their terms and opening up the hood.
    • Govern: Use a common data model and apply fine-grained security constraints.
    • Ignite discussion: Bring groups together for open knowledge forums.
    • Unite business and IT: Enable citizen developers to design mockups and builders to execute quickly.
    • Use the platform: With more low-code use comes more creative sparks.

    Ultimately, low-code won’t replace 100% of your programming needs (especially at software-oriented companies). Low-code should be viewed as a time-saver, not a talent replacer, Jamison said. Low-code enables developers to quickly assemble simple business applications, freeing them to devote more time to core competencies or advanced processes that are far more interesting, such as building machine learning models.

    Final Thoughts on Low-Code Transformation

    There are many forces driving the current low-code revolution. Major tech hubs lack developer talent and COVID-19 has accelerated digital disruption. In this economy, requirements for business processes are changing “by the hour,” said Jamison. “The awareness around low-code is increasing because the need for automation and more digital solutions is increasing.”

    As Jamison noted, many enterprises are undergoing a “dual-track digital transformation.” Companies are investing in expensive, broad-scope cloud technologies while still digitizing many manual processes. To Jamison, low-code is now imperative to meet both needs. Thus, it should be adopted with forethought for all potential use cases (and shadowy non-uses).

  • DevOps Chats: Shadow Code Security with PerimeterX

    DevOps Chats: Shadow Code Security with PerimeterX

    When the cloud first caught on, there was a problem with Shadow IT—developers spinning up instances in AWS without the IT team knowing they existed. Now with the ease of CI/DC automated deployments, the problem of Shadow Code—code being added to apps that did not go through the entire team process—has arisen.

    In this DevOps Chats we speak with Elad Koren, VP of product at PerimeterX, about the Shadow Code issue and how his company can help.

    As usual, the streaming audio is immediately below, followed by the transcript of our conversation.

    Transcript

    Alan Shimel: Hey, everyone, this is Alan Shimel, and you’re listening to DevOps Chats. Today’s DevOps Chats features Elad Koren, who is VP of product at PerimeterX, and Elad, welcome to DevOps Chats.

    Elad Koren: Thanks, Alan. It’s an honor being here. Happy to join you.

    Shimel: I appreciate you being here, and it’s our honor to have you. So, Elad, we’ve never—I don’t believe so—we’ve never interviewed or covered PerimeterX before on Security Boulevard or DevOps. And why don’t we start with, why don’t you give our audience a little background—what’s PerimeterX about?

    Koren: Cool. I believe you’re right. PerimeterX has been around for a bit more than five years, and its main goal is to secure businesses, digital businesses across the web. It can be e-commerce, SaaS, and other online businesses, essentially providing solutions to the online digital challenges they have.

    We started with our Bot Defender solution about four years ago, and this targets the bot problem around the web. I’m sure you’re well aware of it, being the security professional you are. About a year ago, we’ve also launched our Code Defender product, which looks at the client-side code and highlights vulnerabilities and issues around that. And we will, of course, develop some more in the future as part of our growth plans to continue in securing digital businesses around the world.

    Shimel: Excellent. So, we’re gonna dive into that in just a second, but Elad, I also always like to ask people about their own personal journey. How did you come to be VP of Products at PerimeterX?

    Koren: Wow. [Laughter] It was a long journey. I’m actually, I’ve actually been in security for more than 15 years. I started with the Israeli Intelligence and the IDF. Then moved to my startup where I took all the security and kind of compliance and fraud areas. From there, I moved on to RSA Security, so you’re probably familiar with RSA Security, now part of Dell. And after a short period in Payoneer as their Head of Compliance and Security, I found myself in PerimeterX, leading the product group and now the VP of Product. I’m very proud of what we do with really, a sense of accomplishment with what we’ve been doing so far.

    Shimel: Excellent. Well, RSA Security was spun out of Dell now, right? Didn’t they do a PE deal a couple months ago, I thought?

    Koren: Yeah, yeah, they had a discussion around that. It was actually interesting because RSA was one of the biggest assets EMC had before Dell acquired them. And once Dell stepped in, I think RSA wasn’t that interesting for them, so it was only a matter of time.

    Shimel: Yeah, no, Dell seems to have a love/hate relationship with the security companies they acquire, but that’s for another podcast. Let’s stick to PerimeterX. [Laughter]

    So, client-side code inspections and security—talk to us a little bit about what you’re doing there and then I wanna jump into this concept of shadow code that we spoke about off-mic.

    Koren: Yeah. So, first of all, very important to understand, you know, the first question that comes to mind is, why are we talking about it on devopsy.kinsta.cloud. So, one of PerimeterX’s top targets is to assist DevOps teams to do their job better. And the fact of the matter is that, after we’ve had our bot mitigation solution for quite a while and DevOps was one of our personas, we went out and asked our customers, what’s their next major problem.

    And one of the things that came up for many, many customers was the fact that they have a challenge around their client side, okay? Developers are adding libraries—well, you know, it’s a common practice. However, some of these libraries, JavaScript or others, they’re not that secure, and they’re not that trustworthy. What we did at that point is kind of think of that problem and what it reminded of. And it kind of reminded us of the problem of the shadow IT that we’ve seen about 10 years ago or so, where employees would just come with their devices or do whatever they want with their bring your own device kind of concept, and companies started fighting that. But at the end of the day, they understood that they have no weight.

    It’s kind of similar with code. Developers will find the best weight to add code, even if it’s a library that they can just take and adjust slightly, and even if it’s a GitHub repository that no one maintains, and these introduce significant risk.

    Shimel: Yeah. Absolutely. You know, it’s interesting, I think no one in DevOps questions anymore when we talk about adding security to the mix. I mean, thank God. You know, a little bit of my own personal journey, right? The reason I got into DevOps is because I thought it was the greatest thing for security. I thought this, the way it came down that this whole DevSecOps movement and shifting left and making developers more aware of security—I envisioned that when I first found out about DevOps. And I was hoping it would give us another chance to do it right, to correct some of the mistakes that were kind of inherent in our whole model.

    And I’m not saying it’s a panacea or it’s perfect now, but certainly, we can acknowledge that developers do care about—no one wants to develop insecure or crappy code. People have pride in what code they develop. Now, when they didn’t know—the more they know about security and the more tools we can give them that allow them to kind of do better, develop more secure code, the better off we are, I think.

    But this issue of, as you’re calling it, shadow code, right, kinda growing ________ with shadow IT when the cloud first came.

    Koren: Yeah.

    Shimel: It’s a problem. And the thing about it is, again, developers don’t raise their hand and say, “I wanna sneak around. I wanna sneak a little code in the back door.”

    Koren: Exactly.

    Shimel: Right? They do it because they have time constraints, they wanna get it done, they want it to work faster, right?

    Koren: They’re exactly the reasons that we’ve understood when we looked into it.

    Shimel: Yeah.

    Koren: And it makes sense. If you think about it, developers should be able to add whatever it is that they think can help them develop faster. I mean, it’s the business goal.

    Shimel: Mm-hmm.

    Koren: The main question that we asked is—well, how can you make it more streamlined, okay? How can you—and now, going one step backwards or sideways, there’s a disconnect, okay? The developers, as you said, they wanna make it a secure code, but the business owner or the person who manages the security posture of the application doesn’t necessarily know that somebody introduced a new vulnerability, because the developer thinks that this repository is safe. I mean, it should be, it’s in GitHub. [Laughter]

    Shimel: Oh, no—agreed.

    Koren: So, the thing is—and this is where we asked around, our customers, what are they doing to mitigate this type of risk and what are they finding out. And what we found out is, interestingly enough, you have a lot of performance monitoring tools, but you have zero security monitoring tools on client side in real time. You have static code analysis, you have a lot of other solutions trying to find the vulnerability before it goes out to production. But once it’s out there, nobody monitors.

    And you have to keep in mind—I know you are keeping in mind, but our listeners—the fact that, well, when in run time, you can inject dynamic code, that changes. And if somebody else gets control over it, this is a problem.

    Shimel: Yeah, yeah. Well, and there’s a couple, I think, other complicating factors, Elad, that I’d like you to address. And that is, you know, today, where does that client side code live? Is it in the container somewhere with the whole Kubernetes microservices mesh thing goin’ on?

    Koren: Mm-hmm.

    Shimel: Is it in the traditional hypervisor kind of environment, or maybe something like that or is it on bare metal and serverless or—you know, it’s a great time to be a developer, but it’s a very hard time to be a security person who’s trying to keep guardrails there for these people to do it as safely as possible, as securely as possible. How do you do that?

    Koren: This is correct. You’re spot on. You’d expect that when a new code is introduced, the company or the developers would adopt it and manage it or maintain on their servers or on their microservers or their mesh. However, because they want to keep it updated, because they want to keep it as capable as possible, they sometimes take the dynamic library from their repository and, whenever there’s a CI/CD process going on, it pulls the library from there.

    And that is where the shadow code becomes a problem. Because, unless you have the right processes around, how to make sure that this library is safe? How to make sure that this is, you’re not introducing anything malicious—and we have seen it happening in the past—this is where you have to address the problem. And you know, I can share some of the things that we’ve seen when we had the validation of the product before we launched it. We had a design partner, and they asked for something like this because their developers asked for the security team to allow them visibility into what’s happening on the client side. And we’ve actually—and it’s a big customer. I don’t want to name names, naturally, here, but—and you will share my surprise—when we found out, when we run on their client side that a very, very big vendor of there is using a jQuery from a non-trustworthy source.

    Now, you’d expect something like this would never happen for a well-established company, but it does. And it’s surprising, but it does. And they weren’t the only ones.

    Shimel: Hmm. Interesting. So, let’s now talk—so, I think we’ve defined the issue and the problem, right? How is PerimeterX helping this?

    Koren: So, our approach when looking at this issue or this problem, naturally, we are a Dev first company. So, we came and asked the developers that we were working with—the DevOps, DevSecOps, and some of the risk analysts, some of the personas—what would be most beneficial. And what they said, and this is how, you know, I’m the VP of Products. I’m a Product Manager at heart. And customer input is the number one thing that I’m looking into when I’m building the products.

    They said very clearly, if they can see, before moving from staging to dev to prod, what the code itself, when it’s pulled dynamically, is doing and have the visibility of what’s happening there in real-time on users—this is something that they don’t have today. Because that will introduce that level of visibility whenever something bad happens.

    I don’t know if you’ve seen some of the Magecart attacks that have happened from third-party libraries. Again, don’t wanna name names, but if somebody looks online, they can find out. When we come in and we analyze in real-time on the client side, on every user going into the website, what the scripts are doing there, whether they send information to a bad domain, whether they try to take the information and store it in a cookie and then use it later on—we can quickly highlight the main risks and main problems and vulnerabilities, like I mentioned earlier with jQuery, so that the DevOps or DevSecOps can quickly raise a flag and say to the developer, “Listen, this script you’ve added introduces new vulnerability.” You can’t see that in the static code analysis, but you will see that on run time on the client side. And that is something revolutionary. We don’t have that today in anyone else’s solution out there.

    Shimel: Hmm. Interesting. What—so, I always ask, and you’re the perfect person, VP of Product—now you’ve got a conundrum. You’ve got a really great security product here that’s gonna help developers with secure code. How do you—how do you sell it? How do you bring it into the organization? Do you talk to the security guy and say, “Hey, go talk to your developer team and tell them to use this?” Do you talk to your developers and say, “Tell your security team you wanna do this?” Do you gotta talk to the security team and the developer team? Whose budget does this come out of? Who ultimately is responsible for setting the policies and processes?

    Koren: And this is—

    Shimel: Is the solution hard to sell, maybe, though?

    Koren: You’re correct. So, theoretically, it’s hard to sell. However, the main key here or the key differentiator is the fact that when we went in to look how we wanna sell this solution, before we even built it, we established the fact that it should fit into their processes. If it’s not fitting into their processes, if they have to start defining things like content security policy, if they have to start maintaining this on a day to day basis, it’s not going to work.

    Solutions for DevOps or DevSecOps today are one, two, three. You have to have it in and you have to do it quickly and you have to have minimum manual effort, unless you definitely prove why it’s needed. And so, this is why we’ve added the fact that nobody needs to do the baselining on their own, we are doing that automatically with machine learning capabilities, what every script does, whether it’s ________ or not, and the fact that they can just have a small snippet on their client side and we’ll analyze whatever and flag in our portal or alerting system that they have, it actually fits into their CI/CD process, it fits into their day-to-day process. They can even have it as part of their regular security processes and have it fit into their SIM.

    And this is where it really makes the difference, because you don’t have to do anything manually and you solve a problem and you fit into their processes, and security people are very happy about it. I can tell you that one of the customers that actually already bought this product was very happy with the fact that they have visibility to this area and they don’t have to maintain it on their own, because we are doing that, the product does that out of the box. So, this was a key component in our product.

    Shimel: Huh. Excellent. Excellent, excellent. So—I told you, the time goes very fast. [Laughter]

    Koren: [Laughter]

    Shimel: We’re coming up on time, here. For people who are interested—let’s use our time wisely—how could they find out more information? What path do you suggest for them?

    Koren: So, first of all, they can go out to our website and check out our solutions, both for bot mitigation as well as the Code Defender and other solutions that we have. I think reaching out to our team if you have any questions, if you have any concerns around the client side, I can tell you that even companies that thought everything’s fine were completely oblivious to threats and concerns around the client side that are out there and many people are not aware of. You can also reach out to me directly via LinkedIn or what have you and we can discuss.

    I think in general, for DevOps and DevSecOps to be more aware of the dynamic nature of the code that is added to the client side and what to do. We actually have a blog post listing the things that are best to do if you want to make sure that it’s secure and you’re on top of things. So, it’s a good read as well. And that’s about it. So, we are here. We’re ready to help.

    Shimel: Cool. Last question, just because you have to ask it because it’s out there—with everything going on in the world with the COVID and everything else, how is it affecting you guys and what are you seeing?

    Koren: It’s actually amazing. We’ve seen some trends around the e-commerce landscape that we’ve actually had some blog posts on. And I think, you know, one of the things that kind of symbolizes these times, a few of the e-commerce sites that we are working with said that the traffic they experienced outgrows the Black Friday/Cyber Monday level of traffic.

    I think it symbolizes kind of the boom of online life that we have. I’m sure you’re experiencing it as well. And I think the shift there is not going to go back to the previous levels. It’s definitely going to go down, but we are seeing so many trends, very interesting trends, and we are naturally adjusting what we are doing, but luckily and happily, we’re doing great these times and it’s—we’re very happy with what we have now.

    Shimel: Well, I will tell you, for whatever reason, you know, and it may not all be good, because there is this whole, with the virus pandemic there’s a cyber pandemic of people trying to exploit. I mean, so, for instance, even here MediaOps where DevOps and Security Boulevard, our security site, used to be pretty even in terms of how many visitors—they both get 350 to 400,000 visitors, unique visitors.

    Koren: Mm-hmm.

    Shimel: All of a sudden, you know, Security Boulevard now this month is gonna be at 600,000.

    Koren: Wow.

    Shimel: Last month was 530,000. So, in the last two months since this COVID thing, you know, we’ve seen traffic on the Boulevard site—DevOps has stayed relatively steady. It hasn’t gone up, necessarily, it hasn’t gone down.

    Koren: You know, one thing we’ve noticed, and I think it can also explain, I think it’s wider than that—attacks and in general fraud and security challenges became much more complicated, because the adversaries are out there and they are targeting a whole lot of other new sites that previously didn’t experience. We are seeing much higher levels of complexity in the attacks that we’ve previously seen on giants, now on even medium small—small- to medium-sized sites.

    Shimel: Agreed. Crazy. Just crazy, right?

    Koren: Yeah, indeed.

    Shimel: You know, because that’s what you need when you have a virus pandemic, we need to have more cybercrime and that stuff to worry about.

    Koren: Yeah. [Laughter]

    Shimel: So, Elad, I want to thank you for joining us today on DevOps Chats. It’s been a pleasure.

    Koren: Thanks, Alan.

    Shimel: Be back on soon. Elad Koren from PerimeterX here on DevOps Chats, this is Alan Shimel and you’ve just listened to another DevOps Chats.

  • Taming the Shadow IT Beast and Runaway Spend

    Taming the Shadow IT Beast and Runaway Spend

    Do you know how much IT resources your employees are consuming?

    According to research conducted by the Everest Group, shadow IT spending accounts for a whopping 50% or more of the IT budget. Beyond these costs, shadow IT could end up costing you big in terms of a security breach: Gartner estimates that 33% of security attacks will be on shadow IT resources by 2020. Simply put, shadow IT isn’t just an expensive problem to have. It’s a threat to your business.

    You Can’t Blame Developers for Going Rogue

    DevOps and application teams are a key consumer of IT resources in your organization—they’re agile teams who need to get product releases out the door quickly. They need to get the job done, and will provision any resource that will get them there, even if it means going around IT.

    Still, you can’t blame these developers for going rogue: They need the right resources when they need them, and IT, busy responding to multiple tickets while juggling daily fires, can’t always meet those needs in a timely fashion. From a developer’s perspective, though, the fact that IT is firing on all cylinders to do their best doesn’t matter. For them, waiting days for resources may as well be an eternity.

    Giving Your DevOps Teams the Goods

    In a perfect world, DevOps and application teams would get access to the resources they need without the back and forth of ticketing systems, or the complexity of provisioning resources on systems that are totally unfamiliar systems. The latter is especially risky because it can introduce potential security holes that could be exploited by attackers.

    To this end, IT’s ultimate goal should be to enable self-service provisioning for DevOps and application teams. Creating a catalog that only serves up the resources relevant to the requesting team is one option here. Through blueprints, a repeatable way to orchestrate and automate provisioning of resources, this self-service nirvana becomes a reality: IT delivers resources in minutes, not days or weeks, and developers get what they need without putting the organization at financial and operational risk.

    Delivering Self-Service, but with a Safety Net

    Of course, IT wants to be as efficient and agile as possible, though not at the expense of control over cost and compliance. So, while enabling DevOps, IT also needs to monitor and contain cross-cloud spend.

    To accomplish this, IT can set automated quotas and limits, ensuring that user access to AWS resources, memory and more, is tightly controlled. They can also set up controls, such as power scheduling and expiration dates, to further control costs. As a result, VMs can’t be left on gobbling resources over the weekend, and demo environments shut down automatically when no longer used.

    From a security and compliance standpoint, IT can prevent teams from going rogue by determining who can do what. For instance, this could be who can orders servers, workloads and XaaS—along with quotas set for spend and resource usage—to who can approve fulfillment of those orders. This way, resources are never overprovisioned, and a real tally is kept as to exactly who is using which resources across the business.

    Taming the Shadow IT Beast

    With a better handle on cloud spend and resource usage, IT teams can put a dent in the 44% of IaaS compute spend stemming from non-production resources that are accidentally left running, according to ParkMyCloud. At the same time, they can stay on top of security and compliance, while still giving DevOps the tools they need, with orchestration blueprints that automate resource provisioning on a repeated basis. Taming the shadow IT beast, allowing developers to access resources in seconds with a self-service catalog, frees up IT teams to tame all the other beasts they face on a daily basis.

    — Brian J. Kelly

  • Three Insights from the World’s Leading IT Organizations

    Three Insights from the World’s Leading IT Organizations

    IT is in a state of change on a consistent basis, but never more so than now. With the increasing importance of the digital customer experience across all industries, technology is at a new inflection point in how it can fundamentally impact executive priorities. And while nobody can speak for the direction of IT as a whole, there are a few resources so comprehensive that they’re worth reviewing when they’re released.

    Take, for example, the 2019 Harvey Nash/KPMG CIO Survey. It’s the largest global survey of CIOs with data from 3,645 respondents across 108 countries. IT leaders who participated in the survey controlled a whopping $250+ billion in annual IT budgets. The CIO survey examines how board priorities, technology adoption, skills gaps and IT leadership is changing in the age of digital business.

    Here are three insights that explain the tectonic shifts occurring in enterprise IT teams today.

    Digital Leadership: Three Steps to Becoming a Digital Native

    The 2019 Harvey Nash/KPMG CIO Survey shows only 30% of IT organizations are digital leaders. These organizations are unusually adept at “using digital technologies to advance their business strategy,” and can launch innovative solutions that generate new revenue streams, enable faster time to market and cut down operational costs. Here are three defining characteristics of what it takes to be a digital leader in 2019:

    • It’s All About Data. Data management and analytics is a core competency of leading IT organizations. Digital leaders are in a strong position to maximize the value of their organizational data by extracting, aggregating and curating the right information. This data is then used to train machine learning models, create high-value assets and deliver customer value on an ongoing basis.
    • Speed of Execution. Digital leaders are willing to either quickly double down on successful experiments or pull the plug on products that don’t deliver expected value. They are also more likely to leverage agile and DevOps practices to increase software release velocity and iterate rapidly on solutions using fast feedback loops.
    • Expansive Mindset. Digital leaders have transitioned from project thinking to product-centric innovation for creating enduring value from their software investments. They also build cross-functional teams across their business and IT silos for better collaboration and faster decision making for digital transformation initiatives.  

    What Does This Mean? CIOs will need to embrace big data analytics, agile delivery models and product-centric teams to create the right foundations for digital business. Without proper foundational investments, IT leaders will struggle to meet business demands, gain customer trust and withstand competitive pressures in the face of escalating customer expectations.

    Business-Managed IT: How Shadow IT Finally Became Respectable

    In the last decade, the adoption of cloud services led to the phenomenon of shadow IT where business units would directly buy cloud solutions without consulting IT teams. CIOs resented their growing irrelevance and tried their best to bring shadow IT under their control.

    The 2019 CIO survey confirms 64% of enterprises have made peace with business-managed IT investments. In fact, 10% of IT leaders actively endorse this approach. What factors have led IT teams to change their mind on shadow IT?

    The survey shows organizations with business-led IT scored better on key metrics than organizations without any mandate for business-managed technology spend. Business-led IT organizations delivered “better customer experiences and faster time to market for new products (52% more likely) as well as positive employee experiences (38% more likely).”

    For business-managed IT spending to be truly successful, CIOs will require the right guardrails in the form of central IT oversight. The 2019 CIO survey makes the case that organizations without IT team involvement are twice as likely to have multiple security issues and are also less likely to build customer trust with their technology investments.

    What Does This Mean? Instead of actively opposing shadow IT investments, CIOs should partner with their business counterparts to create effective governance and operating models for business-managed IT spending. Central IT oversight will ensure the right support for digital business initiatives, reduce the risk of unauthorized breaches and minimize wasted spend.

    Influencing Without Authority: What It Takes to Be an Effective Technology Leader

    Board membership for CIOs dropped this year, with only 58% of IT leaders being part of the executive team in 2019 as compared to 71% in 2017. Does this mean CIOs no longer have executive backing for orchestrating and executing digital business strategies in their enterprise?

    The 2019 CIO Survey indicates board membership, headcount or annual budgets are not the right indicators of the power and influence of technology leaders. Instead, CIOs should focus on building trust across organizational boundaries, creating partnerships with the right executive stakeholders and ensuring the success of critical initiatives. CIOs working for digital leaders are comfortable exerting influence without authority and are driving organizational growth, by being “three times more likely to collaborate strongly with business leaders.”

    What Does This Mean? Formal board membership or the size of the IT team is not the best way to assess CIO influence. The best technology leaders ensure successful enterprise transformation by garnering strong commitment from the board, building digital capabilities with cross-functional teams and creating a sense of urgency for rapid innovation.

    — Deepak Jannu

  • Modern Workers Demand Modern Technology

    Modern Workers Demand Modern Technology

    Companies today must think of their employees as customers and employ technology, including mobile apps, that employees want to use.

    I have always been a bit of a technophile. Many years ago, in another life, when I worked in technology sales, I was one of the first sales engineers on my team to buy a personal laptop to use as a way to manage leads and accounts. The advantages of doing so over pen and paper became clear to me within weeks. I was able to track my activities more effectively and follow-up more precisely than my associates.

    For similar productivity reasons, I also equip my home office with the best tools that make the most sense from a productivity standpoint. This has been true for both the years I worked out of my home office self-employed and as an employee.

    I expected the tech I bought for my work to always be better than the tech that was provided to me by my employers. I grew to dislike the outdated computers, software and support services provided by employers. Why didn’t these employers invest in their employees to make them as productive as possible? There was never a good answer to that question.

    However, in the late 1980s and early 1990s, I was an outlier. Most workers didn’t have personal computers and most appreciated whatever outdated green screen hardware and software was planted in front of them. Today, it’s the other way around: Employees don’t just want state-of-the-art technology that matches their work—they demand it.

    Consider a recent note from research firm Gartner that found outdated technology pushes Australian workers away from their employers. In fact, Gartner’s “Q4 2018 Global Talent Monitor” found that technology now ranks ninth in the top 10 reasons Australian employees will leave their current role.

    “People have become so used to advanced technology in their day-to-day lives, that they expect the same thing from their workplace. However, businesses are having a hard time matching the speed at which technology is adopted at home,” noted Aaron McEwan, human resources advisory leader at Gartner. “It’s not surprising that employees are becoming frustrated when they find themselves wasting valuable time navigating complicated systems and processes that utilize slow and old technology. It’s unproductive and inefficient for everyone involved.”

    According to McEwan, businesses no longer can ignore the needs of their employees and must start thinking of them as they do their customers, making it a priority to offer a personalized, seamless and efficient experience.

    This recent Gartner Australian survey taps into trends that have been underway for some time. A few years ago, Microsoft partnered with SurveyMonkey to conducted a survey of about 1,000 millennials in the United States. That survey found 93 percent of respondents said modern technology was one of the top aspects of a good workplace.

    This isn’t just about new hardware or off-the-shelf software. It’s also about custom-built enterprise apps. For decades it has been accepted practice that enterprise software didn’t have to compete with consumer software, and poor-to-lackluster design was considered acceptable.

    This is no longer the case. Most employees today are technically savvy and their enterprise apps are on their tablets and phones, right next to the consumer apps that they love to use.

    Enterprise IT can try to force them to use leaden software, but this strategy increasingly is unlikely to prove productive. If they don’t like a collaboration platform, they’ll turn to one of the widely available cloud alternatives. If they don’t like the enterprise CRM, they’re likely to turn to Salesforce or a competitor.

    When consumer apps are designed—think Evernote, Uber, Instagram or another favorite consumer mobile app—a considerable amount of thought is invested into the user interface and making the app enticing to use, designing an intuitive workflow and hiding complexity from the user into the background of the app. The same should be true for the enterprise apps designed for the enterprise.

    A recent survey from Adobe found that 61 percent of 1,500 enterprise leaders believe organizations that don’t deploy mobile apps are at a competitive disadvantage. I’d take that a step further and conclude that deploying isn’t enough. But it’s more than simply deploying an app; organizations that don’t deploy effective and compelling apps will find they are at a competitive disadvantage.

    — George V. Hulme

  • Has DevOps Caused the Re-emergence of Shadow IT?

    Has DevOps Caused the Re-emergence of Shadow IT?

    Shadow IT is back, and this time, it’s in the DevOps toolstack

    “One of our clients conducted an audit and found more than 10,000 Jenkins instances across their IT landscape!” This remark from a tooling vendor that helps enterprises centralize their continuous integration infrastructure really took me by surprise. For starters, I was impressed how the company had unleashed creativity at this scale—if the number of Jenkins instances in an organization is an indicator of DevOps. Clearly, its employees have taken the saying, “Don’t ask for permission, ask for forgiveness,” very seriously.

    However, there are certain risks with this approach, especially security risks if teams haven’t considered the long-term implication of their decisions. For instance, how do you handle another major security flaw such as the OpenSSL Heartbleed bug? You may have to send hunting squads to track down all the instances of Jenkins (in this case) across your IT estate—including the Linux server hidden away under the desk of the engineer—and patch them. If you are lucky, you can audit all the virtual machines on your chosen cloud where all your tooling instances reside. And if you are really lucky, the entire DevOps tooling infrastructure would have been set up in a DevOps way, using infrastructure-as-code principles with automated patching capability.

    Consider the nightmare scenario for IT compliance, security and governance teams: The spectre of shadow IT is amplified due to poor adoption of DevOps! Shadow IT in the application stack has always been a big headache for CIOs; the use of IT systems within an organization without the approval, or even the knowledge, of corporate IT has never gone away. Shadow IT has been historically associated with business users who made the purchase, but did not have the expertise to maintain and upgrade the software to make sure there were no risks to the wider organization. Much has been written about the problem in the application stack and how DevOps ways can help resolve the issue.

    However, with the proliferation of DevOps tools in a localized way, the shadow IT problem is now manifesting itself in the tooling architecture of enterprises. With the increasing adoption of DevOps practices and tools in the enterprise, teams have started installing various DevOps tools in a localized and autonomous way. This is leading to the shadow IT problem in the tooling landscape of enterprises. It’s slightly different than the problem that originated in the application stack, but with similar risks and challenges. Access to cloud in the enterprise has made it easier for teams to set up their own localized DevOps tool sets. A sizable program of work in its full DevOps glory can easily use dozens of tools and need to consider aspects of security such as:

    1. What is the patching policy ?
    2. Are your DevOps tools critical to the business due to the dependency on them for the build and deployment of critical  services that the business requires?
    3. How resilient is the tooling infrastructure ?
    4. Is there enough knowledge in the enterprise to handle this change?

    Essentially, there are four risks of shadow IT due to DevOps tooling, based on a pertinent classification by Computer Weekly:

    1. Software asset management: The risk of discovering unapproved and unlicensed software is huge and the CIO could be potentially jailed for sanctioning usage of unlicensed software.
    2. Compliance with industry and government standards to demonstrate quality to customers.
    3. Lack of testing and change control: Managing cycle of change and releases becomes complicated when there are dependencies on third-party SaaS.
    4. Configuration Management: IT teams rely on the veracity of information in the configuration management database CMDB and shadow IT compromises it.

    Organizations typically respond to the problem of shadow IT with rationalization, migration or even sunset of the targeted applications—most of which are reactive measures. In the context of DevOps tools, an extreme way to deal with the problem is by taking control of all tools with an “iron fist” and shutting down everything—at the risk of killing off innovation in the enterprise. In the short run, teams do achieve higher levels of productivity by deploying tools in the way that suits their business context and experience of the engineers in the team. However, over time I find that the teams are overburdened by the maintenance overhead of DevOps tooling and maintaining a tooling stack in addition to their software application stack. At times, if they are early adopters in their organization, they tend to be victims of their own success: by supporting other teams with their tooling solutions, almost becoming a tooling platform provider internally, and diverting their attention away from their core purpose of delivering value to their business partners.

    One pragmatic way to resolve this is to add an element of centralization or “platformization” of the tooling infrastructure.

    Autonomous teams understandably fiercely resist any attempt to centralize services in the enterprise. A few useful ways to gain a balance between innovation and control include:

    1. Provide a responsive tooling platform: “You can have any color as long as it’s black” approach to DevOps tooling will only lead teams to finding their own unique solutions.
    2. Anticipate tooling needs and build them: Think ahead, track the trends and procure the tools that you expect teams to achieve. For example, if a few teams are already playing with docker and containers, then think a step ahead and look at Kubernetes to manage the containers.
    3. Focus on user experience: Think about the ease of subscribing to tools, installation, billing … the entire life cycle
    4. Offer help to transition to the tooling platform.
    5. Run an internal communications campaign on the tooling capabilities that are available to teams.

    Ultimately, a well-thought-out DevOps approach and implementation can actually help resolve the challenge of shadow IT that organizations face, instead of accentuating the problem.

    — Aditya Vadaganadam

  • Citizen Developers Can Benefit an Organization

    Citizen Developers Can Benefit an Organization

    In many organizations, IT resources are pushed to the breaking point while users increasingly demand new technologies, features and capabilities. Users who know a thing or two—often just enough to be dangerous—sometimes “expedite” matters by finding their own shadow IT solutions. Organizations can harness those efforts, though, as citizen developers by finding a way for IT and rogue users to work cooperatively toward a common goal.

    Shadow IT can be a serious issue. Consequences arise when users store sensitive company data in the cloud using unsanctioned consumer-oriented services such as Dropbox or track customers or sales in a Google Sheets document. The company loses control and oversight of its own information because it no longer knows where it is, and IT can’t adequately protect data or processes it isn’t even aware of. Users who implement maverick solutions put the company and its data at risk.

    On the flip side, these users understand best what is needed to get the job done. They’re the ones working in the trenches and whose employment depends on getting their job done effectively. IT might select or develop tools and mandate that users adopt them, but if they don’t deliver all of the capabilities users need—or worse, get in the way of efficient productivity—users often will take things into their own hands.

    What if IT and employees work together? That is the promise of the citizen developers movement. It’s a recognition that IT has neither the resources nor the vision to deliver everything users need, while providing rogue users with a sanctioned framework for creating solutions that IT can approve and manage.

    Michael Beckley, CTO of Appian, explained that “shadow IT” is a pejorative term used to describe business teams bypassing IT and enterprise architecture governance to purchase systems that may create disconnected silos. Citizen developers can leverage shadow IT or sanctioned IT. Most successful IT organizations embrace low-code platforms and other technologies that enable citizen developers to operate securely and transparently within IT’s domain.

    “The best-designed products have always been built with the needs of the user from the outset,” Beckley said. “Who better than citizen developers to design software that enables organizations to transform customer experiences, launch compelling new products and manage risk efficiently? Citizen developers are motivated by the opportunity to create a new reality, not merely accepting the workplace as they found it.”

    Organizations typically enable citizen developers by providing a cloud-based, low-code platform that enables IT to create managed integrations to core systems, and maintain governance and security without significantly limiting the creativity of users.

    “Citizen developers are most successful when supported by IT,” Beckley said. “One critical area where IT can help is in promoting reuse and modularity in the applications and business processes that citizen developers build.”

    Having worked in the trenches as an IT admin, I have firsthand experience dealing with maverick users who try to circumvent policies and go around IT. At the time, I saw that as an attack on my authority in my role as an IT admin. A lot has changed since then, though—both with the technologies and services available, and my own attitude. I have come to recognize that users know best what they want and need, and there should not be an adversarial relationship between IT and users.

    By embracing citizen developers, organizations can harness that ingenuity and innovation to help make the whole company more productive.

  • Should Citizen Developers be Welcome in DevOps?

    Should Citizen Developers be Welcome in DevOps?

    “We’re all developers now. Citizen developer activities will accelerate.” That’s what Gartner predicted back in 2012. Fast forward more than four years and we’ve seen the DevOps movement explode, while the rise of citizen developers has also marched steadily. The challenge for organizations is to figure out how these two philosophies co-exist and complement one another.

    What are “citizen developers”? The 2015 State of Citizen Development report defines them as, “… 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.”

    DevOps is about agility and momentum. Automation. Continuous continuousness. The culture and tools that comprise DevOps are all about moving faster—facilitating better collaboration and streamlining processes to accelerate the development and deployment of applications. That more rapid pace relies heavily on automation, in most cases, and still has rules and procedures to manage how things are developed, tested, integrated and deployed.

    The citizen developer movement, on the other hand, is sort of an evolution of rogue or shadow IT. There has always been “that guy” in any given company. The one who is too impatient to follow procedures or wait for IT to deploy a solution, and who knows just enough to be dangerous and brew his own unsanctioned tools. Citizen developers harness that same “maverick” attitude, but in a more acceptable and manageable way.

    Platforms like Intuit Quickbase or Genesis from Metavine provide users with little or no coding experience with the tools to create effective applications without writing a single line of code. It may seem like that encroaches on the work of developers and confuses things, but there are two caveats to that. First, the users are in the trenches and have an intimate understanding of the issues they’re trying to solve—so theoretically they’re best-suited for solving them. Second, if citizen developers can use code their own solutions for the “low-hanging fruit,” then developers are free to focus on solving more complex business problems and developing more innovative solutions.

    Metavine explains, “This approach for generating Cloud and IoT applications places more responsibility in the hands of the people who define business needs, freeing them from typical engineering constraints. Application development becomes more collaborative and highly creative, involving technologists, solutions architects, designers, and line of business people performing cross-functional work to produce agile business results.”

    Craig Sproule, founder and CEO of Metavine, provided a description of Genesis. “It is a true zero code application development platform designed to enable the creation of enterprise-class applications. It allows developers and architects to build applications to meet exacting needs, while delivering unprecedented agility to the business.”

    While at first glance it would seem that having a bunch of rogue citizen developers implementing their own home-grown apps is a bad idea and would complicate and conflict efforts to streamline development through DevOps. But the reality is that they can co-exist peacefully. Using the right tools and platforms, citizen developers can help solve some of their own problems more quickly and let developers focus on solving more complex problems.