devopsy.kinsta.cloud

Tag: software development

source{d} Delivers Enterprise Edition of SDLC Platform

source{d} has made available an enterprise edition of its software development lifecycle (SDLC) platform that includes visualization and analytics tools along with additional management capabilities. A free community edition of the core source{d} platform, which is stripped of most of the enterprise-class tools, also is now available in beta.

Company CEO Eiso Kant said the enterprise edition of source{d} provides the additional tools enterprise IT organizations require to employ the platform as the equivalent of a business intelligence (BI) application for managing DevOps processes.

The tools can launch queries against a big data repository based on the Apache Spark in-memory analytics engine running on a Kubernetes cluster, which can be populated with actual data or metadata pulled from multiple DevOps tools and platforms. That capability enables IT leaders to then query data that has been joined together in a way that surfaces actionable intelligence, said Kant.

source{d} Enterprise achieves that goal by including Apache Superset, an open source business intelligence web application. The platform also can be extended to support SQL queries launched from other BI tools and project management applications. The enterprise edition also provides access to advanced queries and user-defined functions to address tasks such as code duplication analysis or identity matching.

Finally, source{d} Enterprise provides authentication integration with LDAP and OpenID to limit who can edit or view queries, data sources, charts and dashboards.

Longer-term, source{d} plans to leverage predictive analytics and machine learning algorithms more aggressively as the amount of SDLC data that gets collected by enterprise IT organizations increases.

Kant said many enterprise IT organizations have tried and failed to build the equivalent of source{d} platform mainly because bringing together and then maintaining all the required technologies often becomes too complex an undertaking. Those efforts also have been confined largely to managing processes such as bug fixes versus including all the BI tools needed to manage software development in a way business and IT leaders can align technology initiatives to specific business goals, he said, noting the source{d} approach brings together enabling technologies such as Spark and Kubernetes to enable IT organizations to deploy an SLDC platform on-premises or in a public cloud.

As software development increasingly grows more complex, the days when it could be managed efficiently through a project management application alone have come to an end. At the same time, more organizations realize their success ultimately comes down to how consistently they can deliver a high-quality application experience. For all the hype surrounding digital business process transformation, the core tenet is that most organizations are indeed becoming software companies. As such, they need to borrow many of the SDLC processes that successful software companies employ routinely. The only real difference is they don’t need to develop those processes from the ground up when more turnkey SDLC platforms are emerging.

— Mike Vizard

July 9, 2019
State of the Software Supply Chain: Secure Coding Takes Spotlight
After almost a year of research that involved studying 36,000 open source software projects, 12,000 enterprise development teams and 3.7 million open source releases, we at Sonatype are excited to share the “2019 State of the Software Supply Chain” report.

This year, we worked with research partners Gene Kim, founder of IT Revolution, and Dr. Stephen Magill, principal scientist at Galois and CEO of Muse, to examine and empirically document objectively for the first time the attributes of exemplary development practices, especially in relation to secure coding practices. But, as in years past, we’ve also analyzed the rapidly expanding supply and continued exponential growth in demand for open source components.

Not All Open Source Projects Are Created Equal

For the past four years, we’ve studied the ins and outs of the software supply chain—what it’s comprised of; how vulnerabilities are getting in and how often; the growing regulations; and, most recently, a new trend in which adversaries are purposely attacking the supply chain with malicious components.

For our fifth anniversary of the report, we wanted to look deeper. We wanted to understand exactly how enterprise development teams—and potentially even more importantly, how OSS projects—were thinking about and addressing the software supply chain security issues. We wanted to understand and identify the very best practices so we could share them with others.

As a result of our research, we identified five common behavior patterns across 36,000 open source development teams. This includes identifying attributes of Large Exemplars and Small Exemplars who rest within the top 3%, or 1,229, OSS project development behaviors.

To arrive at this list, we examined a large number of variables, including:
- Do differences exist in how effectively OSS projects update their dependencies and fix vulnerabilities?
- Are there exemplary teams that do this better than others?
- Are components from exemplary teams more widely used than “non-exemplary” components?
- What factors correlate with exemplary components?
- What advice can be offered to producers of OSS components and the developers that consume them?
The answers were quite striking—and the resulting data even more illuminating. While the report identifies Small Exemplars and Large Exemplars, we’ve also identified three additional groups of OSS projects: Laggards, Features First and Cautious.

Exemplary Commercial DevSecOps Practices Create Superior Software

There are clear, competitive advantages for teams with exemplary DevSecOps practices.

We’ve known for years that innovation is critical, speed is king and open source is at center stage. This research further underscores these accelerating trends throughout the software supply chain. It also shows that taming the supply chain is possible. By making better supplier choices, component selection and using automation, dev teams are seeing impressive rewards. In fact, for those development teams actively managing their software supply chains, the use of known vulnerable component releases was reduced by 55%.

The report details 11 other behaviors and attributes of leading enterprise development teams, including their frequency of software releases, their use of repository managers and their reliance on a software bill of materials.

Gene and Stephen helped shed new light on exemplary development and DevOps practices that I believe will help developers around the world better understand what secure coding means and how to start addressing it.

— Derek E. Weeks
July 5, 2019
The Purpose of Microservice Architecture
Microservice is an architectural style that can be implemented during complex application development within an organization. The implementation of this architecture allows the application being developed to be highly maintainable and testable, loose, independent during deployment and also strongly organized around business capabilities. In another way, the microservice architecture can be explained quite easily. It is a software development technique that allows for the structuring of an application. The structure of the application being considered will be that of a set of coupled services.

Any application developed using the microservice architecture is easy to understand, develop and test. More so, the application will have a sort of rigid attitude to degradation in the long run. This is due to the concept adopted during design.

The design of the microservice architecture ensures that applications are separated into smaller services, states, etc., until they become fine-grained and light in weight. Therefore, the modularity achieved encourages the adoption of methodologies that will allow for the division of labor. These methodologies will aid in the concurrent design, development and testing of the sub-services independently.

While this architecture is suited to certain scenarios, it (like every other architectural style) has its demerits. Microservice experts advise on the study of the architectural platform before adoption. The implementation of the microservice architecture can be affected by a number of programming languages.

Within the context of this article, I discuss the purpose of the microservice architecture, and also examine the upside and the reasons why they should be learnt and implemented. I also take a look at particular niches that allow the use of microservice architectures and why they use it.

Architecture, Examples and Types of Microservices

The microservice architecture is a major decomposition of the monolithic architectural method. The monolithic architecture had applications developed from the top to bottom and also had the entire development process run as a single unit. The microservice architecture works in contrast to this by enabling modularization. The core of the microservice architecture has requirements that are intensified and made possible by the separation of the primary task into smaller services, in which one service represents just a requirement, function or need.

Examples of microservice architectures can be found in airline service scenario. If we pick out the flight booking component, we could find out that this primary task could be separated into inventory adjustment, seat allocation, fare calculation, timetable lookup, reward management and customer update.

Applying Microservices

Research has it that the majority of the companies that make use of microservices are quite on the high side. This majority includes organizations such as Netflix, eBay, Amazon, PayPal, Twitter, The Guardian, etc. This list also includes the United States Government Digital Service.

The application of microservices can work with a number of technologies but a number of researches attribute effective usage of this architecture with the cloud environment and the DevOps environment as well. These tools and environments help to manage the operational complexities that affect the swift functionality of the architecture.

Why Do They Use It?

Most of the organizations that make use of the microservice architecture did transcend from the monolithic method. This is mostly because the method offers organizations the ability to decompose primary applications into smaller composed pieces. These pieces can then be built independently (which is easier) and also maintained independently as well. Developed pieces have the ability to communicate with each other and work together as well.

The adoption of microservice architecture provides the management of an organization and everyone involved in the development of the application with a decentralized approach towards building the software. This approach breaks the development process into a series of deploy, rebuild and redeploy.

The choice of a microservice architecture also grants organizations the ability to implement variant strategies, tools, techniques, etc., for services that are involved. Studies show that organizations that implement this architecture have a high proficiency rating. This is due to the usability of the architecture in independency, deployment, replacement, etc.

The architecture encourages easy debugging of errors and detection of faults in general. When an error is spotted, the segment from which it originated can be easily traced and the fault can be found shortly after. This, as explained earlier, is because primary tasks are separated into smaller services. Each service can then be fine-grained to simple state. Before the simple state is attained, it is also possible that the service can be separated into a smaller group of services. This option helps the development team actualize a major concept within this architecture, which makes sure that a service handles just one task. Also, the architecture allows for the adoption of management techniques that assist the organization. These management techniques include options such as change management process, continuous software development processes, problem and incident management techniques, etc.

Benefits to Using Microservices

The benefits to using the microservice architecture include:
1. The actualization of scalability when considering customer-focused services.
2. Independent deployment of services.
3. The ability to work with more than one development tool (such as programming languages).
4. Easing the modularization of tasks within the project as a whole due to the modularization of the application being developed.
5. Support for a wide range of platforms and devices such as web, mobile, internet of things, etc.
— Subramonian
July 3, 2019
Clubhouse Aims to Simplify Software Project Management

Clubhouse Software today announced it is adding a Clubhouse Iterations module to its project management application to make it easier to plan sprints involving product and software engineering teams.

Mitch Wainer, chief marketing officer for Clubhouse Software, said Iterations will be included as part of its project management application service, which aims to bridge the divide that often exists between software development teams and the lines of business for which they are building applications.

Wainer said the company’s namesake project management software makes it easier for non-technical professionals to participate in the same project management workflow as a development team, rather than requiring them to become conversant in a project management application designed for software engineers, such as Jira. Clubhouse’s approach eliminates silos that get created when two teams within the same organization rely on different project management applications, he said.

Clubhouse Iterations goes a step further by surfacing what teams need to focus on as priorities and timetables change within a specific project, added Wainer.

Clubhouse Iterations allows users to define sprints using start and end dates, and the tool then sends reminders so the team can reserve time to focus on specific projects, he added.

Organizations that have successfully embraced DevOps almost invariably seek to extend those processes beyond the software development team. In theory, at least, the entire business should aspire to become more agile. However, the project management software many DevOps teams employ today is too complex and intimidating for the average business executive. Rather than forcing business users to learn how to master these applications, a case can be made for a more intuitive set of project management tools for both software development teams and the product managers they ultimately serve. Wainer said Clubhouse is already being used within 2,000 organizations to address that issue.

Wainer also noted the Clubhouse Software also has no bias as far as continuous integration/continuous delivery (CI/CD) platforms are concerned. Clubhouse is designed to integrate with multiple CI/CD platforms via application programming interfaces (APIs) to enable the development of custom workflows that include, for example, integration with real-time conversations occurring via the Slack service.

Next up, Wainer said Clubhouse intends to improve the search capabilities it provides on the platform and offer more sophisticated reporting tools.

In the meantime, the rise of DevOps would not be possible without the capabilities enabled by project management applications. But the agile nature of DevOps processes is forcing providers of project management software to make their applications both more dynamic and accessible. Those advances, in turn, make it easier to bring new members on board to the DevOps team.

Project management software may not always be viewed as the linchpin around which most software development processes are constructed. Without some form of project management application, however, most DevOps processes would have devolved into utter chaos a long time ago.

— Mike Vizard

June 25, 2019
Shift Left Without Fear: The Role of Security in Enabling DevOps
It’s the age of DevOps, and we all want to shift left, which refers to the idea of performing processes earlier in the CI/CD cycle. That includes security checks and audits. By starting security operations earlier in the delivery pipeline, it becomes easier to find problems, and teams have more time to address them before pushing code into production.

The challenge, of course, is building a shift-left security operation that allows you to perform security operations early without slowing down delivery speed. Let’s take a look at how to square that circle.

Defining Shift-Left Security

A popular term in DevOps culture is “shift left.” But what does shift left mean? Shifting left refers to the effort by a DevOps team to implement measures to ensure application quality at an early point in the software development life cycle. In the case of application security, this means implementing measures to ensure security concerns are taken into consideration while the application is being developed, rather than at the end of the process.

The overall goal of shift-left security is to identify and resolve potential vulnerabilities earlier in the development life cycle, when these issues are less expensive to fix. Doing so will help to mitigate the risk potential security concerns pose to both the delivery schedule and your end -users.

DevSecOps: Integrating Security Into the Development Process

Let’s be honest: Faster and more frequent development cycles aren’t going away. Slowing delivery speed to analyze and bulletproof the application at the end of the development process is no longer a viable format for implementing security. DevOps and CI/CD need to be embraced and enabled by the security staff.

For security teams to enable the DevOps process, collaboration is key. Through this collaboration, the process of DevOps transforms into something known as DevSecOps. In DevSecOps, security personnel work closely with the rest of the DevOps organization to help those who create and deliver the application to gain a better understanding of what is needed to address security concerns as early in the development life cycle as possible.

The following tips serve as a jumping-off point for implementing this collaboration:
- Make security the responsibility of the entire DevOps team: Impress upon the development and operations staff that security is now the responsibility of the entire organization. Simply addressing potential vulnerabilities post-development will eat up too much time and increase the risk that something will be missed. Buying into this process is an essential part of implementing successful collaboration between the security team and the rest of the organization. An example of this would be impressing upon developers to code with security in mind.
- Facilitate regular discussions about application security throughout the development process: It is the responsibility of the security folks to keep security considerations at the forefront of a developer’s mind while they develop new features. Use the agile process to your advantage. Backlog meetings can involve security folks to ensure the creation of user stories includes consideration for security concerns. Your daily standup meetings are another place to include security personnel. This will provide security staff with an opportunity to speak up when the work described by the developer requires—or might require—considerations related to security that have yet to be addressed. Doing so will help to ensure the ball is not dropped, allowing for potential issues to be rectified before they even exist.
- Use test automation and continuous integration to your advantage: When it comes to addressing security concerns throughout the development process, continuous testing is your best friend. And, in cases where it makes sense, the DevOps team should integrate automated test scripts for the detection of security and into their continuous integration process. Such tests can include developer-written scripts to test for vulnerabilities in the code base and tools for static code analysis. Another part of your continuous testing strategy could involve the use of tools for infrastructure monitoring.
The data produced by these strategies can then be analyzed by security folks. And from this analysis, recommendations can be made to the DevOps team regarding the path forward to close potential gaps in security before they ever reach production and can be exploited.

Understanding the Role of Security Personnel in the Development Process

Security folks are often not coders, and development personnel are often not security experts. And while it may be frustrating at times, the solution to managing this disconnect is in the collaboration described above. Situations will arise where developers need to develop with various technologies to build a quality product. It’s possible that these technologies will lend themselves to security concerns that require security expertise. The job of security personnel shouldn’t always be to fight back against the use of these technologies. The security team should act as facilitators—take what development and operations staff intend to do and foresee the potential impacts that innovation will have on security—then take these potential impacts and provide insight into what needs to be done to reduce the risks.

Conclusion

In the past, security often was considered as an afterthought in the development of an application and its infrastructure. The movement toward faster development cycles and more frequent application releases has forced development organizations to think about security differently. Nowadays, so much can change in an application in a short time. This has forced DevOps organizations to integrate security into the development pipeline to make security a continuous consideration in the development life cycle. With this integration, the responsibilities of security personnel have shifted. Security teams now need to be enablers of the DevOps culture, empowering DevOps processes with security in mind.

To see how Symantec CWA can help you shift left without fear, sign up for a free trial to see how it can help secure your cloud.

— Scott Fitzpatrick
June 11, 2019
Citizen Developers Drive Productivity and Innovation

It was once written that “software is eating the world,” “APIs are eating the world” and “APIs are eating software.” In 2019, a more accurate statement might be, “APIs (or application programming interfaces) fuel the software that’s still eating the world.”

In today’s world, there is an ever-constant demand for software, enterprise applications and mobile applications, and most company IT departments can’t keep up. Enter the citizen developer. Citizen developers are helping organizations close the demand gap and innovate more quickly. But who are they and what role do they fill within an organization? And how do they contribute to overall technology innovation within a company?

Citizen Developers and the Need for Speed

The ongoing need to develop software quickly and efficiently has given rise to a new type of developer. A citizen developer is a non-professional developer who builds new business applications using existing tools, development and runtime environments sanctioned by corporate IT. They also can access various online tutorials to learn and master their application-building skills.

Today’s software development environment, powered by APIs, is ripe for the citizen developer. APIs, mobile application development kits and the cloud have created a no-code/low-code, building block-like approach to building software. Less code and a more simplistic software development path allow citizen developers to create much-needed apps quickly. This building-block approach cuts development time, translating to faster time-to-value.

Speed is critical not only in the creation of new apps, but also in the end user experience of these apps. With the building-block model, citizen developers use best-of-breed technologies for each block—making the resulting UX optimal (and fast) for an internal user or customer end user. Internal users are able to use fast, effective search within employee directories, company intranets and project management solutions, for example.

For end users, this need for speed addresses their ever-growing expectations. When someone searches for hotel deals in Phoenix, for example, they expect accurate, personalized and fast results. Even a one- or two-second delay can translate to lost opportunity and revenue.

The Workplace

In the digital workplace, citizen developers serve a key purpose. For starters, they know firsthand about the challenges employees face at work; they also know which applications or tools are critical to getting the job done. These non-IT developers (perhaps in a business or marketing role) help create apps for timesheet entry, productivity tracking, project workflow reporting and more. In one study, 76% of businesses stated that at least some of their apps were developed outside of their IT department—and 20% even stated that most of their applications were created outside of IT.

Citizen developers often use low-code tools or visual tools with some degree of coding required. Low-code allows developers to design and develop software applications with minimal hand-coding, while low-code platforms enable users to build applications with modern user interfaces, integrations and data quickly without writing thousands of lines of complex code. Also, citizen developers may work alongside software developers and database experts to develop apps with custom coding to meet specific enterprise or company needs.

Citizen Developers and IT: Working Together

When citizen developers work alongside IT, two things happen. First, by creating simple apps on their own, they enable IT to focus on developing more complex applications. Second, when building more complicated or customized applications, IT can use citizen developers to derive valuable insight. This data helps with testing or tweaking business app prototypes. With low-code, citizen developers with some technical skill start with a prototype and then can iterate with the IT team during the developer phase and later integration of systems, custom coding and security processes. Also, developers, who are often asked to understand more of the business side of the organization, gain this insight working with workplace citizen developers. And the results are promising: 82% of citizen developers said they witnessed a reduction in inefficient tasks while 71% reported an increase in team productivity.

In the past, IT spearheaded application development projects from beginning to end. Now, with citizen developers becoming an integral part of the workplace, IT’s role changes a bit. While no longer in full control, IT does give recommendations to the business department and selects development components and building blocks.

Just the Beginning

When it comes to search software, citizen developers have the potential to create personalized and customized experiences. While some types of front-end search are simple to create, developing a personalized and customized search experience is more complicated. This is where the current work lies and in doing so, we can build a new community of search-focused citizen developers.

This is only the beginning, as there will always be a demand for developers (both traditionally trained and citizen developers). In the coming years, we will see more citizen developers as there literally aren’t enough engineering schools to train students to meet business demand. They are helping to democratize application and software development across the board—and we can expect to see businesses and consumers continue to benefit.

— Julien Lemoine

May 29, 2019
Open Innovation Labs: How Lockheed Brought Better Security to Fighter Jets

How Red Hat’s Open Innovation Labs have helped accelerate Lockheed’s software development for the F-22 Raptor

As the key government contractor charged with helping the U.S. Air Force keep its F-22 Raptor jets in fighting trim, Lockheed Martin Aeronautics increasingly values software delivery speed as much as engine speed. So much of the continued evolution of these fighter jets depends upon continual upgrades of the software code powering all of the physical systems built into them, from tip to tail.

Until a year ago, these jets, which first rolled out of the manufacturing plant in the 1990s, were supported by the waterfall development methods of that same era. Lockheed executives and Air Force brass recognized that the F-22 needed a DevSecOps transformation, and fast.

“When you have a world-renowned platform like the F-22 Raptor, adversaries are constantly looking for ways to counter it,” said Michael Cawood, vice president of F-16/F-22 product development at Lockheed Martin. “This means we must constantly add capabilities and improve the F-22. And we must do it faster than ever before. We needed to transform our own organization and how we did things.”

To accelerate that process, Lockheed last year sent a small contingent of engineers through a residency program at the Red Hat Open Innovation Labs to fast-track the process of implementing an open source architecture onboard the F-22 while adopting agile development methodologies and DevSecOps practices. Since bringing back their learning to the organization, these engineers helped to catalyze a faster development process that has helped Lockheed introduce software features for the F-22 years ahead of schedule.

How Open Innovation Labs Works

Now in their third year of operations, the Open Innovation Labs were developed by Red Hat as immersive training grounds to help its enterprise customers figure out how to deliver better software, faster. A standard engagement has companies such as Lockheed pay for residency for anywhere between three to six developers and operations staff to get paired one to one with Red Hat employees—engineers, consultants and others—with deep knowledge in DevOps and agile development. They work with them in a time-boxed four- to 12-week engagement to build out application prototypes using DevSecOps practices along the way. The residents are also teamed with a designer and an engagement lead who doubles as an agile coach, typically working with the customer’s product owner for the prototype.

Obviously, Red Hat has a vested interest in training these people in technology such as its OpenShift Container Platform, getting them up to speed on how to orchestrate and manage containers and microservices. But the labs approach is in a different league than the standard vendor training program. It more closely follows the DevOps dojo model that enterprises like Target and Capital One are running internally to scale up cultural and process transformations across their IT organizations. Like those dojos, the working model is to build real software through a guided learning process that helps participants get hands-on experience in how to change the way they deliver software.

Red Hat runs the labs either out of a handful of dedicated spaces it runs around the world or within pop-up labs of the customer’s choosing. Besides Lockheed, other notable alumni include the likes of Volkswagen, UNICEF and Heritage Bank. According to a recent analysis by Forrester Consulting, participants in the Open Innovation Labs program are accelerating application development by more than 60%.

Lockheed’s Accelerated DevSecOps Transformation

In Lockheed’s engagement with the Open Innovation Labs, the organization sent out a cross-functional team of five developers, two operators and a product owner. They were tasked with building out a new application for the F-22 on OpenShift, using that process as a model for future development workflows. As a part of the process, Lockheed also worked with the labs to help it build out an internal dojo that could facilitate the scale-out of the knowledge gained by its small team across the entire F-22 development team. Six months after the initial residency, Lockheed managed to scale its OpenShift deployment and DevSecOps transformation across its entire 100-person team.

“By working with the Red Hat Open Innovation Labs team, we changed everything—our toolchain, our process and, most importantly, our culture,” explained Cawood.

As a result, the F-22 development organization has been able improve its ability to forecast for future sprints by 40%. More importantly, it has cut what was once an onerous five- to seven-year process of rolling out new software capabilities for the aircraft. Lockheed is on track to deliver new communications capabilities for the F-22 this summer a full three years ahead of schedule.

— Ericka Chickowski

May 21, 2019
The State of Low-Code Development

As enterprises continue to play catch-up when it comes to meeting their internal demand for new software services and applications, more enterprises—but still, only a minority—are turning to low-code development platforms to try to fill the gap.

Low-code development platform provider OutSystems released its sixth annual “State of Application Development Report.” The report is based on surveys conducted in March of 3,300 IT professionals.

The report found that a sizable minority (41%) of respondents are already using low-code platforms, while another 10% stated they were about to start using a low-code development platform. For comparison, in the 2018 report, 34% of respondents said they were using low-code development platforms and 9% said they were about to start using these platforms. Clearly, interest in these platforms is rising, if not modestly.

Low-code development platforms strive to make software development more accessible. They do so by removing traditional coding interfaces with graphical user interfaces. And they typically target development toward a specific functionality, whether that be web applications, business process automation, IoT and, quite often, databases. The low-code development platform market is expected to grow to $27.2 billion by 2022 from $4.3 billion in 2017, an annual growth rate of 44%.

The demand for software has never been higher. According to the OutSystems report, 64% of IT professionals said they have an application development backlog. For 19% of respondents, that backlog is deeper than 10 apps. While 50% said their backlogs have remained the same, 39% report that their app backlogs have improved over the past year.

The time to deliver web apps and mobile apps is mixed. The 2018 OutSystems report found that 54% of respondents took four months or less to deliver a web application. This year, 61% said it takes them four months or less to deliver a web application. Mobile app development has changed a little: 55% on average said they deliver apps in four months or less.

According to OutSystems, enterprises using low-code development platforms are 12% more likely to report that their backlogs have improved year over year.

Those findings echo similar surveys. For instance, a survey released earlier this month from low-code provider Appian found that nearly 80% of its respondents believe that using low-code can free developer time to work on higher-level projects. That survey also found 86% of IT developers agree that emerging technology is increasing the pressure on the IT organization.

One thing is certain, the demand for software isn’t going to let up anytime soon. According to the OutSystems report, the number of applications respondents plan to deliver this year is 60% higher than last year. For those with more than 500 employees, 65% said they had plans to deliver 10 or more apps, 38% plan to build 25 or more apps and 15% said they plan to develop 100 or more apps this year.

Despite the high demand for enterprise software, only 36% of organizations have larger development teams than they did a year ago. However, that’s likely not due for lack of trying to hire and retain development talent. The OutSystems survey found only 15% of respondents described developer recruitment as easy. “For many organizations, retention of developer talent appears to be an equally grave challenge,” according to the report.

With conditions like that, it’s only reasonable to expect low-code development platform popularity to continue to rise.

— George V. Hulme

May 16, 2019
The Terrain of DevOps is Strewn with Pitfalls

As Gene Kim, one of the leading thinkers in DevOps, once said, “DevOps is not about what you do, but what your outcomes are.” What he’s telling us is that DevOps is about enabling a rapid flow of work that transitions from development to testing to operations, but the bottom line is that it’s about achieving results. Unfortunately, this too often gets lost in modern-day DevOps practices.

In this article, I will discuss five common pitfalls that occur in DevOps if you don’t pay attention to the endgame and how your organization can avoid falling victim to them.

DevOps and Automation: Measuring the Wrong Outcomes

Some people believe that, at its core, DevOps is about trying to automate everything. But ask yourself this: Once you automate, are you really delivering a better outcome?

The answer is not always yes. While metrics such as deployment frequency or mean time to repair (MTTR) are interesting DevOps indicators, they are no more interesting to determining if your team is delivering actual value than measuring the number of lines of code submitted or counting the number of keystrokes by the development team. You measure outcomes by determining a baseline from where you start and compare that with where you end.

We need to understand that DevOps is about much more than automation; it’s about the entire pipeline and how your team moves from ideation to delivery to production. Even large companies with world-class DevOps teams don’t always clearly see the problem and can struggle managing the value stream and putting together multiple pipelines. An anonymous but real-life example of this is an organization I know that had been doing DevOps for 18 months, yet hadn’t delivered anything into production in that span. Are they really doing DevOps? DevOps is a process, but if it produces zero value, it’s not delivering on its promise.

The key is focusing on delivering value and measuring value delivery into production. However, before you can begin measuring value, you have to define what it means to each individual deliverable. Common metrics include the number of story points, actual revenue from product comparison and customer satisfaction. With your clearly defined metrics in place, you can measure value as it gets delivered to the customer.

DevOps and Fragile Environments

One Achilles’ heel in the DevOps process is the pre-production environments where code gets deployed and tested. Automating a delivery pipeline relies completely on code being built and deployed to various environments. Fragile environments mean that the developers and testers are wasting time dealing with problems originating from the environment and not the code itself.

While we wish all environments could be on-demand; the fact is, most are not. Another DevOps expert, Randy Bias, has an analogy about pets versus cattle in describing servers, and the same analogy can be used for environments. If environments are not standardized and repeatable, you have to be willing to move on from it like a farmer moves on from livestock; you can’t hold onto sentimental attachments like we have with our pets. What’s most important is that in no case can an environment be singular in nature.

One element of the solution is to create code and automate, but the key is building up environments that are complete. Every environment needs proper builds, proper data and proper tests validating the environment. Additionally, the automation must have the stability to perform successfully every time. If you have piece of automation that fails even just 5% of the time, that’s unacceptable.

The only way automation works in an environment is if you can trust the environment. When the environment is unstable, it’s like playing Russian roulette: No one knows exactly where the danger lies. It could be in the environment, the code, the data, the middleware … a number of places. When a problem arises, developers are often the last line of defense, but dealing with an issue such as this pulls them away from getting real work done.

Disconnected Teams

On this point, I’d like to share a warning: Disconnected toolchains lead to disconnected teams. The planning, development and testing teams can lack cohesion, and the release and operations teams often struggle to be on the same page. Each of these groups have their own tools and management, but they need to be able to communicate with each other effectively to make things work smoothly. In an ideal world, planning initiatives would flow into features for the development and testing team, which would flow into release pipelines and operational changes. Every team still can speak its own language, but the tools need to be interconnected and unified across the teams.

Mismanaging Hybrid

The term “hybrid” has many different uses in the software development space. Hybrid methodology refers to combining waterfall, agile and DevOps practices. Hybrid environments means your environment is housed in multiple locations such as the cloud, on-premises, virtual or code. There’s also hybrid geography, hybrid architecture, hybrid style—the list goes on.

The key to transitioning to DevOps is properly managing the different types of hybrid. If you can’t manage hybrid delivery, you can’t manage your entire delivery and you can’t improve your delivery holistically. Organizations must learn to manage in a world of hybrid delivery and be able to handle cloud and on-prem, as well as teams all over the planet.

Fixing Non-Constraints

The Theory of Constraints is about pinpointing the bottlenecks in your process and fixing them. Any work that’s not focused on eliminating the constraint will not result in improvement and could be considered a waste of time.

It’s important to remember that if you haven’t fixed the bottleneck, you haven’t improved anything. At the same time, if you’re automating the non-constraints, you’re wasting efforts by trying to improve what doesn’t need improving.

As we’ve pointed out, DevOps does not equal automation. If an organization has messy processes and tries to automate them, they’ll be left with an automated mess. Therefore, organizations will see the best results from automating their constraints and just as important, not automating the non-constraints.

— Jeffrey Keyes

May 13, 2019
Promoting Purpose in Agile Environments

Agile environments increasingly are becoming a popular option for organizations large and small. Although initially created as a solution for small software development teams with short budgets and complex scopes, it’s been adopted (and refashioned) for all industries and team sizes.

Agile Methodologies: Why They Work

The agile approach seems obvious to us now, but back in 2001 when the idea was incepted, it was a revolutionary one: Give employees the room they need to get the job done and let them do it. Throw out extensive documentation and overbearing technical documents for constantly moving, constantly changing, constantly reassessing and growing workplaces.

“In 2001, a group of experienced software developers got together and realized that they were collectively practicing software development differently from the classical waterfall methodology,” wrote Isaac Sacolick for InfoWorld’s “What is Agile Methodologies?”

“This group came up with the Agile Manifesto that documented their shared beliefs in how a modern software development process should operate,” he continued. “They stressed collaboration over documentation, self-organization rather than rigid management practices and the ability to manage to constant change rather than lock yourself to a rigid waterfall development process. From those principles was born the agile methodology for software development.”

How the Framework Works: Higher Purpose

An agile approach pursues the production of top-tier software. Without an agile framework (or something like it), there is often a distinct lack of purpose-driven principles. From an agile framework, companies can create strong cultures.

Why is higher purpose so important? After the great recession hit in 2008, we were left with some very important questions amid a financial disaster, the likes of which hadn’t been seen in 80 years. When the economic foundations of our world were rattled, many firms were forced to answer what their higher purpose really was.

Without the promise of a steady paycheck or a fat margin, there is all too often an absence of purpose. Even when the economy is performing in a spectacular manner, a lack of higher meaning pervades many mediocre organizations.

“Although a higher purpose does not guarantee economic benefits, we have seen impressive results in many organizations,” reported Harvard Business Review writer Robert E. Quinn and Anjan V. Thakor. “And other research—particularly the Gartenberg study, which included 500,000 people across 429 firms and involved 917 firm-year observations from 2006 to 2011—suggests a positive impact on both operating financial performance (return on assets) and forward-looking measures of performance (Tobin’s Q and stock returns) when the purpose is communicated with clarity. So, the purpose is not just a lofty ideal; it has practical implications for your company’s financial health and competitiveness.”

How to Create Purpose With Agile Principles

Joe Robles, the former CEO of USAA, found this utter lack of meaning to be of immense concern for every level of his organization. Concerned about his employees, he visited them to discern where the company culture could improve. He was surprised to find that his call center employees were happy to collaborate on every level.

It became his mission to imbue this type of mission-driven attitude to every employee and everyone in leadership, through major cultural education. How can other organizations emulate USAA’s successful purpose-driven culture? There are a few steps to achieving this goal.

The first step is to imagine the workforce you wish to have. In agile environments, there is a focus on efficiency. There is no unnecessary research, documentation or meetings; there are only results. Successful outcomes, however, only come from motivated, purpose-driven individuals. That means we must ascend above the employer-employee relationship and, instead, swap it with an inspiring mentorship program.

The next step is to make this dream a reality. Craft an authentic message, promote that message, then promote the supplementation of that message with continual learning, training and dialogue.

Conclusion

Agile environments foster meaning and cooperation. Instead of employees that mindlessly listen to the autocratic directives of their superiors, they are part of a task force who shoulder the responsibility of reaching a higher goal together. This means some critical and divergent thinking must be fostered, which can be frightening to traditionalists of all forms.

In agile environments, you will need to start asking questions that help expand how the team thinks and operates. In addition, listening, analysis and reflection skills must be a primary focus for a higher meaning to be divined.

— Anthony Coggine

May 10, 2019