Category: Features

  • Low Code and Change Management with Max Rudman

    Low Code and Change Management with Max Rudman

    Many organizations trying to accelerate their digital transformation are turning to low-code technologies to respond quickly to the constant market changes. Low-code technologies facilitate application development by offering drag-and-drop components that require little to no hand-coding. Low code creates a seamless integration between cloud platforms, tools and utilities.

    As low-code applications increasingly become a shared responsibility between IT and business units, it’s incumbent upon IT to ensure changes are delivered consistently, reliably and without disrupting end users — no matter who makes the change.

    In this Q&A session, Prodly CEO Max Rudman answers a few questions about low-code applications and change management.

    Max is one of our distinguished speakers presenting at Low Code Today Virtual Summit. During his session, Max will discuss how to implement an agile change management process to low-code applications and accelerate time to value for low-code apps.

    How do low-code applications boost productivity?

    The simplest answer is: It’s just faster to configure and make changes to low-code applications. Low-code apps leverage declarative programming, meaning you assemble a solution by dragging and dropping predefined components together like Lego blocks instead of writing code line by line. Everyone knows how to use Legos, which brings us to the far greater productivity benefit of low-code apps — they expand the number of people on your development team.

    Low-code applications have given rise to the citizen developer — someone who deeply understands the business problem and how to design the desired solution but previously lacked the programming skills to make it a reality. With low-code applications, business analysts, project managers, operations teams and other business users are empowered to implement solutions for themselves. Consequently, technical developers have more time to focus on projects that require specialized skills. Because developers are now able to focus on tasks that really do require programming expertise, they become more productive, too. It’s a win-win for both IT and business.

    How does low code drive change management? How can you carry out an effective change management process?

    Low-code applications highlight the need for change management within an organization, especially as application configuration and maintenance becomes a shared responsibility between IT and lines of business. This should not be a free-for-all approach to application development where anyone can make changes to applications at any time. More and more businesses rely on low-code apps to manage critical and often complex business processes, like revenue and customer service. Changes must be made in a predictable way that mitigates the risk of errors, downtime and other disruption to users. At the end of the day, users don’t care if an application is built with code or clicks, but they do expect it to work reliably and securely for them to do their jobs. 

    Change management processes address these issues and foster greater collaboration between IT and the business. The low-code revolution has accelerated the pace of change, and it’s causing organizations to rethink their change management processes to accommodate non-technical developers to participate. It’s an opportunity and a responsibility of IT to establish the guardrails and guidelines to empower citizen developers to move fast without breaking things. 

    What can we expect from your session?

    We’ll be discussing the implications of low-code applications on existing change management practices and why that’s causing IT leaders to rethink the people, processes and tools for managing change. Attendees will get practical tips for change management strategies that decrease application time, accelerate time to value and mitigate risk. We’ll also dive into how to give CIOs and IT managers the visibility they expect into the change process.

    To learn more low-code adoption and change management, attend Max’s session at Low Code Today Virtual Summit on Nov. 19. To check out the full agenda or to register for free, visit the Low Code Today website.

  • Survey Sees Surge in Demand for DevOps Skills

    Survey Sees Surge in Demand for DevOps Skills

    The Linux Foundation and edX, a provider of an online learning platform, jointly released an annual report today that for the first time finds organizations are looking for more IT personnel with open source DevOps skills (65%) than developers (59%).

    Clyde Seepersad, senior vice president and general manager for training and certification at The Linux Foundation, said the 2020 Open Source Jobs Report shows that as more workloads shift to the cloud in the wake of the COVID-19 pandemic, the number of organizations looking to embrace best DevOps practices is increasing substantially. The report finds 70% of respondents are more likely to hire an IT professional with cloud computing skills.

    Based on a survey of 175 hiring managers and 900 IT professionals with open source expertise, the report also finds that despite the economic downturn brought on by the pandemic, 37% of hiring managers say they will be looking to hire more skilled IT professionals in the next six months.

    The report also finds 93% of survey respondents report difficulty finding open source talent. An overwhelming 81% of hiring managers said recruiting open source talent is a priority for 2020, with 56% looking to recruit IT professionals with open source skills in the next six months. Nearly two-thirds (63%) said their organizations have begun to support open source projects with code or other resources for the explicit purpose of recruiting individuals with open source software skills.

    More than half of hiring managers (52%) said they are more likely to hire someone with a certification, while 80% of survey respondents reported providing online training courses for employees to learn open source software. Nearly three-quarters of organizations (74%) are now offering to pay for employee certifications, according to the survey results.

    An equal percentage of hiring managers also identified Linux as the most in-demand skill they seek in new hires, while 63% also said they are looking for IT architects who can build solutions based on open source software.

    Seepersad said given the difficulty attracting talent many organizations are focusing more on training their existing staff rather than trying to recruit talent in an open market where demand for open source expertise remains high.

    The talent pool is more global as more organizations become accustomed to working with staff who are now largely working from home, which, coupled with current economic realities, is limiting how much organizations are willing to pay for IT talent. More organizations are also keen to make sure there is a cultural fit with their organization when hiring, he added.

    In general, it’s clear more IT organizations will need to focus on growing their own farm teams with open source DevOps skills rather than hoping to lure away superstars from other organizations. Rather than simply trying to fill open positions, organizations need to think more in terms of acquiring and managing talent in the same way a general manager manages a sports franchise.

  • How To Foster a Culture of Citizen Developers

    How To Foster a Culture of Citizen Developers

    What can leaders do to encourage a thriving environment of citizen developers in their organization?

    Over the last several months, businesses of all sizes have had to embrace rapid change, as have their workforces. When it comes to IT departments, even before the pandemic many were fielding requests to implement new technology, customize solutions to niche problems and automate specific tasks at rapid rates. Unfortunately, these increased demands coincide with an ongoing developer drought, and paired with the pandemic, have put an added strain on some already thinly stretched IT teams.

    As a result, there has been an observable rise in citizen developers being tapped to relieve some of this burden. “Citizen developer” here is used to describe any programming novice or non-developer who has been tasked with the responsibility of constructing custom applications. This person has some familiarity with programming but may not have been formally trained and, therefore, may use their own set of tools and workarounds to complete the work. If leaders don’t make an effort to create standardization, the consequence can be high variability in quality, efficiency and output.

    And it doesn’t seem to be a passing phase. I recently spoke with Dave Garrett, chief strategy and growth officer at Project Management Institute. As we look to the future, Garrett believes that citizen developers will play a critical role in helping organizations stay agile and ensuring projects move forward without delay.

    Though it won’t solve all of your pressing technical concerns, the good news is that with smart strategies, a citizen development emphasis can ease the burden on IT teams and improve output. Garrett spoke to a sea change of new techniques being developed to respond to these growing needs.

    4 Elements of Strong Citizen Developers Culture

    1. Standard Toolsets

    To start, build a solid foundation by choosing standard toolsets. Be sure all development staff is made aware of the toolsets you’ve deemed standard, clarify that adopting them is a priority and ensure that all have access. Standard approaches to using these tools should also be established and communicated, such as programming languages and stylistic standards.

    “If you have a standard toolset and approach, then you have many people who can help,” Garrett said, emphasizing that by doing so, you are building a broader base of support. Having a larger pool of employees to pull from helps an organization stay on top of the necessary tasks and creates more freedom for open collaboration. As a bonus, professional developers are freed to focus on more advanced tasks, such as machine learning and or mathematically complex programming.

    In deciding which toolsets and approaches to make standard, Garrett said, ask yourself, What will get them from A to B most quickly and efficiently? One approach to this is low-code or no-code tools. He considers such platforms transformational in empowering citizen developers to express ideas tangibly without a great deal of coding.

    2. Technical Training

    From here, ensure that all development staff, especially your citizen developers, have been technically trained in adopting the standard toolsets and approaches that have now been established. This may include offering training in low-code UIs and instilling fundamental programming concepts such as boolean logic and conditional programming such as If/Then/Else statements.

    “Set a foundation of success for learners,” he said. For example, have them build something of value during training, making it as actionable as possible for the use cases they will be handling.

    3. Discouraging Use of Shadow IT

    Once you have established toolsets and training, leadership should do whatever’s possible to enforce the established standard’s adoption and discourage the use of shadow IT—tools, applications and workarounds not approved by leadership within the company. Shadow IT, as a practice, can be messy, creating high variability and making quality-control and collaboration difficult. “You want to avoid it,” Garrett said.

    4. Good Mentorship and Governance

    Another benefit of having a standard toolset and eliminating shadow IT use is that it enables more efficient mentorship—critical for inspiring citizen developers. IT teams are advised to identify a mentor or group of mentors proficient with the standard tools to offer ongoing guidance to the team’s citizen developers.

    Quality mentorship goes hand in hand with quality governance. “Governance” here is used to mean technical admins who enforce the use of technical standards, tools and programming styles. No-code tools require access control that reflects a citizen developer’s permissions.

    Building in Hyper Agility + The Two-Pizza Rule 🍕🍕

    One way to think, Garrett said, is hyper agile. This can apply to team size, smart PM cycle lengths and brainstorming techniques.

    Team Size

    In thinking of ideal team size, ask: How can the team be optimized to work quickly and efficiently? One suggestion Garrett had was to ensure your team isn’t too large to effectively train, mentor and govern. For example, as a rule of thumb, he mentioned the old “two pizzas” rule: A team size shouldn’t require more than two pizzas to share a meal.

    Sigh. Remember things like in-person training? Pizza parties? Obviously, old meetups can’t be executed exactly to plan these days, except with some clever contactless delivery tactics, but you get the idea. A strategically sized team will create an efficient workflow and collaboration in your team dynamics.

    Cycle Length

    As projects come in, an agile cycle length, or sprint, for completing a specific set of work should be determined. What is an efficient amount of time to expect a team to turn out a project? To determine this, sprints should start with a planning meeting during which the product owner defines the work criteria. The development team determines a realistic time frame to complete the work scope. The scrum master or team manager typically makes this call.

    The lengths of agile sprints can vary—some may be two weeks, while others may be 30 days—depending on the scope of work. Most project management experts recommend you aim to keep your cycle length consistent, so teams get used to working within a set amount of time.

    Brainstorming

    Bringing attention to how your team ideates together is an excellent way to build agile collaboration. Brainstorming as a development team fosters collaboration and allows you to aggregate the talent and pull ideas together for the best output, whether you’re trying to solve a niche problem or simply join forces around how best to complete the sprint.

    Garrett recommended bringing people together in smaller groups for round-robin brainstorms and creating as you’re ideating. “Thus, iterations happen fast,” and all team members are given a chance to express their ideas in a tangible way.

    Once citizen developers see success, you can then use the excitement of building applications and solutions together to drive things forward, he said. Your anchor is a cool product that gets people excited—great for both morality and high-quality output.

    When Are Citizen Developers Appropriate?

    The question should be asked: When is it appropriate to call on citizen developers? Garrett recommended performing a suitability assessment to identify the best use cases for citizen developers. This will help the organization understand when it’s smartest to bring them in.

    The easiest way to answer this may be to consider: When isn’t it appropriate? Assigning advanced processes to citizen developers such as algorithm-heavy, mathematically complex programming or core product functionality is usually inappropriate, he said. Instead, utilize citizen developer talent for constructing internal business utilities that can be automated easily.

    There are formal suitability assessment tools that look at scores and attributes for applications to help you make this call. “However, everyone’s different,” Garrett noted. “You have your own ways of working, given context, goals and what you’re trying to accomplish.” So it may make the most sense to perform your own internal suitability assessment.

    Do the Numbers

    According to a recent PMI report, over the past five years half of organizations have recognized team members who brought innovative ideas forward, but:

    • Only 25% required dedicated time for innovative thinking and idea generation.
    • Only 19% hosted a creativity lab or hackathon facilitated by a professional.

    By contrast, their research shows that those promoting innovative practices see stronger results. Case in point:

    • 80% of organizations that encourage project leaders to expand their role have invested in at least one innovative idea in the past five years.

    The trend PMI sees on this front is that organizations want to innovate, but don’t always know how to make it happen. So, how might they push innovation forward? If you can implement a strong citizen development toolset, you can “enable innovation to bubble up,” Garrett said. The hope is this guide offers a blueprint for fostering just that.

  • The Low-Code/No-Code Revolution: Join the Conversation

    The Low-Code/No-Code Revolution: Join the Conversation

    Make plans to take part in the low-code/no-code conversation at an upcoming daylong virtual conference

    MediaOps, the company behind DevOps.com, is excited to announce it will be producing Low Code Today, a new live virtual event taking place Nov. 19. The call for speakers is now open and actively accepting submissions.

    The low-code/no-code market has been growing and evolving for a number of years. With the onset of the COVID-19 pandemic and the need to bring applications to use faster than ever, as well as the increased capabilities of building complex applications with low-code/no-code tools, this area is becoming increasingly important.

    We want to hear your stories: How have the economic conditions during COVID-19 accelerated your digital transformation efforts? What tools are you using to work smarter and faster in a world where building cloud-native applications is quickly becoming a necessity? 

    We’re inviting all professional developers, citizen developers, business executives and creators of low-code/no-code technologies to submit their abstracts before the deadline, Oct. 31. 

    Low Code Today is a free, multi-track virtual event focused on the low-code/no-code market that’s been developing over the past few years but has seen exponential growth in the past six months. We invite those who are interested in speaking to submit their abstracts for one of the following topics:

    • Steering the Charge: Hear directly from CIOs, business leaders and IT managers on their approaches to adopting low-code/no-code from a high-level, organizational perspective. What are the strategic approaches, considerations and challenges with bringing low-code/no-code tools to an organization? How is low-code/no-code revolutionizing businesses? What will the future of app development look like?
    • Learning by Doing: The best way to learn is by doing. Tune in to hear experiences and case studies from customers who have brought low-code/no-code technologies to their organizations. You’ll discover answers to questions such as, How has your company used low-code/no-code tools? What was the impact? What lessons were learned?
    • Enabling the Citizen Developer: Low-code/no-code technologies have given rise to the “Citizen Developer.” These demonstrations, workshops and how-to tutorials will share how low-code/no-code tools can help business users improve processes and increase productivity.

    Whether you’re currently using low-code/no-code technologies or creating tools that can support complex business processes, we encourage you to tell your story with an individual presentation, panel discussion, customer case study, fireside chat or live Q&A session. 

    For more information, please contact inaara@mediaops.com. Sponsorship opportunities are available. Sponsors to date include ServiceNow, Outsystems and Prodly. Click here to submit your session.

  • DevOps Deeper Dive: IBM to ‘Maniacally Focus’ on Hybrid Cloud, AI

    DevOps Deeper Dive: IBM to ‘Maniacally Focus’ on Hybrid Cloud, AI

    IBM this week announced its intention to spin out a new company next year focused primarily on managed infrastructure as part of a plan to focus more on hybrid cloud computing and artificial intelligence (AI) initiatives.

    IBM is combining the Red Hat assets it gained last year via a $34 billion acquisition with its investment in Watson AI technologies, while an as-yet-unnamed company will assume control over IBM outsourcing services currently provided by the Managed Infrastructure Services unit of IBM’s Global Technology Services division.

    IBM CEO Arvind Krishna, appointed last April, on a conference call with analysts said IBM will primarily focus on high-growth opportunities driven by Red Hat OpenShift, Linux, Kubernetes, containers and DevSecOps software technologies that will drive a trillion-dollar hybrid cloud computing opportunity, while the new company will become the world’s largest IT services provider with more than 90,000 employees serving a base of more than 4,600 clients generating more than $19 billion in revenue. Today IBM generates a little more than half of its revenue from those services and claims to have a services backlog of $60 billion.

    The new approach will enable IBM to “maniacally focus” on hybrid cloud computing and AI opportunities, Krishna said. That shift will also create a separate company capable of generating double-digit growth that should result in a higher stock valuation at a time when investors are pouring billions of dollars into software companies. IBM this week disclosed it has 2,400 hybrid cloud platform clients and that the number of larger deals driven by Red Hat software has increased by a factor of two.

    To achieve its financial engineering goal, IBM will incur multiple charges, including $2.5 billion to spin out the new company and another $2.3 billion to set it up.

    IBM has a long history of spinning out companies. In its new form, the company will grow both organically and inorganically as it makes additional acquisitions, noted Krishna.

    The “new” IBM will look and feel a lot more like Red Hat than it will IBM prior to its acquisition of Red Hat, said Mitch Ashley, CEO and managing analyst of Accelerated Strategies Group (ASG).

    “It’s starting to head toward looking more like Red Hat acquired IBM,” he said.

    The degree to which IBM will be able to dominate hybrid cloud computing is unclear. IBM is making case for unifying the management of IT by standardizing on the Red Hat OpenShift platform based on Kubernetes that can be deployed on any public cloud or on-premises IT environments, including those that also house mainframes and x86 servers. In the wake of the economic downturn brought on by the COVID-19 pandemic, the rate at which IT organizations are expected to reduce costs by centralizing the management of cloud computing platforms is expected to increase.

    Adoption of multiple cloud computing platforms in the enterprise has tended to be reactive and any effort to centralize the management of those platforms is still in the planning stages, said Judith Hurwitz, president and CEO of Hurwitz and Associates, a research and consulting firm.

    “It’s not easy,” she said. “It’s not like you can go out and buy a control plane.”

    Ultimately, however, IT teams will have multiple options to choose from that don’t necessarily require them to adopt the Red Hat OpenShift platform.

    Similarly, IT organizations have access to a wide array of open source AI frameworks via cloud services that provide alternatives to Watson offerings.

    In the meantime, the rate at which organizations are transitioning to hybrid cloud and AI platforms is increasing. The issue IBM will need to contend with is making sure it doesn’t become distracted by its own internal issues over the course of the divestiture, which might take well over a year to ultimately complete.

  • New Survey Highlights Codebase Size Problems

    New Survey Highlights Codebase Size Problems

    Sourcegraph and Dimensional Research have released a survey of developers at large organizations, which shows a massive growth in codebase size, number of repositories in use and complexity concerns.

    “The Emergence of Big Code – A 2020 Survey of Software Professionals” is definitely intriguing reading, and a few of the results are eye-opening—such as the difference between what development managers think developers are using to search code and what developers say they are actually using. But most of it simply validates what we all knew: Codebases are growing at an alarming rate, through a variety of growth vectors—support for new platforms, use of open source and internal development. Adding environment to code à la GitOps, systems reliability engineering and/or environment automation is adding a layer of completely new source and a layer of complexity not normally in the developer’s realm of immediate concern.

    I’ve been working with Accelerated Strategies Group over the last few months, and we’re looking at tools in this market. The ability to quickly get up to speed on large codebases and the ability to find a specific area in a codebase that is massive and/or spans repositories is a very real need that is not currently well-served. This piques my interest in what Sourcegraph brings to the table, but at the moment we’re focused on the survey, so perhaps in a future blog we’ll talk about Sourcegraph.

    While there is a lot packed into the survey, I think my favorite part is crammed in with other “What would you find useful?” results (the slide is below). Fifty-eight percent of respondents—all of whom are developers—chose, “Finding code by querying semantic relationships, not just matching a string.” As developers, these respondents no doubt are aware of the complexities of this type of feature, particularly in environments with a variety of programming languages and scripts (be they bash, SQL, whatever) all working together. This is huge, and first iterations would be shallow, but is a worthy goal. I’m intrigued to see how well SourceGraph et al solve it.

    Source: The Emergence of Big Code – A 2020 Survey of Software Professionals

    It is also intriguing to see more than half of respondents want the ability to explore ” … both known and unknown code with code intelligence that provides contextual understanding.” That, too, is a tall order. Code analysis has gotten better over time, but contextual analysis of large codebases is notoriously difficult. I’ll be intrigued in the near future to play with this concept and tools that offer it to see how reliable they are and how much human guidance is accepted and/or required to make it a reality.

    Code change velocity reporting and contextual information about code are both available and pretty solid from the majority of full-stack DevOps vendors. Perhaps that is why that particular response only netted 45% and 43% of responses, respectively—the other 50+% are already using them.

    We’re in an interesting time when consolidation appears to be on the upswing and the needs of developers and DevOps teams working in large codebases are becoming more clear and more complex at the same time. Over the next few years the needs reported in this survey will likely be replaced by more specific needs as these are fulfilled and find general use. The question of databases and database integration in large codebase migrations, for example, has these needs, but has other needs closer to the problem domain. As these general issues are resolved, expect your vendors to turn to those more specific, but every bit as complex, problems.

    And just keep rocking it. Find out what the tools and companies already in use at your org have added, and if those capabilities fit with your needs or can enhance your Dev/DevOps exercises. Keep the lights on, keep customers happy and watch for tools to help you make it even better.

  • Strengthen API Security With These Tips and Patterns

    Strengthen API Security With These Tips and Patterns

    If you haven’t noticed, digital organizations are building more and more APIs. ProgrammableWeb tracks more than 23,000 public web APIs at the time of writing, and the API market is estimated to be worth $5.1 billion by 2023. Building with APIs increases internal interoperability, reduces development time and can extend product functionality tremendously. In short, the value of APIs is rising. However, opening up with APIs brings security caveats that, if not addressed, could result in serious breaches that negate these benefits.

    I recently spoke with Roey Eliyahu of Salt Security to get his take on the top security concerns for API-enabled companies, and how organizations can safeguard their services. In short, he recommends thoroughly cataloging and understanding your API inventory, designing for legal challenges and mitigating OWASP’s top 10 API security vulnerabilities.

    Challenges for API Security

    APIs have been called “the next frontier in cybercrime.” Rightly so, as API breaches continue to pop up nearly every day. Take the recent API vulnerabilities at Cisco Systems, Shopify, Facebook, U.S. presidential campaign apps, and GCP as evidence. The most infamous was likely the Equifax breach—not enforcing formats on incoming API calls resulted in a massive data breach, which cost the company a $700 million lawsuit.

    So, why have API breaches increased recently? Well, a few years ago, there were simply fewer APIs. And, these older services exposed less sensitive data. Nowadays, companies typically have many more APIs. Banking applications, for example, might expose hundreds of highly valuable endpoints that are very appealing to hackers.

    Companies also build APIs for different audiences: A 2020 study by SmartBear found 72% of companies develop both internal and external-facing APIs. These APIs could easily hold hundreds of parameters, and with every new method added, a company’s potential attack surface grows considerably.

    3 Steps To Secure APIs

    To mitigate the above API security issues, Eliyahu suggested three main steps: Understand your API inventory, audit against privacy policies and data privacy regulations, and track the most pressing API vulnerabilities like a hawk.

    Know Your API Inventory

    “You need a great inventory of APIs to know your attack surface,” said Eliyahu. Many API providers document their APIs with OpenAPI definitions. But, these files don’t always match the production realities—they may be manually generated or leave out certain methods. “In every organization, there is up to a 40% gap between APIs that are actually deployed versus what has been inventoried,” he said. By maintaining a clearer API inventory, organizations can avoid unprotected shadow IT.

    Include Legal Auditing

    A change to an API could result in a change in how it collects user information. Updates involving sensitive data could break privacy policies or regulations such as GDPR. “After you have an inventory, you need to map all parameters manually,” said Eliyahu. He recommended performing a legal audit against your API inventory and establishing a repeatable testing process that plugs into a continuous delivery pipeline.

    As API teams release new updates, they must consider security and legal implications earlier on in the development flow. “Now, with CI/CD, these changes have to happen very frequently,” he noted.

    Watch the OWASP API Security Top 10

    There are many known API security gaps. For example, there may not be proper authorization in place, keys could be exposed, unexpired tokens could be hijacked and so on. Thankfully, OWASP has compiled a resource of top API security vulnerabilities, which Eliyahu and many others in the API economy have rallied behind. “The world should move to adopt the OWASP issues,” he said. These vulnerabilities are as follows:

    1. Broken Object Level Authorization
    2. Broken User Authentication
    3. Excessive Data Exposure
    4. Lack of Resources & Rate Limiting
    5. Broken Function Level Authorization
    6. Mass Assignment
    7. Security Misconfiguration
    8. Injection
    9. Improper Assets Management
    10. Insufficient Logging & Monitoring

    Using AI To Go Beyond ‘Whac-A-Mole’

    Plugging these above holes is a good start. However, these are only defensive measures against known patterns; they aren’t helping you keep guard for nuanced attack types. Ideally, security systems should stop cyberattacks before they even get started.

    Yet, Eliyahu recognizes a big gap in how APIs are monitored. Organizations “don’t have proper tools to know who is looking for vulnerabilities,” he said. “Tools are typically not that advanced. They mainly look for injections and known patterns.”

    Imagine a hacker probing an API. They will likely do so by trial and error, testing undocumented endpoints, sending malformed requests and so on. “They need to probe for hours or days before they find something,” said Eliyahu. If an AI could detect these odd attempts in minutes or seconds, IT could significantly reduce risk.

    Security solutions should thus leverage big data and AI to create baselines of typical behavior, then deter malicious activity the millisecond any nefarious probing begins. Eliyahu said such a security AI must consider dozens of behaviors such as, How is the API being accessed? What parameters are being used? What are the relationships between parameters? What is the flow of API calls? What type of data can be exposed?

    Instead of waiting for a breach to occur, an AI-enabled API security monitoring could instantly pause behavior deemed “out of the norm” by referencing a knowledge base that’s constantly refined using machine learning. Because, if you are only blocking malicious actors without knowing how you need to improve API security posture, “you are just playing Whac-A-Mole,” said Eliyahu.

    DevSecOps Requires API Security Forethought

    Mark O’Neil, analysis at Gartner, predicted that by 2021, 25% of organizations with public APIs will have discontinued or rebooted their public API strategy, citing security concerns as a common breaking point. APIs are now at the core of many application developments. Yet, without the proper DevSec proposition, teams risk wasted efforts and costly breaches.

    To summarize, here are our tips on API security:

    • Ensure everything is well-documented: API inventories cannot be audited if undocumented. Shadow APIs increase the likelihood of an attack.
    • Watch the top 10 OWASP vulnerabilities: These points are foundational to API security. Though not a cure-all, they present a starting point.
    • Build a security and legal review process: Ensure APIs are never deployed without the proper security review. Create validation systems that plug into continuous development processes, so new versions are never breaking privacy policies.
    • Each API is unique: Another thing to keep in mind is each API is unique. Therefore, API security monitoring also requires more context into unique business logic.
    • Continuously monitor your APIs: Continuous search for anyone looking for vulnerabilities.
    • Remove deprecated APIs: Remove old API versions. “You need a mechanism to identify and remove old API versions.” Otherwise, “zombie APIs will bite you!”
    • Learn from the attacks you block: Don’t just play Whac-A-Mole. “You need a mechanism to learn from attacks you block.”
  • Recruiting Pro Tip: Treat External Recruiters As If They Work for You

    Recruiting Pro Tip: Treat External Recruiters As If They Work for You

    The best recruiters are salespeople. Just because you have hired a salesperson does not mean they are going to know how to sell what you have to put out on the market. So many people believe that once you have hired an external recruiter the job is done—they will go out and find the right people for you.

    Sure, most recruiters spend half an hour talking with someone in HR about what they should be telling candidates about the company and the position. They might even have a half-hour chat with a hiring manager. This is not enough—not even close to achieve what you hired these folks to do.

    The technologists you want to hire have other offers or are happy at the jobs they have. To hire them, you have to sell—you have show them how your mission and your work environment are right for them. As the hiring manager, you may be great at this, you may be able to enthusiastically present this to anyone. But just because you can doesn’t mean your recruiters can!

    Here is what you need to remember: Salespeople need to be sold. It’s easy to sell a product you believe in. That belief can’t just be bought—the salespeople you just hired to find and attract that hard to get talent need to be sold, too.

    If you want them to believe in the product, then you need to show them what the product is all about—and, remember: A big part of the product is YOU, the hiring manager. You need to make sure your recruiters care about you, the position and the company.

    Here are four ways to sell the salespeople and get them working harder and more effectively for you:

    1. Bring them in for an office tour. Introduce them to key players and let them get a feel for the culture. If you don’t have an office, then set up a videoconference meeting and let them meet the team and ask questions. Make this an enthusiastic, fun meeting. It’s easier to sell something if it’s tangible, if you have seen it.
    2. Spend at least an hour going over the mission, the company and what you are looking for. Have them give their pitch back to you to make sure they know the ins and outs.
    3. Give them your cellphone number. Show them you care and they are at the top of your list, and be there to unblock anything that gets in the way or their success.
    4. Continue to build the relationship over time: Have regular meetings. Bring them to a company happy hour. Don’t assume the job is done because you started off right. Successful external recruiting is a relationship, not a transaction.

    If you help them understand and care about the company like an employee and show them you care just like you would an employee, external recruiters will work harder and smarter for you than anyone else.

    Looking for the right talent? Please visit recruitops.com and learn how our talented recruiters can help you find the right fit for your team.

  • 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).

  • New ASG Report Looks at COVID-19’s Impact on Software Development

    New ASG Report Looks at COVID-19’s Impact on Software Development

    We are all trying to adapt to a new world created by COVID-19. As the coronavirus continues to spread, the economy and businesses everywhere have been severely impacted, and no one really knows what the so-called “new normal” will be. For now, most organizations have gone remote, not knowing when—or even if—employees will be able to return to their offices.

    While some organizations have been open to the idea of working remotely, many have also struggled to shift to a remote workforce seemingly overnight. For software developers, however, remote work is nothing new. Many developers have successfully worked remotely before the COVID-19 pandemic even started.

    “The Future of Remote Work and Software Development“ research published today by Accelerated Strategies Group dives into the long-term impact of a decentralized workforce on software development and delivery. ASG interviewed 347 industry leaders from around the world to gather and refine data on the impact of COVID-19 on software teams and their organizations’ ability to create software, and the importance of remote work tools and applications during the pandemic.

    The ASG report, commissioned by CloudBees, revealed some interesting trends. The survey found 63% of respondents said digital transformation objectives have significantly or somewhat increased in priority. Business automation (61.6%) and the need for investment in creating contactless services (60.1%) have increased somewhat or significantly.

    More than half of the respondents said the COVID-19 conditions have increased their focus on DevOps initiatives (51.75%) and increased their progress on cloud migration (52.25%). Also worth noting is the growth in companies’ DevOps and Agile adoption, with 46.24% of respondents stating they are using cross-functional teams, 55.64% practicing daily stand-up meetings and 43.23% automating tasks.

    The majority of respondents (59.49%) to the ASG report saw an increase in productivity on software teams since the pandemic started. Forty-two percent of respondents said it has become somewhat easier to complete their work tasks in a timely manner.

    However, feedback concerning respondents’ ability to manage unproductive distractions was mixed: 39.7% said managing these distractions was somewhat or much easier, 36.36% said it was somewhat or much more difficult and 23.48% said they had no change in their ability to manage these distractions.

    When asked to provide insight into the potential negative impact of their remote workforce on productivity, more than one-third (38.6%) of respondents said there was no change, 27.58% of respondents indicated that teams were slowed down significantly or somewhat and 33.83% said things moved along significantly or somewhat faster.

    The majority of remote workers (64.4%) expect to remain working remotely, either permanently or at least three or more days per week, once COVID-19 restrictions are lifted. Only 12.7% said they anticipate returning to an office location full-time.

    For the most part, the transition to working from home has benefited software teams. COVID-19 has not only impacted the global economy, but also business priorities and has accelerated business and software strategies. Though the future is uncertain, and no one has a clear picture of what the “new normal” looks like, there is a huge possibility many software and DevOps teams won’t return to the office—at least not full-time.