The amount of data that businesses generate and collect continues to soar, and enterprises that want to accelerate their end-to-end processes and obtain business insight can’t keep using the manual data management processes they have relied on for decades. And the situation will only get worse in the coming years. IDC expects the amount of data to grow at a 32% CAGR to 180 zettabytes by the year 2025. Fortunately, DataOps can help.
DataOps is a relatively new and still-maturing discipline that arose about five years ago. It’s built on the foundations created by agile development and DevOps, and the goal is to bring similar principles to data analytics and data science to improve data quality and reduce the time required for obtaining actionable business intelligence.
Over the next few years, enterprises that resist adopting DataOps will spend even more time reacting to data errors and broken manual processes, and fall even further behind in their ability to provide timely, accurate information to business leaders. Meanwhile, those that embrace DataOps will create streamlined, automated data pipelines that enable data administrators and data scientists to optimize business processes, focus on higher-value tasks and support decision makers with the best possible intelligence.
In this article, we’ll review the principles and power of DataOps and five specific ways every organization can benefit from it.
What Is DataOps?
Because of the massive size of datasets, performing data analytics today requires automation to be able to do validity testing, analyze the activity and behavior of the data pipeline itself, and detect anomalies and outliers that can indicate a quality issue with the data or the pipeline. Based on the efficacy of agile development and DevOps principles to deliver high-quality results orders of magnitude faster than previous approaches, relevant principles and best practices were borrowed and codified in the 18 principles of the DataOps Manifesto to enable the same types of automation and quality-detection capabilities within the data pipeline.
A foundational concept of DataOps is that “analytics is code,” which means that everything–collection routines, ETL routines, even the analysis routines that drive metadata and business intelligence-level summaries–needs to be modular, automated and easily and instantly repeatable. As businesses work toward this goal, operational benefits will accrue, such as the ability to receive real-time alerts on streaming data, so quality issues can be resolved before bad data gets propagated or has a chance to impact decision making.
The Power of DataOps
DataOps is already enabling businesses to transform their data management and data analytics processes. For example, like DevOps, DataOps lets teams easily spin up isolated, safe and disposable testing environments that allow them to experiment and innovate (Principle 12 of the Manifesto). However, while developers typically focus on applications with small test databases, data analysts and scientists may need to spin up a sandbox environment that includes applications along with terabytes or even hundreds of terabytes of data. By easily implementing intelligent DataOps strategies such as automation, cloning, predictive analytics and more, spinning up massive disposable data environments becomes possible.
DataOps principles are also enabling businesses to act on their massive production datasets in ways that were unimaginable just a few years ago. For example, DreamWorks can now easily share the datasets of its films in development with teams of creative artists around the world, enabling rapid collaboration and dramatically shortening production times. Another example is the genomics company, WuXi NextCODE, which has developed a genome platform that can compare human DNA–millions of bits of data–and integrate the data on the fly to explore the differences or mutations that may cause cancer or rare diseases.
There are also many financial services companies, in America, EMEA and APAC, all leveraging NetApp for moving to a hybrid cloud data pipeline model. The hybrid model allows them to maintain compliance for protected and sensitive data, while taking advantage of cloud cost savings for non-sensitive data and applicaation components. This allows for a strategy that delivers both regulatory compliance and the flexibility of a hybrid data pipeline architecture.
However, you don’t have to be a film studio, genomics company or financial services firm to benefit from DataOps. Every company that needs to obtain timely actionable business intelligence will benefit in five critical ways.
Top 5 Benefits of DataOps for Any Business
Reducing toil: Similar to DevOps, DataOps is fundamentally about process-oriented methodologies and automation, which dramatically increases the efficiency of workers. By baking intelligent testing and observation mechanisms into the analytics pipeline, teams can stay focused on strategic tasks instead of poring over spreadsheets looking for anomalies.
Better-quality data: Creating automated, repeatable processes, along with automatic code checks and controlled rollouts, reduces the chance that any type of human error will get distributed to multiple servers and take down the network or produce erroneous results.
Faster access to actionable intelligence: Reducing toil and improving data quality leads directly to faster access to actionable business intelligence. Automated ingestion, processing and summary analytics on incoming data streams, combined with the elimination of errors, can deliver insights into customer behavior patterns, market shifts, price fluctuations, etc.–instantly instead of hours, days or even weeks later.
Seeing a bigger picture of dataflow: Beyond the business-critical day-to-day insights, DataOps can provide an aggregated view over time of the entire dataflow, across the organization and out to end users. This can reveal macro trends, such as adoption rates of features or services, or search pattern deltas over time. Even behavioral or geographic patterns for focused or global data sets. Creating such a view would never be possible for teams that are constantly reacting to anomalies and errors with manual processes.
Career enhancement: Data analytics and operations professionals who learn how to implement and manage DataOps processes will enjoy career benefits as they become the leaders of the next generation of data teams and set the standard for data practices for at least the next 10 years. The business also benefits from increased employee satisfaction and retention as repetitive and monotonous processes are replaced by an exciting and fast-moving organization focused on innovation.
Over the next five years, DataOps will become mainstream in the same way that DevOps did. The benefits are too compelling, and the consequences of ignoring it are too dire. However, as companies progress on the DataOps journey and find success in leveraging its principles to drive business intelligence and streamline processes involving large datasets, they will eventually confront the limitation of their infrastructures. As a result, they will need trusted technology partners that can help them ensure data replication, data distribution and data availability at a scale that dwarf’s today’s requirements.
The past 15 years have been rough on software testers. The rise and fall of outsourcing, Agile growing from a manifesto to a movement and ever-shrinking release cycles have all taken a toll. By 2011, Albert Savoia walked on stage at the Google Test Automation Conference (GTAC) dressed as the Grim Reaper and declared testing dead. Since then, the emphasis on the “automation” part of “test automation” has fueled demand for Software Development Engineers in Test (SDETs) and left many testers wondering if they must learn programming to save their jobs.
If you look at how frequently people are searching for “software testing” on Google, the trends seem to suggest that the profession is, if not dead, at least flatlining.
However, I think the times are a-changin’. The pendulum will be swinging back—to the point where software testing could be the comeback kid of the 2020s. Sounds crazy, I know. But consider some developments that could turn things around.
Developers Don’t Want to Bear the Testing Burden
On Agile development teams, the party line is that unit testing is essential. It’s the most efficient way to expose implementation errors as they’re introduced. You can feasibly cover each function/method when you test at this level, plus when a test fails, you know exactly what function is broken. Moreover, having a suite of effective unit tests establishes a safety net that alerts the team whenever changes break previously-verified functionality. Those are just a few of the reasons why unit testing forms the foundation of the Agile test pyramid.
But, if you talk to developers in a casual setting, the truth starts to come out. Unit testing requires a lot of work, and they’re skeptical about whether it pays off. Just skim through a few of the 2.5 billion results returned by a Google search for “Is unit testing really worth it?” to get an idea of some of the issues.
Unfortunately, a seemingly endless amount of work is required to ensure that unit testing delivers long-term benefits as a regression testing safety net. Developers are committed to progression testing, not regression testing. Although developers on Agile teams usually write unit tests to check new functionality, few keep them up to date as the code base evolves. As the team moves on to another sprint, these tests become regression tests. Then, little by little, they start failing—but developers have moved on. The number of working unit tests at the base of the Agile test pyramid erodes, as does the level of confidence the test suite once provided.
In fact, data from our internal studies on financial instructions across EMEA shows that as an iteration ends, unit tests cover about 70% of the new code. After a few iterations of code getting extended, refactored and repaired, the original unit tests provide only about 50% coverage of that original functionality. This drops to 35% after several more iterations, and it typically degrades to 25% after six months.
Is Unit Testing Doomed?
Ultimately, developers don’t have the time or desire to keep these tests current over the long term. Unit testing has been a best practice for more than 20 years, yet despite waves of unit test automation tools (including one created by Albert Savoia not long before he declared testing dead), unit testing remains a thorn in developers’ sides. Does that mean we give up the benefits of unit testing altogether? Not necessarily.
In order to take on unit testing per se, testers would need to understand the developers’ code as well as write their own code. That’s not going to happen. But, you could have testers compensate for lost unit test coverage through resilient tests they can create and control. Professional testers recognize that designing and maintaining tests is their primary job and that they are ultimately evaluated by the success and effectiveness of the test suite. Let’s be honest, who’s more likely to keep tests current, the developers who are pressured to deliver more code faster, or the testers who are rewarded for finding major issues (or blamed for overlooking them)?
Another option is to consider new testing approaches that achieve unit testing benefits for today’s most popular development architectures—but without requiring knowledge of the code. Enter microservice contract testing.
Microservice Contract Testing: The New Unit Testing
Interest in microservices (the blue line on the graph below) has been rising rapidly since 2015. In fact, it seems to be on the exact opposite path from software testing (red line).
This rise is hardly surprising. From the architecture perspective, there are significant benefits to microservices. Initial forays into service-oriented architectures (SOA) were a huge step forward in enabling reuse and flexibility. Business logic formerly implemented in monolithic applications was freed and released as isolated independent services, which were loosely-coupled and highly-distributed.
Microservices take the decoupling and granularity to new levels. Business logic is now implemented in the smallest, most discrete units possible. Functionality that would have once been a single service is now distributed across tens, or potentially hundreds, of microservices, each of which can be independently developed and deployed.
In addition to enabling unprecedented agility and scalability, this extreme decoupling opens up promising new options for testing. With the initial waves of services and APIs, API tests had little choice but to pass through a fairly broad set of business logic, which was likely implemented through multiple units of code (e.g., functions).
If an API test failed, there was no clear pointer to what specific code function needed to be fixed. That required unit testing and/or additional debugging.
Now, with each microservice implementing an extremely focused unit of business logic, you know exactly what code is broken when an API test fails. Why spend the time and effort on unit testing if you’re already getting the benefits from something that’s considerably less painful?
You might be thinking, “Testing hundreds of independently-evolving microservices is just going to present a different pain.” Correct. Each integration point is a potential point of failure, and testing all the possible integrations is a logistical nightmare—so don’t. Instead of testing how each microservice interacts with all the other microservices it touches, perform contract testing instead.
Very basically, contract testing helps both microservice consumers and providers ensure that they’re meeting expectations in terms of message format and data. The microservice consumer adds a contract that specifies expected request and response pairs for its various interactions with other microservices. Each contract is used to create a virtual service that the consumer can then test against. If the consumer’s changes result in incorrect/unacceptable request messages, they’ll be alerted immediately by a contract failure message triggered from the virtual services.
On the flip side, the microservice provider can use the same consumer-specified contracts to ensure that their own changes don’t break the functionality which consumers depend on. If the actual provider response suddenly fails to meet consumer expectations, they, too, get a rather clear and telling contract failure message.
The beauty of this approach—even beyond the fact that neither consumer nor provider ever has to stand up the whole spider web of interconnected and independently-evolving microservices—is that you get very specific unit-level failure information without burdening developers. As soon as testing moves away from the code level to the API level, it doesn’t need developers doing it. You certainly don’t need developers to deal with the maintenance, and you really don’t even need them to set up the test. Instead, the task can be delegated to people who view testing—not development—as their profession. We call them testers.
Looking Beyond Unit Testing Is Essential for Ensuring a Positive User Experience
Nevertheless, hyperfocusing solely on unit testing of any flavor can leave you blind to many critical issues. For example: Does every step of the end-to-end transaction work as expected—from whatever mobile or browser interface the user happens to have, through the backend (which might interact with custom/legacy applications, packaged applications, mainframes, databases, third-party services, etc.) and back to the user? Will these same transactions perform acceptably under a sudden increase in demand? If the user exercises the application in ways that the developers didn’t anticipate, will the application respond in a reasonable manner, or at least fail gracefully?
The answers to such questions lie beyond the horizon of the testing performed by the typical Agile team, which rarely extends beyond unit testing and a little integration testing.
However, as organizations invest millions in digital transformation initiatives, this doesn’t cut it. Maximizing that investment requires a flawless user experience from start to finish, 24/7. Professional testers thrive on exposing the glitches that developers tend to overlook but that would cause a CIO to cringe.
I’m confident that software testing will surge in importance in the 2020s if we commit to expanding its scope and effectiveness, which will ultimately elevate its business value. As the pendulum swings back, testers can’t expect to just hang on for the ride. Willingness to jump on the momentum of this decade’s trends—for example, stepping in to solidify the foundation of the Agile test pyramid and embracing new practices such as microservice contract testing—will be essential for navigating the turnaround.
Much like “blockchain” and “big data,” the term “DevOps” is another buzzword currently being thrown around the IT departments of large organizations.
Many have identified the need for faster software development life cycles; a more precise process closely aligned with business objectives, allowing for clearer workflow and collaboration between the development and operations teams. DevOps is essentially agile, all grown up and ready to take on the constantly innovating and rapidly deploying needs of the modern business.
For security professionals, it’s a fantastic initiative: We can inject security into the process far earlier, reducing the cost of fixing bugs and avoiding potential catastrophe down the track.
The problem is, few companies are truly successful in their DevOps implementation. Without the right support, nurturing and understanding across the business, it can quickly become a white elephant, you know, one of those “don’t mention the war” projects.
So, what’s the problem? There are a few ways to approach DevOps that I believe will make for much smoother sailing. An effective program goes beyond a few fancy new tools, titles and team meetings. It’s not always going to be easy but taking the time to fix a broken strategy (or implement it the right way from start) is going to be far less painful in the long run. Ultimately, it’s going to result in higher quality and more secure software.
Let’s break it down.
Let Go of the Agile Apron Strings
There is somewhat of a misconception that an organization must choose between agile or DevOps, setting down one path or the other, never to look back.
The thing is, the development process works best when both are being considered and implemented as one. DevOps is not a reinvention of agile development; rather, it is an extension of it. The wheels tend to fall off when there is an expectation the process will be exactly agile, or completely different from agile.
Agile supports the principle of cross-functional teams, bringing designers, testers and developers together from the beginning and committing to open communication lines throughout a project. Its aim is to stop siloed delivery and reduce double-handling, both of which are benefits of the DevOps process as well. However, DevOps goes a step further, introducing systems, security and operations into the mix to offer a robust, end-to-end skillset that had the ultimate goal of full, functional software delivery to the customer.
During the inevitable pain-points of moving to a more DevOps-centric process, the risk of siloed development can crop up again. You can often have the original agile team working together, with the security and operations additions still finding their way in the machine. No one is quite sure how to include them, what they should be doing and their overall objectives.
DevOps does not work without clearly defined objectives, cross-functional onboarding and direct communication with all parties. There will be an adjustment period requiring careful change management but getting everyone on the same page with the enhancements DevOps functionality will bring is half the battle.
Increasingly, DevOps is placing emphasis on security best practice as part of the process as well, demystifying that step and bridging the gap between the security team and everyone else. As I have said before, we still have a long way to go in empowering developers to code securely from the start, but the successful implementation of DevOps methodologies is an excellent foundation on which security skills can be built within the development team.
Automation Isn’t Everything (and It’s Not the Most Secure)
Another feature of DevOps methodology is, to a certain extent, the automation of the software development process. Continuous integration and continuous delivery (CI/CD) principles are the cornerstones of this concept, and as you can likely guess, very reliant on tools.
Tools are awesome. They can bring unprecedented speed to the software delivery process, managing the code repository, testing, maintenance and storage elements with relatively seamless ease.
However, while robots might take all our jobs and imprison us someday, they are definitely not there yet. Heavy reliance on tools and automation leaves a window wide open for errors. Scans and tests may not pick up everything, code may go unchecked and that presents enormous quality—not to mention security—issues down the track. An attacker only needs one back door to exploit to steal data, and forgoing the human element in quality and security control can have disastrous consequences.
The happy medium is to ensure you have a balance of people and tools. Tools should serve as the assistants to a team you trust to deliver on project goals. You should:
Allocate enough time for people to become familiar with the chosen DevOps toolchain.
Focus on effective collaboration (and how the tools can support that).
Address any gaps in the process, whether they are skill/knowledge or tool-based.
In short, don’t just tool up and hope for the best.
DevOps Isn’t a Buzzword, It’s a Culture – Are you Growing Yours?
Change management is tough at the best of times. Fear of the unknown can stop even the most brilliant team members from growing their skills and expanding their horizons.
You see, merely saying “let’s do DevOps” and making the operations team move desks isn’t going to magically implement a successful process. Many will be confused, and long-serving members of the team will be left feeling disgruntled. Communication of expectations is crucial, as is walking the walk. DevOps represents a cultural movement just as much as a development methodology, and a team should live and breathe a cross-functional, collaborative mindset.
What does a great DevOps culture look like?
Individuals are empowered to lend their expertise to a process, not just leaders.
Open, honest and respectful communication between teams.
Each person takes responsibility for the overall objective of building quality and security into the development process.
Everyone is on the same page with the definition of DevOps in the business, the roadmap and how/what/why of each person’s role.
For years I have emphasized the importance of building positive security cultures in development teams, and DevOps is no different.
The right tools, knowledge and support are imperative to achieving security best practice, seeing a downturn in discovered vulnerabilities and opening the team’s eyes to the importance of protecting our data. With DevOps, you must lay the cultural groundwork for positive change: Ensure everyone understands their role, value and expectations, the overall project goals and steps in the process.
Have you mastered that? Great. Now, let’s shift the needle, dial up the security aspect and make DevSecOps the ultimate plan for software excellence.
How do we define DevSecOps? A combination of DevOps and security is readily apparent, but the philosophy goes much deeper. In a recent eBook, The State of DevSecOps, we asked industry experts to define what DevSecOps meant to them. Below, we’ve condensed their answers into five core attributes.
Following these principles, CIOs or CTOs now have a DevSecOps doctrine applicable to nearly any software development and release environment.
Security Automation
DevSecOps emphasizes security objectives within the automation processes. Ben Newton, director of product marketing and evangelism at Sumo Logic, defines DevSecOps as first making security requirements and objectives a clear part of the continuous integration (CI) and continuous deployment (CD) cycle.
Culture of Security
DevSecOps establishes a team culture that embraces security concerns. As stated by Ben, a security team must provide “clear guardrails for developers as to what is fair game and what is not appropriate from a security perspective.” Building security expertise to integrate security into the entire DevOps lifecycle is critical.
De-Siloing IT
DevSecOps is about eroding boundaries. Just as DevOps has eroded the traditional separation between software engineering and IT operations teams, “DevSecOps further erases the walls between the DevOps team and IT Security,” said Tim Jarrett, senior director of product management at Veracode. “DevSecOps is about building a bridge between the security and DevOps teams,” echoed Dan Hubbard, chief product officer at Lacework.
Security Shifts Left
DevSecOps places security earlier on in the development process. IT security is traditionally viewed from a risk avoidance and compliance standpoint. Rather than viewing security as a gate, Tim noted that within DevSecOps, “security is better positioned to integrate earlier in the development cycle where they can actually make a difference.”
Security Enables, Not Stalls
DevSecOps supports, not stalls, agile development. DevSecOps doesn’t have to be sluggish. As Dan described, DevSecOps must “support the need for DevOps to move fast, but in a way where security is not ignored.” By embracing a security-as-code mindset and involving practices such as automated threat detection, agility is not sacrificed.
The Feb. 28 release of the ITIL Foundation ITIL 4 Edition book is proof positive that other service management frameworks have impressed the folks who brought the latest iteration of ITIL to fruition.
ITIL V4 proves to be significantly different than previous generations of ITIL and embraces many of the core values found in frameworks including Lean, Agile and DevOps. Ideologies such as embracing value, fostering collaboration and adopting what ITIL V4 specifies as a four-dimension model bring a holistic approach to service management. The four dimensions are classified as people, products, partners and processes.
Perhaps the biggest challenge in creating ITIL V4 was moving from traditional process-led delivery advocated in ITIL V3, to a best practices approach of focusing on co-creating value collaboratively between the organization and stakeholders. A change that potentially impacts ITSM, development, operations, business relationships and governance.
“We worked with 12 lead architects, 61 authors and reviewers and hundreds of practitioners from the wider IT industry,” said Mark Basham, CEO at AXELOS, the organization responsible for ITIL. “In addition, our ITIL Development Group has more than 2,000 members from all over the world. This huge collaboration has now produced a framework that will support practitioners and organizations, to meet the challenges that come with the Fourth Industrial Revolution.”
At first blush, ITIL V4 seems to reiterate what many other frameworks already espouse. However, ITIL V4 does bring some other ideologies into play.
“One big change with ITIL V4 is the focus on value, where value is more than just a desired outcome but also something that is co-created by all involved. That ideology fuels collaboration and breaks down silos. The shift to focus more on the customer experience demonstrates achieving value, establishing the value chain as a foundation,” said Nancy Van Elsacker Louisnord, President of TOPdesk USA, an Orlando, Florida-based developer of service management software. “ITIL V4 actively embraces some great concepts out of Agile and DevOps, exemplified by the guiding principle of progress iteratively with feedback. The ITIL4 service value chain looks very similar to what we see in DevOps and actively encourages an iterative approach.”
However, with ITIL V4 seeming to borrow from other ideologies, one may wonder how much value remains in the ITIL framework.
“Partners and suppliers have been added as a fourth dimension, next to organizations and people, processes and value streams, and information and technology. It is an addition that accounts for the reality of increased outsourcing, and the challenges that come with that,” said Van Elsacker Louisnord. “The dimensions play an important role in the 34 ITIL practices that have replaced ITIL V3’s 26 processes. While in essence they haven’t changed much, ITIL V4 takes those four dimensions into account in every practice, making practices much more practical than the processes of the past,”
While many questions still remain around ITIL V4, the writing is on the wall that Agile ideologies are becoming the norm, and DevOps-orientated development brings forth certain advantages. ITIL V4 must co-exist with other frameworks to bring value into best practices and adaptable frameworks. More importantly, ITIL V4 is being set up as a framework that can enhance other ideologies, while helping to preserve the investment that hundreds of thousands of IT professionals have made in ITIL.
There is a belief in the space where containers meet DevOps that a service hosted in a container crashing is no big deal, and you can just spin up a new one. It’s not a pervasive belief, but it is common enough that we’ve all heard/read it somewhere.
I think this view of the world is, at best, incomplete. There are easily verifiable cases where it just isn’t reality. A good example is the Cloudbleed bug, where ignoring errors and spinning up a new instance to meet load demands was one of many things that combined to make a sensational (if low-risk) failure.
Another good example is shopping carts and payment systems. All the small-business owners I know would balk at a shopping cart of payment processing system that could crash mid-transaction, and the provider shrug and say, “We spun up another instance; have the customer try again.”
Are there scenarios where crashing containers simply being replaced might be acceptable? I would argue no. They’re software errors. The world has not changed; errors are still bad. I can invent “but if you …” scenarios as well as the next person, but the fact is, if your software is crashing—be it container, VM, hardware, firmware or whatever—you did something wrong and you can’t know the extent of the issues the crashing creates without digging into the problem. At which point, you may as well fix it.
I’ve written my share of bugs, like any developer. And I’ve fixed my share of bugs, like any developer. Ignoring them is a recipe for disaster, when a seemingly benign bug is suddenly exposed to have major issues.
Schedule time to fix issues. Rushing forward with new features and products is cool, but keeping the customer base happy and safe is far cooler when revenue time comes. If containers and DevOps are saving you the time they’re supposed to be, you have a little extra time to get in there and fix issues, so use it productively.
DevOps is the marriage of application development teams with system operations teams, their philosophies and actions.
In an agile environment, development, testing and operations all must work together to meet frequent iterations, releases and delivery goals. This calls for a collaborative development environment that supports data orchestration with other lifecycle tools.
The article will explain how multitool integration support can help organizations perform the DevOps life cycle, which includes continuous planning, continuous integration, continuous testing, continuous monitoring, continuous delivery and continuous feedback mechanism.
The Drivers of DevOps
Today, with the increasing competition and the need for an early market release, the software development industry is undergoing a paradigm shift. Agility has become an inevitable process across all organizations. In addition, shorter ROI cycle spans, frequent releases, increased CRs and different IT systems and tool technologies have made the situation critical.
The industry demands higher transparency, maximum visibility, minimum turn-around time, lesser human intervention and efficient processes at every stage, from development to delivery.
However, organizations that use specialized tools to manage builds, deployments and delivery processes continue to face difficulties when it comes to data orchestration and process automation across the tool chain.
In an agile environment, developers and testers need to ensure not only that code changes work and integrate well, but also that frequent iterations do not make the product unstable. Hence, seamless cross-tool collaboration is very important here.
The process chain consisting of Code –> Build –> Provision –> Test –> Defect Fix –> Deploy –> Release needs to run continuously and smoothly without compromising delivery deadlines or the product quality.
Automation is the Catch Line
With the rising demand for continuous delivery and sprint-based development, manually setting up a test, build and deployment environment is burdensome and time-consuming.
Software teams need to automate the entire cycle of build, provisioning and deployment of test environments, including the tools, scripts and test data to ensure rapid delivery. They also need to collaborate around the application architecture and monitor event-action-based mechanism for seamless data flow across the tool chains.
Reports show the most important DevOps components are IT automation, agile development and collaborative teaming of personnel. Therefore, without centralized orchestration of tools, achieving DevOps is not a realistic situation. Since organizations spend around 73 percent of their DevOps budget in tool acquisition, it is important they know how to get the tools working together to overcome DevOps obstacles.
In the process of connecting their existing and new toolsets, most organizations search for an integration methodology that is scalable, reliable and easy to maintain. Point-to-point integration between tools help, but to a limited extent. Even a single change in integration rules involves complex coding and high maintenance across development, test and deployment cycles.
How ESB-based Integration Can Help
An enterprise service bus (ESB)-architected integration hub connects both the existing and the new tools to support a seamless data flow between them across the DevOps life cycle.
Once integrated, the data from both the development and the operations tools become readily available for use to every stakeholder. The benefit of using ESB-based integration is that you can add or remove any tool based on your connectivity requirements.
In a typical scenario, DevOps teams use a series of cross-functional tools starting from project planning to delivery and operations. Neither of these tools comes with built-in integration features, which results in inconsistent flow of information among tool users.
Project managers use application lifecycle management (ALM) or Agile planning tools to detail the scope of work and tracking progress reports. Upon unit testing, developers use a different tool to check in a code from their integrated development environment (IDE) to the source code management (SCM) repository. They also perform a code quality analysis before committing to the SCM.
In such a scenario, continuous integration (CI) can be achieved only when developers bring these planning, unit testing, code analysis and SCM tools under one roof. That is, connecting the tools through a common integration hub. It also helps developers to manage everything from within the IDE.
After successful check-ins, build engineers trigger the SCM tools for automated build and testing. Upon a successful build, testers engage in continuous testing using manual and test automation tools, followed by provisioning for continuous deployment. They also perform load testing, API testing and security testing using separate tools. An integration support helps to keep the real-time data flowing between the build and the testing tools uninterrupted and seamless.
A DevOps system also includes application performance monitoring (APM) tool for continuous monitoring of memory consumption, CPU usage, database health and release tracking. Operations team use help desk/ IT service management (ITSM) tools for continuous feedback generation and customer support. And delivery managers use continuous delivery tools for defining and tracking release pipeline through graphical interface.
When all these tools are connected to a central integration hub, product release and help desk operations become faster and efficient. The integration between development and ITSM tools facilitates continuous feedback generation, which helps to improve the product quality.
Through an integrated tool ecosystem, project managers can create a DevOps workflow based on business logic and automate the data movement across tool systems. Business analysts, developers, testers and delivery managers can also get real-time update on development progress and keep track of actionable items. Supervisors can route cross-tool data to a central repository and generate meaningful reports and analytics before taking business decisions.
Fig: ESB Integration Bus Facilitating Adoption of DevOps
An ESB-based integration tool helps organizations to implement and leverage the best DevOps practices by establishing connections across all participating tools. An integrated tool ecosystem helps achieve the following:
Real-time collaboration between development, delivery and operations tools
Continuous planning from requirements capturing and review to design and code analysis
Cross-tool traceability for defining relationships between various data objects
Test strategy implementation for continuous testing
Continuous integration through automatic triggering of build on successful completion of code check-in
Continuous testing through workflow based automatic triggering of both manual and automated test cases
Scheduled test automation script execution enabling continuous delivery
Continuous monitoring of release quality through reports and dashboards
Automated defect identification and resolution for faster help desk response
End-to-end traceability providing better release predictability and change impact analysis
Meaningful reports, metrics and KPIs for quick decision-making
Continuous delivery through tracking release pipeline
How Inter-tool Connectivity Brings Continuity
To understand the stages of engineering practice, let us consider a sample DevOps scenario in an IT service organization.
The organization uses an ITSM tool to manage support tickets submitted by customers. On submission of a ticket, it is automatically passed on to an ALM tool as user stories or defects for internal development.
On allotting to a sprint, developers and testers view the user stories or defects from IDE, SCM and test tool. Once the coding is complete and codes get checked in at an SCM tool, an automatic build gets triggered using a build tool. Upon successful completion of the build, tool provisioning is done through a virtual machine.
The successful build can be automatically deployed using a deployment tool and automated tests can be executed through a test automation tool. The test results are then captured and linked with test cases and the source requirements for traceability.
The defects that are raised in the defect tracking tool for failed test cases can be automatically routed to developers for fixing.
Fig: DevOps scenario achieved in a collaborative tool environment
Once connected to an integrated tool system, users get a complete visibility of the tool records and their relationships from within their own tools. Developers, testers and help desk managers can get complete traceability view between development artifacts and change requests or defects.
When all the tools participating in DevOps sync with each other, developers can easily view the support tickets reported by the operations team right from their own IDE.
The help desk team also gets a real-time update whenever a change request gets implemented or a defect is resolved by the development team. It eliminates the latency in communication between the Dev and Ops teams to a great extent.
In addition, customers get frequent updates from the help desk team, which makes them happy and confident about the product performance.
Conclusion
Implementation of DevOps is not a “Do once and forever” type of task. Just deploying the right set of tools to the right users will not serve the purpose. Proper connectivity between and across the DevOps tools chain is necessary if you want to create a collaborative work environment around the Dev and Ops teams.
An integrated tool system saves considerable amount of time and effort, which would otherwise be wasted on manual execution, monitoring and reporting of data during DevOps implementation.
About the Author / Sanat Singha
Sanat Singha is a senior technical and web marketing writer. He takes special interest in ALM process, technologies and tools integration as an industry. Sanat does content marketing, professional blogging, social media promotion and website analytics.
Technology is changing every industry; we can all agree on this foundational premise. If you disagree, I believe the rest of this post is going to do nothing for you, so feel free to stop reading now. If you do agree, then you know that apps, the internet of things (IoT) and APIs are table stakes now. Businesses need strategies for each, and the forward-thinking executives are already adapting. The ones that aren’t risk alienating a channel in their overall digital strategy. It’s not all about strategies for building new types of functionality and partnerships; organizations also need to validate they will work specifically with their customers’ use cases in mind.
When we study software development, the history books teach us that waterfall strategies followed a linear path. In the past, this pace may have worked, but the future seems bleak with the evolution of technology and its disruption of traditional, manual business processes advancing at an exponential rate. Over time, the stages in the software development life cycle (SDLC) may remain the same, but organizations need to focus specifically on becoming more efficient at completing more work in less time. With this “do more with less” mindset, it’s no wonder many organizations see a backlog of work piling up. This point is especially true for quality assurance and quality engineering teams.
First, let’s unpack the software development stages from a traditional sense. Historically, organizations would get an idea and that idea could come from the businesses stakeholders (sales, marketing, customers, etc). The business would prioritize/stack rank all of their ideas by which carried the most merit and how much work those ideas would require for implementation. This is known as the “planning” phase. From planning, the idea would progress to be built. “Building” is the part of the life cycle where your artists/engineers live. You know, the creative people, the developers. They build the technology according to specifications that come from the planning phase. Most importantly, they are incentivized based on the project being delivered on time.
After the technology is built and packaged, it is passed on to the team that has been traditionally responsible for quality—quality assurance (QA). QA has their time with the product to validate the product works as intended, can scale to the appropriate demand levels, is secure and meets all the use cases without error before they pass it over to the team that will deploy it to the hands of their customers. Finally, the business is measuring feedback and customer sentiment, and then rolling that feedback back to the plan stage for improvement.
As time has passed, we have also seen another major trend develop. Organizations have developed agile/iterative SDLC strategies that are focused around bringing smaller chunks of functionality to their users/customers faster. Just like “lean manufacturing,” this concept has been focused predominantly around helping the developers get their projects completed faster. The primary challenge with waterfall development strategies is that by the time an organization brings the plan to market, the needs and priorities of the customer will have already changed. The speed of idea generation outpaces the execution of said ideas. That being written, while development has kept pace, quality has not, unfortunately.
Now I pose a simple, albeit, extremely important question: Who owns responsibility for ensuring quality of the finished product? If your answer is QA (like stated above), and I can see why that would be the instinctual response—the process is set up for failure. Here’s the fundamental reason why: if quality is so important to the process, then why is it the third phase in the SDLC? This implies planning and building without quality in mind is an acceptable process.
Quality should be owned by everybody in the process. QA/QE teams are your enablers of embedding quality throughout the SDLC. The distinction is more about instituting an ideology or culture based on quality.
With a culture focused on driving quality, when the planning team works on creating a specification for the idea, they should work with development and QA/QE as they are designing the flows, behaviors of the application. This allows for QA/QE teams to understand what to validate much earlier in the process. Teams are always looking for ways to factor more automation into the process. QA teams are also looking for ways to make their test environments more closely resemble the production environment where their customers interact with the business.
Unfortunately for QA/QE, they feel pressure from the business to execute within a constrained time frame with better results. This typically means inadequate windows of opportunity to start building automated tests or an incomplete environment that doesn’t quite resemble what the end user will face.
The last frontier to validate is performance which answers the important question: Will the app scale for the expected user population? This is often the last step before flipping the switch and shipping the product to your customers. But what happens if the application doesn’t scale? Organizations need to drive performance validation earlier. Better yet, they should engineer the application for the desired performance, and that means—yes, you guessed it—taking care of this earlier in the life cycle.
What if it were possible to drive more improvement?:
1. … To start building functional test plans and test automation at the time when planning happens?
2. … To ensure that development and test environments more accurately have access to the constrained downstream resources that cause unexpected “wait time”?
3. … To ensure that the automated testing that will be executed in the testing phase, has the right data to power the tests?
4. Finally, … to make sure that performance isn’t just an afterthought but a strategy to scale to the changing landscape of a digital business?
It’s more than possible. It’s obtainable. This process is known as continuous testing. It’s about the validation that needs to occur earlier—not just within a window of allotted time within an overall life cycle. It’s also important to understand that it’s a maturity curve, and it will take work to evolve your individual process.
Can your organization embrace continuous testing strategies? If not, what’s stopping you? If so, where can we begin to improve? Driving quality isn’t just about your company’s KPIs—it’s about your customers’ perception of your brand and what you do for them. You never get a second chance to make a first impression. Let’s build the right impression today!
In the technology world, we are in a time of incredible disruption and innovation. Many years ago, my friend and “DevOps Handbook” co-author John Willis predicted that a decade from now, academics will call this period the “Cambrian explosion” — it was an incredibly vibrant 25-million year period that resulted in an incredible diversification of cellular life forms, including the appearance of complex, multi-cellular organisms, setting the stage for the diversity of life we see today.
Similarly, over the last decade, we’ve seen an explosion of incredible innovation and disruption in almost every area of technology: cloud computing, containers, virtualization; Agile, iterative development, continuous integration and deployment, and automated configuration management.
One can be forgiven if all this change is overwhelming; I think we’ve all had moments in our careers where we think, “I’m not sure if I I’m up to learning how to tackle this next big thing.” Even someone who loves learning can become cynical, or maybe just fatigued by change.
But most of us, maybe with some calm reflection, will recognize that there’s never been a more fun time to be in technology. And many of these new techniques and practices lead to massively better ways of working, where after an initial learning curve, we’d never go back to the old way. I believe this actually calls for excitement! And, I’m not alone.
We recently hosted a live chat with multiple leaders in technology who’ve spoken at past DevOps Enterprise Summit events. As we are in full prep mode for the next event in San Francisco this November, we asked our esteemed panel to share about their career journeys in tech and their passion for learning and change. It was a great pleasure to be able to pick the brains of Dominica DeGrandis from LeanKit, Dr. Nicole Forsgren from DORA, Erica Morrison from CSG International, Terri Potts from Raytheon and Robin Yeman from Lockheed Martin. During the course of the discussion, each person shared how they got their start in tech and many of the lessons they have learned over the past 20 years in the industry. It was echoed throughout the discussion that while things are rapidly evolving, it’s an exciting time filled with continuous opportunities to learn, plenty of room for growth and time to experiment with new tools and processes. For the full video replay and transcript of the discussion, please see below.
Also, don’t forget to register for the 2017 DevOps Enterprise Summit San Francisco to hear more from leaders in tech and get a glimpse into their organization’s journey into DevOps. Early Bird pricing discounts are available until July 31!
Gene Kim: Hello everybody, welcome to this episode of the DevOps Enterprise Summit live chat. We are assembled here today with a group of people I’ve known for years, and people who I genuinely admire. They’re all experts and leaders in the DevOps Enterprise community who are helping shape much of the practices that are going to almost certainly be commonplace in technology organizations over the next decade. Over the last 20 years I’ve been studying high-performing technology organizations, and more recently it’s led to studying transformational leaders and trying to understand how they became transformational leaders. What I find fascinating is there’s evidence to suggest that these are traits that you are not necessarily born with, but instead they’re actually learned.
Over the next hour, my goal is to learn about these leaders on this panel, their careers and experiences that shaped who they are today. My desired outcome is that we’ll all learn something that we can integrate into our own respective journeys. As you’ll surely find out over the next hour, these are all great people. As a reminder, the upcoming DevOps Enterprise San Francisco event is taking place on Nov. 13-15, and for more information visit events.itrevolution.com. And just a reminder, Early Bird pricing ends on July 31st.
Let’s go quickly around the panel, and everyone, if you could just introduce yourselves, name, company role, when did you present DevOps Enterprise and what did you speak on, and free to speak to share any professional accomplishment that you’re most proud of. Dominica, let’s start with you.
Dominica DeGrandis: All right. Well, I was a build engineer, spent 20 years bringing visibility to what version of what file was on what server in what environment. Currently, I am the Director of Training and Coaching at LeanKit. I’ve spoken at DevOps Enterprise Summit for four years in a row now, mostly speaking about experience reports and metrics and making things visible. And I guess, my most professional accomplishment, I think it would have to be finding my courage to get up in front of a group of people, and explain or present data, and demonstrate how to get leadership buy-in with metrics.
Kim: Awesome, thank you. Erica Morrison.
Erica Morrison: Hi, everyone. I’m the Director of Software Development and Operations at CSG International in Omaha. We’ve spoken the past couple years at DevOps Enterprise Summit chronicling our journey through the DevOps space, and we’ll continue to tell that journey. Something that I’m most proud of, probably the things that have brought the most challenges in my career have actually been in the DevOps space. We’ve undergone a fairly major transformation this past year, brought a number of teams through that, but one team in particular who have made substantial improvements as far as stability and automation. That’s been really something that’s been fun to be a part of.
Kim: By the way, following your experience reports has been my favorites among every year at DevOps Enterprise, fantastic. Robin.
Robin Yeman: Hey, I’m Robin Yeman, a Lockheed Martin fellow. I’ve been working in engineering about 23 years in the defense industry on everything from submarines to satellites, and everything in between. I think my biggest accomplishment is really being able to see the change. When I first started doing Agile in DevOps, you really couldn’t see it, but now I start getting contracts and RFPs from the customer repeating verbatim what I told them before. It’s cool to see that the influence is there. It might not be as fast as I’d like it, but it’s there.
Kim: That’s awesome, and then you spoke last two years of DevOps Enterprise San Francisco and London.
Yeman: You’re right. Yeah, the last two years on transforming large legacy organizations way back. A combination between Suzette Johnson from Northrop Grumman and myself from Lockheed Martin, because we both had very similar journeys.
Kim: Awesome. Thank you, Robin. Nicole.
Nicole Forsgren: Yes. Hello, I’m Nicole Forsgren, CEO and chief scientist at DevOps Research and Assessment, otherwise known as DORA. I spent years doing software development, enterprise storage at IBM, and then I went and got my Ph.D. that might be my professional accomplishment that I’m most proud of is that I’ve been studying and researching what’s basically known as DevOps for the last 10 years, and then applying it and bringing what I found to the industry and in my work with Gene and Jez Humble, and the team at Puppet on the State of DevOps Report. We all lived through that 2000 dot-com bust, and we saw many companies fail and I don’t want to see that again. Really helping to make an influence in the industry and make things a little bit better is an accomplishment for me.
Kim: Awesome, thank you Nicole, and you spoke in I think every year at DevOps Enterprise. Fantastic. Terri Potts.
Terri Potts: Hi, I’m Terri Potts. I’m from Raytheon Company, and I’m the Technical Director of the Software Development Organization. Like Robin, we are focused on doing mostly defense- and Intel community-related contracts. I started in the software development business actually in the Air Force and spent 11 years there, moving through the ranks and came to Raytheon, and moved on to be an architect after doing development for several years and have been a champion for technology transformation since the early 2000s.
I’ve spoken a few times at DevOps Enterprise Summit. Once about our legacy transformation since we have been around for long, and a lot of our code is quite old. Last year, I spoke about how you build up your staff of people that can support your DevOps transformation because it’s hard to just go out and hire those, some ideas around how to go do that.
Kim: Awesome, thank you much Terri. And by the way, I remember meeting you at the IBM Interconnect Conference in 2014, and you were actually one of the first announced speakers at DevOps Enterprise, very grateful for that.
First, let me just state an assumption I have that there’s actually never been a more fun time and exciting time to be in technology even though things are rapidly changing. Actually the pace of change is what’s causing much fear for many professionals about our livelihoods, our vocations, but I genuinely believe that the best times are ahead of us not behind us. Do you believe that? And if so, why? Erica could we start with you?
Morrison: Sure. I think about when I came out of college with a computer science degree, and I was focused on writing one language and writing that language well, and now we’ve got the proliferation of numerous different technologies, different languages. Like you said, the pace is moving much quicker. We actually hosted a hackathon here. We’ve done two of them for college students and just a number of different technologies that they use was absolutely mind-blowing to me, but I find it extremely interesting to continue to evolve for all these different things. It’s not just this one little dedicated space anymore, it’s constantly learning these new things which I love to do. Its new challenges everyday which keeps work interesting for us, makes work about being lifelong learners. I love that continuing to learn throughout our career, and it’s just focusing on learning different things now.
Kim: Awesome. Robin, how about you?
Yeman: I absolutely agree. I’d really think it’s the most exciting time. Just like Erica was saying, the college kids are coming in with 15, 20 different languages, they’re bringing all kinds of new technologies, they’re bringing gamification. They’ve really brought some different leadership styles. It’s very exciting. I know that some of our engineers get nervous, but if you just grab on and join the ride its fun.
Forsgren: Honestly, that’s one thing I love about technology. I mean, it kept me engaged, it kept me excited. Back when I was doing a bunch of development work, there was always something new to work on. As you said though, there’s always that other piece. There’s always the other side of it. We’re working in systems with growing complexity and that does make it really, really difficult, and that’s something that we’re seeing when we work with companies with DORA, in our assessment. You have to make sure that you can focus, but you need to know what your constraint is, particularly when we’re working on technology transformations. We need to make sure we can focus on the most important thing. We need to make sure that we can limit our whip, we can focus on our constraints, we can identify what the most important thing is that we don’t have sprawl and just contribute to technical debt. But, I think that’s what makes our work challenging and exciting and meaningful.
Potts: I love change, and that’s why my career has taken me where it has because the more different things you get into I think the more rounded you are, and the more you’re able to adapt new technologies. And the way I see it today is all the technology changes especially with the automation that many of us are going through that transformation, and I have always seen that as drudgery. If you’re working in some factory, let’s automate all the drudgery out, and then that gives us time on our teams to explore more around analytics or machine learning. That’s exciting for me.
Kim: Yes, you make it sound exciting. Dominica, you’re smiling.
DeGrandis: Well, I’m just thinking back at my first job out of school after I got my computer science degree. It was more configuration management back then, that was getting everything on the mag tape from IBM and putting that in a library, physical library somewhere safe in order to deploy it into production. But I think for me, it’s just the amount of opportunity there is now. There is this massive amount of opportunity for everyone whether they have a degree in computer science or not to go out there with all the sharing. The ability to share and learn now is much greater than it has been previously.
Kim: That is true. I mean, there’s never been a better time to be a learner. There’s no cost to entry it seems these days.
DeGrandis: Absolutely.
Kim: I suspect that this isn’t the first time that you’ve seen this dramatic change in the industry in your career. I’d love it if you could tell us about that time and how it affected your thinking about how you viewed your skills, your career, and where it took you. Robin, would you mind starting?
Yeman: Sure. When I first started we had a lot of ToR trend and ADA going on, and I was worried about the next generation of ADA, and whether they would even be able to keep up. So, just like that Dominica and the rest of the folks have said, I spent a lot of time at night trying to study, make sure I could stay on top of it because I was working with these amazing engineers and I just didn’t want to fall behind. I do the same thing now.
Kim: And by the way, I mean in a scale of 1 to 10 what level of fear did you feel? One is like it’s just another book no fear, 10 is existential fear of, “I might not be able to finish the book and therefore my career is over.”
Yeman: I work with some engineers—they’re smart that I was terrified. I’d say way up at 8 or 9 out of 10 because some people just get it quick and I have to work at it—I’m just not a natural. I was terrified.
Kim: by the way, it reminds me of learning Clojure very recently. It’s my first script language and I think I had to do 40 hours of reading before I could write a single line of code. It was just, it was very challenging, but very rewarding but all very intimidating. Nicole, how about you?
Forsgren: My first job in tech was when I was still in college, and it was on a mainframe. I was coming out of my associates in like ’99, and that was the big Y2K, everyone’s panicked, and it really fundamentally shaped what I thought about tech in many ways. Everyone was panicked, there was this big dot-com bust, and I alluded to this earlier, “Survival isn’t mandatory, companies can fail.”
That’s one piece where it really shaped what I do is that I don’t want to see companies fail. I’m sure you all have talked to me at conferences, and suddenly I just dig in, and I’m passionate. I have this drive to make sure we know we can find ways to help companies not fail, but it fundamentally affected me in a different way in that in the late ’90s, there was almost a tactical way to address the problem and it was teach everyone fundamental things. People look at me, they’re like, “How do you do mainframes?” It was mainframe, COBOL, Fortran and that was all we were teaching many students because we desperately had a very tactical need to make sure that when we hit 2000, the world didn’t end, technologically.
And then I did a bunch of consulting, and then I got a Ph.D., and then I was a professor. We’ve almost taken this other stance of we only want to or we’re very purposeful now, and I think it’s led to complexity sometimes in technology, but we want to make sure that we understand the purpose behind what we’re doing. We want to make sure that we have flexibility, we’re strategic, and we aren’t just tactical.
So, we designed the State of DevOps reports. They’re vendor and tool agnostic. We tell you about the principles that are important, the architectural designs that are important, the principles behind using version control are important. We aren’t going to tell you to use Git or Subversion, we’re going to tell you to use Subversion control. That’s the other thing that’s really impacted my career is that I need to make sure that if I walk into a situation I can tell someone from a conceptual level what’s really fundamentally important to improve their technology practice, and it won’t be tied to only a specific technology because that can end up being limiting. If you only tell someone teach someone a language, but not the fundamentals behind that language, it won’t work.
Kim: Principles are timeless and those things are not. Awesome, Terri.
Potts: When I think about this, the thing that comes to mind for me is probably about 20 years ago when systems software architecture started becoming a first-class citizen, at least at Raytheon. I remember seeing the first book, and one of my mentors saying, “Hey, I’m going to have a study group on software architecture do you want to join?” And I wanted to join and started seeing it as a way to grow my career, and be able to influence bigger parts of the system, and try to make things more maintainable, and really make good decisions going forward instead of just sort of stumbling into things. I wouldn’t say I was afraid, but I was really curious, and certainly felt like it was something that I needed to keep up with and did a lot of studying on my own outside of the office with study group, learning everything I can from them.
Kim: Sounds very interesting. In this case, it was like a mentor who actually sort of directed you down a certain direction. There seems to be a pattern of having great mentors. Fantastic, Dominica.
DeGrandis: When it comes to dramatic change, I have to say hands down 2005 or 2006. I was working at Corbis at the time managing environments, and we went from building out maintaining 25 servers to building out maintaining 250 servers over a period of 9 to 12 months. It was just impossible to manually build out servers. We had to start automating, and developers were like, “Builds take too long.” They wanted to put their own changes in their own dev integrated environment, and they took it seriously. They said, “Okay, then you get to own that dev environment like you build it, you maintain it. Then, I’ll just go build out maintain QA and staging inner prod.” That was huge dramatic change I think, and just being able to adapt to that and quickly was the biggest lesson for me there.
Kim: And specifically, was it dramatic because it was such a different way of doing things or it was dramatic because the role change and responsibilities for you, or what made it dramatic?
DeGrandis: Because for the previous six years we have had this process where we just dole out responsibilities, who’s doing what and how we’re doing it, and now that was turned on its head because we had to deliver faster, we had to deliver better quality, we had to get these environments up and running, and everything just exponentially grew with the number of servers and the number of environments. The way that I had been working for the last six years which had been fairly successful was completely different. That’s the second law of thermodynamics, everything is always in constant change and motion.
Kim: I love it. This is the famous story that’s in David Jay Anderson’s book, and in your upcoming book, Dominica. Fantastic, and Erica your dramatic changes in a certain point of your career.
Morrison: In addition to the ones that have been mentioned, there’s a couple that come to mind for me. First of all, the introduction of Agile. I started my career very waterfall. I probably wrote code for three to six months before I even chucked it in to the point that other people were using it which now is obviously mind-blowing to us, but that’s how we did software development back then. That’s been a major upheaval in pretty much all of our processes is around how we do software development.
I think overall, all these items point to the fact that software is constantly evolving, it’s not a static thing. When the next thing comes out we’re used to this evolution of change. It’s something that as developers, we just accept it, and look to learn the next best thing and how we get to evolve and continue to get better.
Kim: And physically what’s different or dramatic about the Agile transformation from your perspective?
Morrison: Pretty much everything about it, just the concept of batching work up into small little pieces. I’ve participated in helping roll out Agile with other teams, and it’s somewhat mind-blowing to these teams that you can take this big amount of work and you can even slice it up into one week or one day increments, and chuck that in and have this daily accountability with my team members. That test is now my responsibility and how am I going to automate that because as a developer, we want to automate that test as much as possible. It’s just much more of this integrated, fast-paced, all of us owning all the work and focusing on flow through the system.
Kim: I do remember that it was around 2005, we had just started our first experiments on Agile and even finishing something in a week was mind-blowing. That’s how long it took us to fill out the PRD forms usually. I love these amazing stories that you’re sharing. If you could compare yourself now to the person you were 20 years ago, what were the most important and significant differences between yourself now and yourself then? What skills did you have to develop? Nicole, let’s start with you.
Forsgren: Twenty years ago, as you think back, there’s no Facebook, there’s no Twitter, there was barely email. It existed, but not really. I mean, definitely all the technical skills, but for me learning how to be a leader and how to interact with people, and how to exert influence in a soft power sort of away.
Again, going back and talking to people that I knew 20 years ago there was learning how to do things in more of a nuanced sort of way, which you need to do when you’re managing large projects. For me, it’s been a soft skills thing. I always joke that technology is easy and people are hard, even as complex as technology can be. That was probably my biggest piece of learning.
Kim: In many parts what we work on, they’re all volunteer projects. And even the softer skills are necessary when everyone’s volunteering their time. Great, Terri.
Potts: Twenty years ago I was finishing up my last year in the Air Force and doing some leadership things, but much more as an individual contributor. I have a good view of what it was like to be on the Air Force side managing big contracts, and testing systems and operations. But since then I think that there have been a few things that I really had to develop. One was my network, the group of people that I learned from, and that has definitely grown in the last four years outside of Raytheon. I had a pretty good network within Raytheon, but once I met Gene and started participating in DevOps Enterprise Summits and the Forum, I just love how that career or that network has grown from there.
I’ve also always been interested in really staying with modern technologies and finding ways to make our teams more efficient, I think that’s always going to be something that’s changing. You always have to stay on top of what the latest thing is that’s helping your teams be more efficient. And the Agile transformation too because definitely we were waterfall all the way in the Air Force, and for the first several years that I was at Raytheon.
Kim: That’s interesting you mentioned network. One my favorite quotes is, “You’re only as smart as the average of the top five people you hang out with.” But I think what is interesting is when you can actually bring that network to help other people with their problems. It becomes a really powerful asset and the ideas of everyone.
DeGrandis: Well, I think 20 years ago, I assumed that everybody else knew what they were doing, and that if they were doing the right thing and I intended to feel like I didn’t know what I would. I didn’t know what was up, I didn’t know what I was doing. I was just inundated with trying to learn quickly. And now I recognize that most people really don’t know what they’re doing. Nobody has all the answers and it’s absolutely okay to ask questions, and that in order to have your voice heard and become the voice of reason, how important metrics have been in order to present them in a way that others can understand.
Forsgren: Plus one on metrics. I will cheerlead for metrics all day long.
DeGrandis: I used to rant we don’t have automated testing, smoke tests take too long, and it just has got me nowhere. Now being able to present data calmly and confidently, to be the voice of reason in the organization is one of the greatest learning changes over the last 20 years. That and learning much more about Flow and Lean and Kanban and different methods out there—it’s why I wrote my book, Making Work Visible to help others see how to become the voice of reason. I think that’s super important one.
Kim: Awesome, we have a calm voice of reason. Excellent, Erica.
Morrison: I’ll echo the comments made about people and relationships, and, I think in college we don’t get an understanding that there’s nontechnical problems in addition to the technical ones. Really, we all look at the world differently and we’re going to have to understand that everyone that we work with isn’t going to have the exact same perception as us, and we need to partner together and get these diverse viewpoints, build these relationships, build these networks. That’s something that I probably didn’t get proper appreciation until maybe the midway through my career journey far. And I just wish someone had told me that earlier in my journey.
And then, I think appreciation for the ecosystem that we operate in I talked about that when I first came out of school as a computer science graduate. I was focused on my view of the world and the code I was writing, and I thought the big picture was understanding what the rest of the developers on my team were working on not understanding how do we deploy this code, how do we maintain it, what’s the infrastructure that we’re running on, how does our customer use this code. All those different sorts of things, which I we work on now to get that bigger picture for people, but that appreciation that that bigger picture makes you good at your specific piece of that. And then just that need to continuously improve yourself. It’s not about just being good with what you’re doing right now, it’s about looking at what’s next, how can I continue to evolve myself and improve myself that I can help move our company along.
Dominica: Well said Erica. Hear, hear!
Gene: I can resonate with all elements of that, but just to share a story. I was talking to a younger developer, he must been like around 25 hanging out with a bunch of ops people and I asked him, “Well, what are you doing here hanging out with a bunch of ops people?” He said something that I thought was hilarious, maybe not the most politically correct, but I couldn’t fault his curiosity. He said, “I just want to know where my code goes. To me it’s like I flushed it down the toilet and I just I’ve been doing it for two years, I just wonder where it goes.” Which I thought was unfortunate imagery, but man he was like, “Well I’m the minority of developers actually caring about the system as a whole.” Obviously, that made an impression on me.
One of the things that, if you go back to the topic of change, one of the things I hear a lot these days is how people in our profession often feel very uncertain about their own future, and specifically about how to maintain their own relevance. I’m thinking a person I met that I was actually able to interview on my blog, and yeah, he’s my age and despite having an MBA, despite having a Master’s in engineering management, despite being an expert in the theory of constraints, despite being an operations lead at Boeing, he wrote asking for career advice saying, “What do I do to make sure that I’m as relevant in five years as I am five years ago?” Specifically, what advice would you give someone who’s in operations and feeling like if they don’t take drastic measures they won’t be as relevant, and what actions would you recommend? Terri, why don’t we start with you?
Terri: I was thinking about this question, much of it depends on where he wants to take his career you have to know where you want to go, in order to put together a plan for how to get there. Given all of his degrees, and what he’s doing, it doesn’t seem like he really wants to go off and start re-architecting software or it didn’t sound to me like he would necessarily need to get a whole computer science degree. But if he wants to really understand how the automation works maybe he takes a few classes in Python or Ruby or one of the scripting languages to help with that, and get involved with that. But it seemed like it would be pretty drastic to go out because there’s lots of opportunities to lead transformations and he’s got those leadership skills apparently. I would say, “Look for the opportunities that really fit with your personality and your skills rather than going back to school for the answer.”
Gene: Indeed, and by the way, I just realized, sorry Robin! I didn’t forget your answer—could you say what advice would you give yourself 20 years ago, and what skills are most important? Then we’ll get back to our friend Pat Birkeland. Sorry, Pat.
Robin: Just like the others, I would say people and people skills. I was really type A and really driven building my code, and I thought the harder I work the more impact I would make, but as I got older I learned really the more that I build people around me the bigger impact I make. Being able to build those co-workers or people that work for me actually magnify that tenfold, and it just didn’t occur to me at that time. I would really focus on what you share. We tend to get rewarded for what we know, but if we rewarded people for what they share, you’d be amazed at what can happen.
Gene: Thanks Robin, and one of the things that I found impactful about your presentation even just in this last London event was you shared the story about how you had created this very informal community of people just sharing, and you met weekly or monthly, and 15 years later you’re still meeting, and then you’ve all sort of ascended together. Am I misremembering that story?
Robin: No, no, we’re actually still meeting and we’re building people. I think both me and Suzette [Johnson] are in the same boat because at the same time we were we were looking for others that would help us because we’ve started Agile pretty early in our careers, and we really needed any information. There just wasn’t a lot of like-minded groups to get together and build each other.
Gene: Awesome, and I guess if I were to sort of speculate that all are sort of very curious, all ambitious, all good at networking, and what a great collection people to learn from and collaborate with.
Gene: Awesome, thank you Robin. Let’s go back to this non-fictitious Pat Birkeland, he was generous in writing up some of his thoughts and experiences. Terri, your advice was the answer is not to go back to school, but maybe more crystal clear about where he wants to go in his own career and find opportunities. I love that. Dominica, your thoughts on Pat Birkeland.
Dominica: First of all, I could definitely relate because I had the same thoughts myself earlier, “Man, I should go back and get my Master’s. I need to. I just need another degree, make more letters at the end.” But really can’t do that because of working full time with little children at home. It’s just really hard. I didn’t have a nanny. I think that what somebody can do immediately is to learn the business better. Maybe just brought it again by a bit from the business perspective and see what the business challenges and risks are. And then, figure out how to reduce some of that risk maybe by making things a little bit more predictable to you. That’s going to be such a huge growth experience to go around, and maybe visit some of the other parts of the value stream and go look at the whole value stream, and see where things are stocking. And you got making that fall in faster.
Gene: That’s such an interesting piece of advice. And by the way, it reminds me, one of the things I was always envious, if I had to do my career over again, I would have loved to spend a couple years at a big four audit firm just because I was envious my friends who could actually see the big value statement, procure-to-pay, order the cash. It was something I was envious about, just even the language they spoke in. That totally resonates with me, Dominica. Erica.
Erica: One thing that I’ve told a number of our operations personnel that I’ve had this similar conversation with is “Good people will always find a way to be successful.” I’ll hire good people any day, and they’ll acquire those new skills. When it comes to being nervous about the situation I think as long as people are eager and willing to learn new things, they’re going to be successful. And then we as companies need to set them up for success. So they’re just personally able to talk with their manager and see if they have specific areas where they see that there’s opportunities for improvement. And then like Terri said, find your passion and invest in that particular area.
Gene: There’s no shortage of problems to be solved, I think is what you’re suggesting, Erica?
Erica: Exactly.
Gene: Yeah, that’s actually great. Pat, I hope you’re listening. I’ll have this transcribed for you. Robin.
Robin: The first thing I did when after the DevOps Enterprise Summit in London is to come back and tell everybody about Nicole’s research which stated that, “Transformational leaders really improve the likelihood of your success.” We’re short on those, I would think being able to build those folks around them and really drive, help the technical folks get things across to understand the value stream as Dominica said. I think there’s plenty of work to be done there, and that would be amazingly helpful.
Gene: That was great. In fact, I mean I do love the literature that says these transformational leadership traits are learned behaviors not that the old school was like these are things you’re born with. The great man theory, that you had to be born that way, otherwise you’re just, yeah, you’re just not wired that way. I think that’s exciting. Nicole, on Pat Birkeland.
Nicole: Yes, I would start by asking in an ideal world right, what would Pat be doing in six months, and in a year? And then, work backwards. What’s your ideal job? What do you want to be doing? And then what skills do you need? Because again you take a look at what he’s been doing, look at his credentials. He’s got an MBA, he’s a theory of constraints expert, and he has a master’s in engineering management. It sounds like he’s setup to be doing incredible things right now in leading a technology transformation. If he wants to be doing that, he might need to brush up on one or two specifics of a new technology in order to like really be able to speak to the developers or the operations staff on a few of his teams, but he might be there.
And it’s funny I say that especially as I was listening to what Dominica said she wanted a master’s so she could add letters. Some people walk up to me and they’ll say, “I want a Ph.D.” because I have a Ph.D., and I’m like why? And they look at me like like I want to be the only one at the Ph.D. I’m like, “No, like why do you want a Ph.D.? Don’t get a Ph.D. just for fun.” A Ph.D. is a research degree. If, for example, if Pat says I want to be doing research in six months or a year it’s going to take more than a year, then get a Ph.D., but if you want a Ph.D. because or if you want to degree because you want someone to know you have a degree that’s not the reason to get a degree. But if the job that you want in six months or a year is to be writing code, okay, then yeah then you’re going to need to either get a degree or do some Coursera or some Udemy or something. But if what you want to be doing in six months or a year is leading transformations, you’ve got it, you’re set.
Gene: There’s many easy ways to learn these days and Ph.D. is just one of them. By the way, if I could just go back to this and this more for me, but I remember a point in my career this must have must been, must be about 2005. And, I hear all these talk about “It’s easy to learn things, yeah, rah, rah. Change is good.” I remember when Microsoft changed their database interface – it would change from ODBC to ado.net, and the reaction I had was like, “This is crap. I do not want to learn another way to access database. This is horrible.” I had no appetite for that. I mean, sure you might have had encountered people who had that reaction, what advice would you give me in 2005? I’ll take any advice from anybody, otherwise I’ll call on.
Dominica: I’ve had friends, developers, who have been extremely frustrated at the continual change in the learning. But if they feel like they learned something really good, and then it just all changes again, and how frustrating that was for them, and it made them want to go be a business analyst. But, I think that is just the nature the demand. That’s the reality that we live in, and that there’s a need, we have to learn and adapt and changes are always there.
Terri: Right, I’ve had interesting reactions from people in our organization who seem to think that learning something new is going to threaten their job right like if you move to automated test then, perhaps they won’t have a job anymore. It’s always surprising to me when people don’t want to learn because learning is sort of what keeps me motivated and excited. Although sometimes, you feel maybe it’s a step too far beyond what your current skills are. But, yeah, there’s lots of, there’s lots of ways to do that these days and to figure out. And worse, if worst comes to worst get a few of your colleagues or friends that are in a similar boat, and you all want to learn about the same thing and you go through a course or a book together and maybe a group effort might make it a little more interesting, less intimidating.
Gene: It always helps to have a buddy is what I learned. Any other advice for Gene 2005 who is enraged by ado.net?
Robin: I would just say that it’s constantly changing, and that if you’re if you’re enraged by it you’re just going to be unhappy all the time. It’s almost like it’s just a given. You might as well try to learn to like it or pretend you do.
Gene: Awesome, Robin.
Dominica: Do you think though that there’s one thing that hasn’t been talked about yet, is this sense of fear that people have. They were really good at something and they knew this technology and they were at the top of their game, everybody went to them to ask advice on this one thing and now that’s changing. That’s scary for a lot of people like “Wow, just a year ago, I was awesome at this and now everything’s changed and what the heck do I do now? I mean look at some project managers now with the whole coming out of waterfall and PMI and Gantt charts. And now all that’s being shifted upside down and where are they going to go now?” I think addressing that fear of what people used to be really good at and now that’s gone is real.
Terri: Those are really good points Dominica.
Gene: And by the way, I had no illusions that I was good at ODBC. I mean, I was barely competent. I felt like their people are just randomly shuffling chairs just to force people to upgrade from Windows 95 or whatever it was just, I saw no value in it. Yeah, but I loved that it is a fact of life and something genuinely miraculous. It’s like, who would want to go back to the old way?
We did a webinar. It was on the topic of how to get your DevOps Enterprise submission accepted to the conference, and one of the people who was on that panel was Margo Cronin. She was an Enterprise Architect at Zurich Insurance and she’s now at AWS, but we actually accepted her through the CFP process. It was fantastic to see her perspectives and the advice that she gave, but one of the things that she said really made an impression on me. She said, “Have confidence that you have an interesting story to tell.” I think she even said, “Just because you’re not the lead developer or using the new cutting-edge technologies that’s not necessarily as interesting as someone who’s helping drive behavior change and transformation in large organizations.” Do you agree with her? And if so, what advice would you expound to anyone who has a story to share, but maybe are hesitant to. Let me call on you Dominica. And Dominica this is great because you’re on the programming committee.
Dominica: I hear this a lot! People don’t feel like they have a story to share, but everybody does. It’s a different perspective that they can bring and there’s a lot of similar nuances that we all go through, but I think to hear, especially somebody that we haven’t heard from before, a new fresh perspective and their challenges always makes for an interesting story.
Gene: Maybe you can shed a little light outcomes of the process right now. We’re looking at every one of these submissions and we are looking for interesting stories.
Dominica: Yeah, how many submissions did we have for San Francisco?
Gene: It’s over 250 almost 300.
Dominica: Yeah, going through all of those is a challenge and one thing that I really look for is original, real wording of people telling a real story and not shying away from using their own language. I don’t think people feel should feel that they have to conform to using the book-written perfect language in a submission. Just say whatever—what’s the problem, why it matters, what they did about it. The real story that’s what I want to hear what worked, what didn’t work, what was some of the failures, and where they are right now, and where they hope to go.
Gene: Great. Yeah, the lull of deliberation. In fact, one of the things that maybe most people might not know is just the level of the intensity of some of these debates of who we accept in the conference. I mean is that something that gets very, very heated. I’m not sure it was actually hung up and out of the meetings, but sometimes very close. Erica, how about you?
Erica: So, yes I actually had a conversation with a co-worker of mine after we attended a local DevOps meetup here, and she said, “I would love to at some point work towards a goal of presenting at this [event].” And she actually comes from a non-technical background and she has participated in a lot of the same things that I have in our DevOps journey and I said, “You know, I think it would be interesting to hear the same story told through your eyes, and I think it would be a different story than my version of it, and just the different things that stick out to you and were amazing to you.” I really encouraged her and I said, “I’d like to hear this story.” Even just the two of us telling that same journey, different perspectives on that are very, very interesting.
Gene: And are you referring to the portion of the presentation you gave last year, which was when a dev manager takes over ops?
Erica: Yes, yup.
Gene: I would love to hear that story. In fact, three of your colleagues actually did submit through the CFP. I’m eager to see where that goes. Thank you for any encouragement that you gave them. Thanks Erica. Robin.
Robin: Just like Erica, I think everybody has a story to tell, and through another person’s eyes it’s a whole different perspective. Sometimes the things that we do every day seems commonplace. That happens to me all the time, but then, when you tell somebody else they’re like, “Wow, I didn’t even know that existed or how would you even do that.” I think, again, just having confidence in yourself and realizing you actually have something unique to sell other people is what you need to do.
Gene: Interesting, thanks. Nicole.
Nicole: Yes, sometimes when I think about what might be a good topic to talk about when I go to conferences, I think about things that I do pretty commonplace or things that are pretty easy and think about what used to not be super easy, right? If it’s a process that I’ve done or a process or what we’re working through right now, and then what that journey has looked like. Right? Because if I can do it now, and it’s pretty easy, and it’s almost habit or reflex, when was it not a habit and reflex. And then, how did I get here? What were the steps that I got here? Did we have a checklist? What were the crazy hurdles? Because if it’s easy for me now and it probably wasn’t easy for me at some point, I had to learn to get there. That’s probably going to be useful or at least interesting to someone.
And then, write that up. And then, that’s the story, but then writing it up I think is another piece. And like Dominica said, I’m on a budget program committee, write it up that when I’m reading 300 submissions or a 1,000 submissions it stands out to me and it’s interesting I can tell you’re going to have some personality onstage and let the audience know what they’ll get out of it. That’s when they read it in the brochure, they know like which talks to go to. What takeaways am I going to get from this? Am I going to have a few tips and tricks? Am I going to know what to avoid? Am I going to know where to start? Those are some tips in terms of like writing submissions. And sometimes I forget when I write my own submissions, so none of us are perfect.
Gene: Awesome.
Nicole: Keep trying. I mean, I still get CFPs rejected. We all do.
Gene: No, it’s so true. Terri Potts.
Terri: Yeah, I do this a lot with people in my organization because moving up the career chain at Raytheon often requires you if you want to stay technical to start presenting. First maybe internally within Raytheon and then externally.
Nicole: I love that.
Terri: Yeah, so a lot of times people think, “Wow, what I do? That’s boring.” I try to just have a conversation with them to get them to tell me some of the things that they’ve done recently. And some of the things I really like to hear about is, “Okay, you started using Puppet or you started using Chef, did that just go perfectly the first time?” “Well, no we tried this and that didn’t work. Then we did this.” I’m like, other people would love to hear that they don’t make those same mistakes. So write something up to say these are things that we found that work really well and these are things that we found that didn’t work so well, so don’t repeat those mistakes.”
Gene: That’s great. As a professional conference goer, I mean I love one of my favorite variances like the internal technology conferences because this is a hope of the shared context that’s already shared. There’s a mercenary reason why you want to help people within your own organization that isn’t present in a more industry-wide conference. I mean I just really I got to attend the one at Capital One and at Nationwide Insurance. I just, they really stand out in my memories. Just incredibly unique experiences and so great for internal technologists to be able to show off the amazing things they’ve done.
All right, we’re almost out of time, one last question. I think a theme that’s come up over and over again is we’re lifelong learners. Learning is part of the game, in this game that we’re playing. Learning is definitely part of it whether we like it or not. Hopefully, we’d like it far more than we don’t. What are your top resources for learning? Maybe answer two ways—of all time and maybe right now here in the moment. Erica, let’s start with you.
Erica: Sure. Of all time, once upon a time I had like my C++ book that I referenced all the time before I really even used Google, so there was those sorts of things. But, much more recently, I rely heavily on Twitter, and a lot of the things that I see on Twitter and on leaders in the DevOps space, and what are they reading, what are the things that they’re tweeting about. There’s obviously books like The DevOps Handbook. And The Phoenix Project and I try read probably about one book at a time, but then I like to just see what’s going on space. Yeah, I’ll see whether there’s a conference going on and I’ll go look for that conference and what’s going on with that conference and the slides that are coming out of that, and that helps me stay current. And then just rely on co-workers as well. They’ll send out emails and different articles that they’ve read.
Gene: That’s awesome. By the way, one of the things I just want to punctuate is several of you mentioned, it always helps to learn with co-workers. I mean I remember teaching myself JavaScript in React, and it was incredibly gratifying, but it was horrible beyond words because there were like 40 tools I had to learn what they were and I didn’t care. Just that it always helps to have a buddy in learning things. I love that pattern. Thank you, Erica. Robin, top resource for learning.
Robin: So, I again I follow Twitter just like our counterparts here. I am a big fan of LinkedIn, I read LinkedIn and read the latest things there. I have a membership to Safari Books. They always have the latest technology books which I just love. And I read the blogs. It’s interesting because you get many different perspectives on the different blogs you hear and what Mike Cohen thinks is cool and Ken Schrader, and then you turn around and hear David Anderson. Maybe they don’t all play nice in the sandbox, but it’s interesting to hear what they have to say.
Gene: Twitter, it is interesting and we always used to dismiss it as a toy, but more and more I find it interesting just to some of the most interesting reading comes from what other than what my friends are reading. Interesting Robin. Nicole.
Nicole: For my overall best learning it’s probably my Ph.D. because it taught me how to do a lot of critical thinking, statistical thinking, pulling things apart, how to design, and critically pull apart research and think about things in a really concrete, consistent, detailed way. And then overall in today, Twitter, news sites. I try to make sure I keep it as well-rounded as possible. New York Times, Wall Street Journal, Al Jazeera, and I try to keep up on what my friends are reading, but then I also try to occasionally do a random search to get exposure to things that my friends aren’t reading.
Gene: Great. Thank you, Nicole. Terri.
Terri: Let’s see, far all time, I mean I’ve kept a membership for IEEE and ACM for years just trying to keep track of what’s going on, but now things are a lot more electronic. Some of the things I do regularly is I try to listen to most of the Software Engineering Daily podcast episodes.
Gene: Oh, great.
Terri: And all the SE-org podcasts, which they’ve had a tremendous amount of podcasts that I found really, really useful. And of course, I do go to a few conferences every year, so I’ve learned a lot at DevOps Enterprise Summit, and this year I presented at the SEI’s Architecture and Technology User Network Conference, and it was really, really good to see the amount of architecture work going on around figuring out how to transform legacy systems and architect for automation in this assembly.
Gene: That’s great. And by the way, I echo your endorsement of the Software Engineering podcast as they have great people in there.
Nicole: Yeah, and I’ll plus on IEEE and ACM. ACM Queue has been really fantastic.
Gene: Yes, and then last is Dominica.
Dominica: Yeah, I’ve learned much from watching TedTalks. That’s one of the greatest sources of learning for me for years now. I mean Hans Rosling, “Let my dataset change your mindset”—in 20 minutes what you can learn from that. Or David McCandless in “The beauty of data visualization”—just phenomenal. And then the DevOps Enterprise Summit videos over the last four or five years, from the tech side great, great learning resources straight up on YouTube, easy to get to.
Gene: Awesome, yeah, because there’s a YouTube channel you can just subscribe to it, and then you’ll be notified whatever there’s a new one. In fact I was going through them last night. Awesome, well, hey thank you much. I so much appreciate your time and you sharing all of your experiences. This is a topic that is near and dear to my heart, and I think we were actually going to be writing this up that people can actually access it in written form and the summary of it.
I look forward to seeing you all soon, one way or another. At the very latest at DevOps Enterprise in San Francisco. I hope you’ve learned as much as I have today.
Thank you to all the panelists who are doing amazing work in all your respective organizations, and you will be able to see them too Nov. 13-15 at DevOps Enterprise in San Francisco. It’s at the Hilton Union Square location and look for updates on the website at events.itrevolution.com. In fact, we’ll be announcing more speakers in the next week or two as we start processing the CFP submissions. And just a reminder, last reminder early bird ticket pricing ends on July 31 be sure to register soon for a 20 percent discount!
With that, thank you much Erica Morrison, Robin Yeman, Nicole Forsgren, Terri Potts, and Dominica DeGrandis. See you next time, all.
It’s time to start implementing the practices of Continuous Testing
Earlier this year, Computing Magazine conducted a fascinating study around the adoption and benefits of DevOps in its DevOps Review 2017 publication. The findings that stood out most fascinating to me where around quality assurance and testing.
In this survey, the question was asked, “Where are the main holdups in the software production process?” Of all the self-proclaimed DevOps practitioners, a whopping 63 percent said the biggest delays occurring in the QA/Test phase. In fact, this cited bottleneck was more than 2 times greater than the next proclaimed bottleneck, which they felt was in planning (29 percent). In this same survey, another question asked, “What tends to lose out more in DevOps environments?” While 43 percent said, “Nothing,” nearly 30 percent of these DevOps practitioners said that quality was being sacrificed. When asked which area they wanted to focus on improving in the next year, over 40 percent opted for quality.
Why is it that quality has taken such a hit? The study cited two issues: 1) Testing and QA is often siloed from the other parts of the organization, and 2) Testing tools haven’t matured much in the past five years.
Testing must become a cross-functional operation across the software development lifecycle (SDLC) spectrum, one that involves all teams. Agile developers and testing teams don’t have weeks to test, but hours. Testing hasn’t kept up because it hasn’t applied the methods and concepts of agile development have not been applied to testing and QA processes. By removing the constraints that force testing to the end of a development cycle, developers and QA teams can achieve accurate, automated testing from day one. They can create an integrated pipeline, capable of taking an idea from design to deployment, at speed, without compromising quality.
Open-source, cloud-based solutions can be the catalyst that brings the speed of agile to testing. Here are a few examples.
Better In-Sprint API Testing: Since APIs have become the major component of applications, organizations are shifting their approach from starting testing when the user interface is complete to shifting the focus of testing at the API level. But the hard thing is finding enough time in a development sprint to test them sufficiently.
Today’s applications are a collection of microservices and API calls. UI testing alone just won’t cut it. UI testing is very brittle, and whenever it changes, testing breaks. Testing needs to shift left into the development cycle—into sprints. But if you shift testing left to be a focus of the sprints, what kind of API testing can you really do? How comprehensive can they really be? Creating those API tests has to be quick, and simple.
Dev and Test teams must utilize automated tools that not only generate API tests, but create an exhaustive set of test cases from the API, then execute those tests. These tools also need to support the most popular open-source testing frameworks allowing developers to run functional API tests as performance tests without any proprietary conversion issues. And, vice versa, developers must be able to take open-source performance tests and be able to run them as functional API tests.
Orchestrating Testing: A Continuous Delivery Pipeline Manager: “Faster” is becoming table stakes with automation. The facts show that companies who have widespread agile adoption and are deploying more frequently with significantly reduced lead times. But, this too often leads to release failures, quality issues and disorder with multiple—if not hundreds—of applications rolling through the SDLC. Plus, things slow down significantly with time-consuming handoffs and rework in the release process. DevOps teams, who release features and fixes frequently while significantly reducing errors and manual processes, need toolchain-agnostic pipeline planning, orchestration and optimization solutions that enable them to eliminate spreadsheets, automate test processes and feedback, and continually improve the delivery of revenue-generating features to end-customers. New CD SaaS tools help make this orchestration process easy.
Performance and Functional Testing Using Open Source Frameworks: More and more organizations are trying to move from legacy testing tools. It’s not so much that these don’t adequately test, but they were never designed to meet the needs of agile development approaches. Rather, they were designed for releases that occurred two to three times per year. But that won’t cut it anymore.
These are just a few examples of how continuous testing eliminates the testing hurdle. With continuous testing, organizations can:
Automatically convert user stories from requirements management tools like CA Agile Central or Atlassian JIRA into the minimum number of test cases required for complete code coverage, and being able to adapt automatically to changing business requirements.
Reduce test cycle prep time by requesting test data from within requirements.
Request, reserve, and create test data at any time, even from requirements phase.
Virtualize APIs for better testing, while managing API access to developers.
Institute easy API testing that can generate comprehensive test cases (positive, negative, edge case, and SQL injection) and execute those tests automatically.
Democratize testing with SaaS-based testing tools so that developers can test early and test often.
Speed testing by feeding test data directly and securely to virtual services.
Use open-source testing tools such as JMeter, Selenium, Jenkins, Jenkins, Appium, Taurus, Gatling, Locust and more.
Orchestrate the application delivery pipeline to promote releases from one environment to the next as soon as all the tests pass and enable faster feedback loops.
This is testing unleashed, going hand in hand with agile development to accelerate quality into production.
By adopting next-generation testing practices, DevOps teams have the ability to test early, often, automatically and continuously. To learn more about continuous testing and why it is critical to DevOps and Continuous Delivery initiatives, visit this Continuous Testing informational page.
Are there scenarios where crashing containers simply being replaced might be acceptable? I would argue no. They’re software errors. The world has not changed; errors are still bad. I can invent “but if you …” scenarios as well as the next person, but the fact is, if your software is crashing—be it container, VM, hardware, firmware or whatever—you did something wrong and you can’t know the extent of the issues the crashing creates without digging into the problem. At which point, you may as well fix it.
Fig: ESB Integration Bus Facilitating Adoption of DevOps
Fig: DevOps scenario achieved in a collaborative tool environment
Sanat Singha is a senior technical and web marketing writer. He takes special interest in ALM process, technologies and tools integration as an industry. Sanat does content marketing, professional blogging, social media promotion and website analytics.
This is testing unleashed, going hand in hand with agile development to accelerate quality into production.