devopsy.kinsta.cloud

Tag: developers

DataOps: Time to Bring DevOps Ideas to Big Data

What can data scientists learn from DevOps? A lot, actually. By applying DevOps principles to the world of big data, you get DataOps, which streamlines data analytics.

If you’re reading this site, you’re probably already familiar with DevOps. The DevOps philosophy emphasizes continuous collaboration between software developers (the “dev” people) and system admins (the operations, or “ops,” folks)—as well as everyone in between, such as software testers.

It’s possible to apply similar ideas to the world of big data and data analytics. There, as in the world of software development and delivery, different teams traditionally have worked in isolation from one another. Those teams include storage admins, who keep data storage systems running; data analysts, who write and execute programs for interpreting large volumes of data; data quality specialists, who ensure data consistency; and data security teams, which protect data from attackers.

As DevOps professionals know, keeping different teams isolated from one another is not efficient. It limits collaboration and maximizes confusion when problems occur.

The data world, therefore, has much to gain by ending this isolation between teams and adopting a DataOps workflow. This will keep data operations flowing smoothly and provide continuous insight into the data that organizations collect.

DataOps is not a brand new concept. People like Andy Palmer have been writing about it for a little while now. But the term and the idea have yet to gain nearly as wide a following as DevOps. (There is not yet even a Wikipedia entry for DataOps—and you know an idea is still in its infancy when no one has taken the time to write about it on Wikipedia.)

Making DevOps Bigger

Meanwhile, from the DevOps perspective, the growth of interest in DataOps is significant because it exemplifies the broad applicability of DevOps principles. So far, the DevOps conversation has focused on the relatively narrow context of software development and delivery. But it can extend much further, too. DataOps is a start.

So, if you’re a data analyst, storage admin, data security professional or someone who works with data in any other capacity, it will be worth your while to borrow some ideas from your DevOps brethren. And if you work in software development, testing or delivery, it may be worth your time to educate your data friends on DevOps principles. It will make their workflows more efficient, while introducing DevOps to a wider audience.

— Chris Tozzi

October 13, 2016
Keep Applications Running by Testing Early, Continuously

Almost every product we buy or use today goes through some form of extensive testing before it’s released on the market; typically, these tests are designed to replicate the worst-case scenarios that a product may encounter under real-world conditions.

Automobiles, for example, go through extensive hot and cold weather testing in remote locations, and are driven over obstacle-laden tracks designed to push the limits of their durability. Even seemingly mundane objects such as children’s toys are exposed to abusive simulations to ensure that they don’t harbor any potentially hidden and harmful effects.

On the current landscape, applications are the face of your business, often serving as the battleground where consumer loyalty is won or lost. Given this reality, it seems crazy to think that any applications are released having only been exposed to a minimum of tests. Yet, in the name of getting to market quickly, that’s far too often the case.

As disciplines including agile and continuous delivery continue to increase the speed at which development teams can release software, it’s easy to put the crunch on testing in the rush to get an update released. But that’s a costly mistake in the long run, as research has shown that it is 50 percent less expensive to find an error in testing than to address the same error once it has reached production, and more than 90 percent cheaper when addressed in the development/coding phase.

Given the dramatic cost savings of addressing errors in development, clearly the goal of any organization focused on continuous delivery should be to shift testing left so a greater number of defects are found early in the development process. This is what we refer to as continuous testing, and it’s a huge part of the reason why I am so excited about CA’s acquisition of BlazeMeter.

Performance load testing should be a core element of any continuous testing strategy because it is a critical factor in determining system reliability. Similar to the worst-case scenario testing that consumer products undergo, performance testing can quickly uncover applications defects that might otherwise go unnoticed. After all, the manner in which a system operates with a few hundred concurrent users may be very different than how it runs with thousands of users.

BlazeMeter enables today’s development, operations and DevOps teams to conduct this critical performance testing earlier in the development process, saving countless hours and resources. The company is also competing—and winning—in a highly competitive marketplace where it has been pitted against much larger, more entrenched competitors.

Part of the reason BlazeMeter is winning is its focus on offering a SaaS-based solution that is highly cost-effective and easy to engage. Using this model, customers can try out the testing software with a few clicks, and then quickly move forward to broadly adopt the system. Another catalyst to its success: BlazeMeter was built using open source tools, such as Apache JMeter, used widely in the development community for performance and load testing. As a result, BlazeMeter can easily run and analyze JMeter and other open source-based load tests—such as Selenium, Gatling and Locust—within a commercial-grade performance testing system.

This combination of a SaaS delivery model and incorporation of open-source tools, augmenting strong performance testing functionality, make BlazeMeter very complementary to CA’s existing continuous delivery solutions, including its CA Service Virtualization, CA Test Data Manager, CA Agile Requirements Designer and CA Release Automation products.

At CA, we’re committed to providing the most comprehensive, integrated and open continuous delivery ecosystem, allowing our customers to release swiftly, test agilely and constantly increase reliably. The addition of BlazeMeter will further enable customers test continuously, thereby increasing agility and the overall quality of their software, to ensure that applications don’t break down on the side of the virtual road.

— Aruna Ravichandran

October 12, 2016
Get to Know the New DevOps Stack

Deploying software has always been manual and labor-intensive. That’s fading into the past as continuous innovation has become a competitive differentiator for companies of all stages and sizes across every industry.

DevOps has become a hot investment market in recent years. The mega-rounds we’ve been seeing show the massive demand for tools that enable optimal runtime. Moreover, IT leaders are ready to spend to promote the DevOps culture.

Companies increasingly are turning to DevOps processes and tools to automate the development life cycle and position themselves to adapt and scale nimbly. But for some companies, the idea of completely overhauling their IT operations processes can seem daunting—they don’t know where to begin. The thing is, adopting DevOps is actually quite simple.

Examining the Stack

Developers should bake in automation and agile development from the beginning. The good news, though, is that a defined set of tools to automate each step of the deployment process has emerged. Here’s a breakdown of the new DevOps stack, layer by layer:

Source Code Repository: Let’s start from the bottom of the stack—from the moment you write the first line of code. Before the open-source movement took off and the cloud enabled easy sharing, developers had to work much more slowly to ensure that the necessary improvements were inserted in the right version of a product. Companies such as GitHub, Atlassian and GitLab provide source-code repositories that facilitate collaboration. Now, engineers can work on the same projects at the same time from halfway around the world without worrying about duplicating efforts.

Continuous Integration: Newer tools such as CircleCI and TravisCI, as well as older tools such as those offered by Jenkins, automate testing and integration and provide repeatability in the deployment process. Using these tools, developers are able to test their code for failures and bugs as they write it so the code can be fixed before users ever experience the bugs. CI tools give developers something they desperately need to succeed in today’s competitive marketplace: timely feedback. By spending less time waiting on feedback for new code, engineers can resolve software bugs before they grow into full-scale crises.

Binary Repository: Jfrog and Sonatype provide an end-to-end solution for storing and managing binary artifacts. The binary repository is the system of record closest to the production runtime environment. When something goes wrong, a binary repository such as Artifactory is the first port of call for operations teams. In addition, these tools scan for security vulnerabilities and make it easy to seamlessly distribute software to every corner of the globe.

Continuous Development: Companies including Chef, Puppet and Ansible automate the next phase of taking data into production. The holy grail for software developers is zero downtime; continuous development tools allow developers to update software while everything remains up and running. These tools also streamline the delivery process by automatically configuring servers and ensuring repeatability of the deployment process.

Production Environment: Google Cloud, Amazon Web Services and Microsoft Azure are in a war over runtime market share in the public cloud. Behind the firewall, Mesosphere, Kubernetes and Docker are trying to dominate the orchestration layers of enterprise private clouds. Customers want the agility and automation that comes from a cohesive DevOps stack but are refusing to be locked into a single vendor at any level. Whichever stack emerges as the default DevOps stack will have to ensure compatibility across public and private clouds.

About the Author / Andy Vitus

Andy Vitus is a Partner at Scale Venture Partners. He has been investing with Scale for over 12 years and focuses on next-generation enterprise software and new data center technologies, including virtualization and cloud computing. Andy sits on the boards of Arena, Crittercism, DataStax, JFrog, PubNub, Realm Stormpath and Treasure Data. Connect with him on LinkedIn and Twitter.

October 6, 2016
Network Resilience and Security from A to Z

An observer watching a bunker shot by legendary pro golfer Gary Player was heard to say: “I’ve never seen anyone so lucky in my life.” The player retorted: “Yes, and the more I practice, the luckier I get.” Yet, when it comes to cybersecurity, nearly half of organizations are solely relying on luck to get them through a cyberattack.

There is not enough practice or training in terms of incident response, and testing happens haphazardly depending on the developer and organization—obfuscating baselines and the context necessary to ensure security and resilience. Particularly in terms of testing, we’ve noticed that despite awareness of its importance, bugs and vulnerabilities routinely slip through. In fact, a recent Ixia survey found that 34 percent of developers have deployed products that have had a few bugs. Worse, 31 percent said products harbored significant vulnerabilities that required patching later in the cycle when shipped.

The problem has been exacerbated by the rapidly growing normalization of agile development processes. Groups of developers are tasked to build products piecemeal, leading to application development that is often incremental and happens in iterative cadences. Testing and oversight happen at each step of the process, but the segmented nature of the development cycle means that bugs and vulnerabilities often arise when the code is assembled, and are routinely missed. For instance, the average IT web application had 32 vulnerabilities, according to recent WhiteHat Security report. It’s clear that more than a local test—a comprehensive end-to-end test—and relevant training are critical.

A Change in Culture

Improvement begins by changing the culture that minimizes security testing for the sake of launch timelines. Too often, the product development team will come together just to be told they need to move up their release date. The habit results in products that walk a thin line of performance, as they may contain unknown security holes due to not being fully tested. Just consider the slew of IoT devices and services that have been proven to be vulnerable because of this habit—from cars to coffee machines to cameras. It’s a major reason for security incidents, even with multiple layers of security tools.

This also requires the right training. Having seemingly secure code and the right security measures is not enough for a strong security stance if proper training is not implemented. Organizations need to learn how to respond. Yet, recent SANS Institute research into the incident response capabilities of companies worldwide found that 43 percent of respondents did not have a formalized incident response plan, and 55 percent didn’t even have an incident response team.

This less-than-vigilant approach to system-level security can have worse implications once a product goes live in the network. For instance, updates, patches and configuration changes applied when a new feature is added can reset an organization’s security posture, and this sometimes goes unnoticed—leaving gaps for threat actors to exploit. Or sometimes a machine fails to update and becomes and entry point, as experienced by JPMorgan Chase. Continuous testing and training from the very onset of operation and throughout a tools lifespan are imperative for all employees, especially IT and security pros—even in its simplest iterations.

What to Look For

Successful and continuous testing and training expose security and IT pros to anomalous activity they’d not be able to recognize otherwise. It’s necessary to be able to answer questions such as, “What does suspicious activity look like on my network?” or “What security alerts require immediate action?” The more they see, the more refined their eye becomes—it’s all about a proactive approach paired with repetition.

Which raises the question, what is considered a good test? It starts with accurately reflecting the widest range of attack types in live operation. It is also important to create an accurate sandbox to test in so that it can be as close to reality as possible. The more accurate the environment, the better prepared IT and security teams will be. Realistic depictions better prepare employees as new malware, phishing and DDoS attack types emerge every day—not to mention it helps keep up with evolving typical application behavior.

More specifically, function and system testing should be at the heart of any program following the development cycle test process. Quality of service, performance and resilience all benefit, along with security, as a result.

Some companies take shortcuts, such as using internally generated attacks or crowdsourced probes to attack their networks. Just as bad, some have the development team create and run their own test scenarios. While this can give the illusion that everything is good, it creates a false sense of security—a single scenario only protects you from one type of attack.

The key is not to stop at the minimum when it comes to security testing and training. Developers spend lots of time building great features; why not spend time training teams on how to use them? Limited or biased tests can easily overlook glaring flaws.

Ultimately, the right approach to testing can make networks robust and prepare IT teams for real-world attack situations, helping minimize response times and the negative impact on the business. As breaches now seem to be coming from every direction, testing needs to come to the foreground, from the development stages to when products sit directly in the line of fire.

About the Author / Jeff Harris

Jeff Harris is VP, Solutions at Ixia, leading solutions marketing for Ixia’s security portfolio of products and capabilities. As a former product development leader of advanced networking, communications, and surveillance products for commercial and military applications, Jeff has a deep appreciation for security implications that occur in development and operation. Jeff has led first to market product teams in personal area networks, mobile ad hoc networks, and a wide range of surveillance equipment and platforms. Connect with him on LinkedIn and Twitter.

September 30, 2016
Big DevOps: Too Slow to Win?

There’s DevOps. And then there’s Big DevOps.

DevOps is a set of disciplines that accelerates time-to-value for digital deliverables. It is being embraced by all kinds of companies, from pure-play digital market disrupters to mainstream corporates trying to maintain competitive parity with their mobile apps.

Big DevOps is something else entirely. Big DevOps resembles mainstream DevOps, because it’s a process by which companies bring code to market. But if you’re a game developer or large bank, your code bases are massive—and your software life cycle requires you to distribute those massive code bases across globally dispersed dev and test teams.

Distribution of massive code bases on a global scale creates time-to-value challenges that are totally foreign to programmers checking bite-sized blocks of work in and out of GitHub. These scale-related distribution challenges chronically delay DevOps workflows—impeding your company’s digital agility and seriously undermining your ability to compete in today’s time-gated markets.

So you must overcome your Big DevOps code base distribution problem.

Choking on Code

The main culprit responsible for the slowness of Big DevOps is the network. It just takes too much time to push a massive code base through the relatively narrow pipe of an enterprise network. Even if you spend lots of money on bandwidth and network acceleration, the ratio between your bits of code and your bits-per-second of network is untenable. Every distribution of every large code artifact gets delayed. Over and over, day in and day out.

Those days add up. And when you pile days lost due to network-related delays on top of the other delays that plague large, complex software projects, you wind up persistently late to market.

And cloud alone can’t help you. Globally dispersed teams can’t work on a massive code base in the cloud. They have to work with it locally. So you have two problems. First, all your teams all over the world have to keep downloading and uploading massive files. Second, you have to make sure everything everybody does everywhere stays synced.

That’s why you need a much better way to globally distribute massive code bases.

Work Locally, Dedupe Globally

That better way is a hybrid hub-and-spoke model that lets you maintain a “gold copy” of your code base in the cloud—while giving everyone everywhere a local copy that is continuously updated with any changes to the current build. This approach eliminates network-related delays while ensuring conflict-free collaboration across geographically dispersed teams.

It’s a simple approach that works. In fact, it’s been used by CAD/CAM teams for years to address a very similar file distribution problem.

Hybrid cloud hub-and-spoke also saves money—because you can spend less on your network and your local storage infrastructure.

Cost, however, is not the existential issue facing Big DevOps. Time is. Companies that are slow to market with their digital deliverables can’t win against fast ones. So if your company is big—and if you’re doing Big DevOps—you have to solve your time-to-market problem. The realities of digital competition demand it.

— Barry Phillips

September 29, 2016
Empower Developers to Build Security into DevOps

Over the past 10 years, as more organizations have made the transition to DevOps, there has been a cultural shift in which security and development teams agree quality is a priority. Yet, even with a shared quality focus, Development, Security and Operation teams still find themselves at odds on the road to continuous delivery of secure software.

Some people claim developers don’t care about security. The reality is they want to write great code that’s secure code, but often they don’t have access to tools that fit with the way they work.

There’s also tension between different sets of expectations and performance metrics for different teams. Developers are graded on their ability to deliver features and functionality to market as quickly as possible, while security engineers focus on prevention and detection. Operations teams, meanwhile, focus on reliability, uptime and stability.

Development managers feel pressure from senior management to avoid project delays. At the same time, security managers aren’t rewarded for reducing risk and may be asked to turn a blind eye and give the application a temporary pass so the project can move forward.

Prioritizing delivery to customers over security creates real dangers for the business. Veracode has found that 63 percent of internally developed applications are out of compliance with the Open Web Application Security Project (OWASP)’s Top 10 standards when initially assessed for security. And, attackers increasingly target the application layer, with web application attacks now the most frequent pattern in confirmed breaches, according to the 2016 Verizon Data Breach Investigations Report.

Empowerment = Security

Regardless of where your team is in the DevOps journey, you’re likely aware that detecting and fixing quality issues as early in the software development life cycle (SDLC) as possible increases efficiency and reduces costs. According to the Puppet 2016 State of DevOps Report, “high-performing development teams spend 50 percet less time remediating security issues” when they address security throughout the SDLC, instead of “retrofitting security at the end.”

While you want to find and fix bugs early in the SDLC, early detection of coding flaws has the unintended consequence of distorting an application’s risk posture. Development is once again in the hot seat, despite trying to do the right thing and testing new versions of an application early in the life cycle.

There is a middle path that can allow development to deliver more secure code at DevOps speed, but it requires automating security into the SDLC and into a continuous integration or continuous deployment (CI/CD) pipeline. Integrating security into the pipeline ensures that security testing happens with every release, and avoids the problem of bolting on application security late in the process.

This method has the ability to scale easily as more applications are developed. The release engineer adds a step in the CI/CD build workflow for an application security scan from the master branch. The assessment can take place in parallel to the CI/CD workflow process and any security issues can be loaded automatically into the defect tracking system that development teams already are utilizing for functional testing. Security issues are prioritized and resourced just as any quality issue.

The best way to catch software defects quickly is to analyze code as close to the time that it was written as possible. Security assessment, such as functional testing, “follows the code” through the application life cycle. During the development phase, developers analyze code in the IDE and develop unit tests that will find issues relative to their individual code changes. At this phase, developers receive immediate feedback while coding a feature, allowing developers to remediate basic issues when they are least expensive to fix.

During the build and integration phases, when a development or feature branch is merged into the master branch, compilation and integration tests are executed automatically by the CI/CD workflow. Issues detected at this stage are visible to the larger development team. No developer wants to be the one who “breaks the build” or has a basic defect that should have been detected during development phase. The integration testing is critical because functional and security tests are able to detect issues resulting when data and control flows between components. Coverage of the application expands and developers still have the time to fix before code goes moves to the next phase.

Enter Infrastructure as Code

“Infrastructure as code” (IAC)—the concept of managing, provisioning and configuration of development, QA, pre-production and production environments in a repeatable automated methodology—provides consistency that previously was challenging when each system was provisioned and configured independently. Product teams using virtual machines (VMs) or containers are able to advantage of this model more easily.

Even for those product teams that cannot take advantage of IAC, teams can still automate the deployment and configuration of the application. This becomes particularly important during systems/pre-production testing, where finding issues takes longer to remediate and the complexity increases as the application integrates with other systems. At this point in the life cycle, system and pre-production tests are automated when possible, and QA engineers and user acceptance testers may run end-to-end tests. Running security assessments at this stage is just as important as functional tests. True, fixing issues at this stage will be more costly to fix than during the development phase. But by this point the developers have been incorporating quality throughout the process and the number of high-priority issues will be significantly reduced.

Empowering developers to find and fix quality issues earlier in the life cycle provides them with the knowledge and skill set to more efficiently fix defects where it is less expensive and disruptive to their coding.

About the Author / Janet Worthington

Janet Worthington is senior product manager at Veracode, working on solutions to help developers and development teams smoothly incorporate security into the application development life cycle. Janet joined Veracode in 2012 as senior program manager, delivering Veracode’s secure development solutions to Fortune 100 companies. Prior to joining Veracode, she led software quality assurance test teams at a number of startup technology companies. Janet has over 19 years of experience in software product development and services. Connect with her on LinkedIn and Twitter.

September 26, 2016
Q&A: BDO’s Coffman on Change Management, Security and DevOps, Part 2

As we covered in part one, DevOps’ best asset and biggest risk factor may be one and the same: swift and precious change. In part two, we continue our discussion of the challenges and solutions with Deena Coffman, managing director of BDO Consulting’s Technology Advisory Services practice.

David Geer: What specific tools and technologies can help DevOps teams to address change management in these ways?

Coffman: There are a variety of tools and technologies to address some of the inefficiencies in change management, allowing DevOps teams to automate most of the process. For example, teams can leverage change management software to build pre-authorization processes and workflows to speed up change management approvals. On the security side, infrastructure monitoring tools will alert an organization when a discrepancy is discovered on the network, providing application visibility to the users and monitoring for unauthorized changes. DevOps teams should also consider using a collaboration platform like Slack to improve communication via virtual meeting places.

Geer: What will these tools accomplish and how should teams be using them?

Coffman: These tools are only useful if used properly. Deployments that require change management approval can go through the automated workflows. If a change requires approval, developers can use Slack or any other collaboration platform to contact the required party and explain the reasoning behind the modification. DevOps teams must also take the time to identify and automate as many “standard” changes as possible to reduce the reliance on change control meetings to speed up their deployments.

Additionally, DevOps teams need to consider using an infrastructure monitoring tool to ensure all changes to the production environment are known and authorized. If a change finds its way to production without getting the appropriate authorization, the monitoring tools can detect it and report it to the team so they can rectify the issue.

Geer: What kinds of things do DevOps teams need to do to address security to the satisfaction of the business?

Coffman: The development team and security do not need to be at odds. By working in unison, both sides can reach their objectives.

The InfoSec team would help the development team by making efforts to reduce the latency of security projects. The development team would help not only the InfoSec team—but potentially the entire organization—by preventing an expensive and embarrassing security incident by diligently supporting tools that automate security checks.

Additionally, the build process needs to run unit testing, integration testing, functional testing, regression testing and information security testing before the code reaches QA. Security testing is often insufficient or not performed at all. DevOps teams need to understand that security testing performs an important function of catching issues early so as to avoid expensive, embarrassing issues downstream.

Geer: What specific tools and technologies can help DevOps teams to address security in these ways?

Coffman: Several tools are available to help DevOps teams address security in many different capacities, including setting up continuous integration/continuous delivery processes, automating server configuration, automating UI testing and functional security tests, testing the security requirements of applications and automating the vulnerability scan of applications and infrastructure.

Geer: What will these tools accomplish and how should teams be using them?

Coffman: DevOps teams should integrate these tools as part of their continuous delivery process. As soon as a developer checks his code in, the continuous delivery system should run the functional security tests, non-functional security tests and the security scan to ensure that the developer did not introduce a security vulnerability to the application and the infrastructure. These tools are only as powerful as the test scenarios they run. Therefore, teams should write exhaustive test cases to ensure the security of the application.

Geer: How can teams do all these things and still maintain all the benefits and expectations that people have of DevOps itself?

Coffman: By deliberately working toward improved collaboration and communication, teams can take advantage of the integration and efficiency benefits of a DevOps structure without sacrificing security or quality. Technical knowledge is important, without a doubt. To be exceptional, though, teams need equally strong teamwork and communication skills to actively support all important functions in the organization.

— David Geer

September 16, 2016
Introducing DevOps Express!
The DevOps Institute (DOI) is proud to join industry leaders as a founding member of the DevOps Express. The DevOps Express is a bold initiative between tool providers and others to create a solutions-oriented approach that will make enterprise DevOps adoption easier using popular technologies spanning multiple solution components. Working together, DevOps Express members have committed to improving interoperability within the DevOps stack, and creating a framework for industry partners to develop reference architectures that will be better integrated with better support.

The 14 founding members of DevOps Express include vendors spanning multiple solution categories in the software delivery process, as well as service organizations providing consulting, training and professional services:
- CloudBees
- Sonatype
- Atlassian
- BlazeMeter
- CA Technologies
- Chef
- DevOps Institute (DOI)
- GitHub
- Infostretch
- JFrog
- Puppet
- Sauce Labs
- SOASTA
- SonarSource
DOI is honored to be a part of this important and innovative program. We believe this initiative represents the industry’s commitment to “walking the DevOps walk” by agreeing to collaborate, align and integrate for the betterment of the market. We are excited that major industry partners are unifying to give enterprises potential starting points for creating a DevOps stack, while also increasing quality and lowering risk. As knowledge, best practices, architectures and models emerge from the work of DevOps Express, DOI will ensure that these are available to the DevOps learning community and embedded into DOI courses, articles and future member benefits.

The DevOps Express is leaving the station, and DOI is on board! Read the press release for more information about this historic initiative.
September 14, 2016
Tasktop Survey Shows Customer, Business Needs Must Align
Recently, Tasktop surveyed 120 global IT professionals on their software delivery processes. The results were based on analysis obtained from its licensed Forrester Modern Application Assessment Tool, which helps organizations evaluate where they fall on the spectrum of modern software delivery and offers insight into what needs to happen next.

The survey covered topics such as customer needs, application development and delivery objectives and strategies, business value, metrics, tools and more.

Key Findings

In spite of the increasing adoption of agile and DevOps initiatives, the survey identified the need for stronger alignment with customer and business needs and tools that increase coordination in the software delivery process.

Developers, tech leads, project managers, chief technology officers and other IT titles surveyed reported the following:
- Only 6 percent strongly agreed they could trace the contents of a software release back to business needs or customer satisfaction.
- Just 9 percent strongly agreed their application development and delivery strategies were aligned with business strategies.
- And, strikingly, a scant 15 percent strongly agreed their work management tools assist in coordinating the work of the software delivery team satisfaction.
It seems that in spite of a strong industry drive toward being more responsive to the the needs of the business, there remain large gaps in how organizations realize the benefits of the tools they use to support these initiatives.

Any parties interested in taking the survey and receiving an assessment can do so here.

About the Author / Betty Zakheim ‎

Betty Zakheim is vice president of Industry Strategy at Tasktop and is the vertex between Tasktop’s customers, the company’s product team and marketing team. She has an extensive background in software development, software integration technologies and software development tools. As a software development manager, she was an early adaptor of “iterative development,” the precursor to Agile. As the VP of product management and marketing at InConcert (acquired by TIBCO), she pioneered the use of Business Process Management (then called “workflow) as the semantic framework for enterprise application integration. Connect with her on LinkedIn and Twitter.
September 14, 2016
Communication Skills Matter in DevOps

While the precise definition of DevOps is an evolving matter, a simple way to describe it is this: DevOps is a change of mindset toward an agile and inclusive approach to IT. DevOps enables IT professionals to think and work beyond technology silos, thereby deriving meaningful results at a faster rate than with more traditional methodologies.

This involves going outside of our comfort zones and collaborating outside the confines of our own cliques. By working across operational boundaries, DevOps will require an understanding of technical, operational and service aspects of the business. This means the heart of DevOps lies not in technology, methodology nor administration: The heart of DevOps lies in communication, which brings all these together.

DevOps professionals seem to agree. In Incapsula’s DevOps Salary Survey conducted in 2015, the California-based cybersecurity firm identified communication skills as one of the highest priorities for DevOps professionals, almost as much as operational skills.

In other words, effective communication across the organization is considered as important as actually building the product, and it is integral to building the product itself. This means when you’re in the field of DevOps, a smart investment in communication skills will pay off for both individuals and the team.

Communication Fosters Teamwork

There usually exists a disjoint between technical and non-technical departments, particularly in technology companies. Engineers, for example, might be fascinated by an elegant piece of code, an algorithm that automatically governs a process or an infrastructure that does exactly what it’s supposed to do. But to the rest of the organization, those things take place purely in the background and work best when they aren’t noticed at all.

Tech people take pride in the technology, while operations people take pride in business results. The two often find themselves at odds due to a lack of communication about what is really needed, and how to get there. Successful communication in DevOps focuses on finding common ground and working toward achieving this.

For communication to be effective, the emphasis should be on the user of your message. You’ll need to have a deeper understanding of where they’re coming from. No amount of expertise matters if you can’t convey it properly. You can’t gain any growth or value for your career or organization if there is always a unidirectional disconnect.

Bottom line is, you need to correctly identify your intended recipients and find a common ground to better engage.

You Can Increase Your Value as a DevOps Pro

Trust is an essential component of teamwork, which is also important in the development life cycle and in decision-making processes. Being a communicator enables you to better establish trust among your colleagues—something that, unfortunately, is lacking in many IT project life cycles.

This is why pure technologists don’t necessarily make good DevOps professionals—an observation highlighted by the Incapsula survey, which shows that a mix of general and technical skills are essential for a successful DevOps career. In fact, general skills are usually more important in securing higher-paying jobs in this field. These include understanding business operations, developing communication skills and remaining flexible and open to change. In addition, the rising trend in outsourcing DevOps pros across a global talent pool means your communication skills have to transcend languages and contexts.

A good DevOps professional knows that value is not just about the technology, but rather about the product. Even the best technologies in the world are just abstract concepts until you translate them into a product people can actually use and enjoy. Thus, going beyond technical capabilities, you will need to know how to collaborate to transform technologies into useful and marketable products.

You Can Advance Your Career Faster

Chatting up the project managers, glad-handing the operational staff and picking the brains of departmental leaders may not come naturally to pure technologists. However, for DevOps professionals increasingly engaged in conversations across the enterprise, knowing the language unique to the organizational culture—verbal and nonverbal—can make all the difference in terms of career advancement.

Such organizational language can be considered as its own kind of coding. This facilitates everything from a working knowledge of financial reporting, to the listening skills needed to understand the technology goals meaningful to each business unit. It’s also how unwritten rules about business priorities or hierarchies are communicated.

After all, the career survey cites at least 26 job descriptions among DevOps professionals, including project manager and operations manager, among others. This means you don’t necessarily have to get stuck in one position or job description. In an organization that fosters the DevOps culture, your value goes well beyond your technical capabilities, but rather the focus is more on organizational skills.

The Takeaway

Since DevOps involves cross-functional teams instead of compartmentalized departments, everyone will need to be more involved in business operations, product development and support. Being an effective communicator is at the heart of all this, and it can spell the difference between success and failure in a DevOps environment.

It’s easy to think that there is little more to learn in terms of communication, especially if your DevOps integration is already mature and your team is functioning optimally. However, your investment in becoming a better DevOps communicator begins with learning the language and culture of the organization. This also includes a continuous reassessment of skills and the ability to build connections from each and every encounter with colleagues, partners and other stakeholders.

About the Author / Laureen Fagan

A senior PR counsel and thought leader, Laureen Fagan has 15 years experience as a media and PR professional, which includes her stint at CBS and Fox broadcast affiliates in the United States, and in print and wire-service newsrooms in Chicago, Washington D.C., and Jerusalem. Laureen received her MSJ from Northwestern University’s Medill School of Journalism, and completed additional graduate study at University of Notre Dame in Theology / Hebrew Bible that includes French, Arabic and Hebrew study. In addition to tech and business, Laureen creates informed content and deep analysis on international affairs, health care, culture and religion.

September 13, 2016