devopsy.kinsta.cloud

Tag: teams

Why Startups are Betting Big on Low-Code/No-Code

It is exhaustive — from infrastructure to app delivery, from data to applications — to modernize your practices, processes and providers to ensure you have the underlying foundation to take advantage of whatever comes next.

Two or three years ago, apps created through low-code/no-code platforms were not usually as detailed under the surface as software developed from scratch, yet they sufficed for certain purposes. There was even a clear distinction between software developers and everyone else out of necessity because software development was incredibly difficult to master.

But now, as we head towards more advanced AI, the SaaS-based low-code/no-code (LCNC) platforms empower businesses to create software exponentially faster and cheaper than a code-based approach.

The future, therefore, of startups in this changing business landscape becomes even more competitive, taking into account the increasing importance of customer-centric UI modeling, data product development and cutting-edge technologies like machine learning and deep learning.

High-Value Acceleration

Applications built through traditional software development can take months or even years to launch. If you create a code-based solution, it’s also easy to blame others and there’s a lack of understanding if it’s not well-documented. “Low-code no-code functionalities can change this dynamic,” says Dr. Ingo Mierswa, an industry-veteran computer scientist and founder of Altair RapidMiner. “The visual workflow describes what it’s doing, so people can understand it, buy into it and take ownership of the results.”

Visual workflows can be understood and created by more people. “They make it easier to maintain and explain why anything, such as a model’s decision or a bug, has happened because the workflows are documenting themselves,” Mierswa articulates. “It would be hard to create such an explanation if you had to sift through 100,000 lines of code, especially if the code had been changed 17 times in the past two weeks.”

You need to iterate, you will make mistakes, and you don’t want to waste time with coding non-critical things. “My big advice for all starters is to always think about what’s critical for your product. What’s your IP? What do you need to own and customize? And if coding is not that important for your product, I think going low-code/no-code is always the better way,” Mierswa shares. “It’s more important for startups because you have less resources, less time, more competitive pressure and markets are moving very quickly.”

Everyone is a Citizen Developer

In the early 1960s and 1970s, there was a clear distinction between software developers and everyone else out of necessity. Software development was incredibly difficult and time-consuming to learn and master. But now with the onset of low-code/no-code solutions, everyone from custodial teams to C-level executives can create and customize applications that make their jobs more efficient.

Because no-code/low-code platforms are built on the fundamental premise. “People closer to the problem are better equipped to find simpler and effective solutions,” says Kissflow CEO Suresh Sambandam. “It’s a team sport, and accountability, the most important benefit of LCNC solutions, accelerates development and empowers even more people to collaborate the right way.”A big advantage,” Sambandam says, “is that CIOs of large enterprises can solve the IT talent shortage plaguing the industry today by leveraging expert business users who are ‘citizen developers.’ Many companies can’t avoid struggling to recruit and retain tech talent in a highly competitive market, but low-code/no-code solutions exceedingly help bridge that talent gap by freeing up the bandwidth of existing resources.”

At the highest level, you always need people who understand the business problems that need to be solved. LCNC functionalities also empower adjacent team members — designers, product managers, data scientists and others — to take part in the different stages of development as the product takes shape.

Reducing Technical Debt to Overcome Friction

In an enterprise scenario, most of the core systems like ERP, CRM, SCM in the front end, as well as in the back end, are bought from standard vendors. There is NO differentiation, as all the top enterprises buy from the same vendor. On the other hand, the bulk of differentiation comes from middle-office processes that are unique to an enterprise. Sambandam points out, “Often these are business processes that require heavy domain knowledge that frequently change to adapt to the evolving business conditions and hence business users are better equipped to build these workflow automations.” He highlights that conventional software development models don’t do justice to the agility required by business users and are too complex for them to use. While business users have the domain knowledge, the system would also require integration touch points with other enterprise systems. These integrations often require deeper technical expertise.

It is essential to create a cultural change within your organization, where it is not just about having the right tools, but also about investing in your employees and skilling them up, commented DevRev Head of Engineering Ahmed Bashir.
It still is hard work, and there will be friction. “Overcoming friction requires creating a tighter loop across departments and managers, closing the gap between developers and customers,” he underscores. “And LCNC platforms are designed to act as a system of action, surfacing real-time information that connects work with developers, customers and product.”

This is exactly where platforms like Kissflow, Blaze and Bubble, which support both no-code and low-code use cases come in and let business users handle the domain portion of the application (90%) and IT teams configure the integration points (10%). This greatly reduces friction between IT and business users, especially when it comes to solutions for long-tail internal workflows.

Long-tail applications include things like approval management, creative requests, incident management, customer onboarding and IT helpdesk. “We looked at the space and decided to tackle this,” Sambandam shares.

Long-tail apps and processes are often viewed by IT as a drain on time/resources they don’t have, yet it’s a lack of internal workflow processes automation that gum up digital transformation. “We found as we scaled the company that when you empower business users to quickly build and augment workflows that directly impact their day-to-day by giving them the tools to do so without advanced technical knowledge, they are motivated to make it happen,” he affirmed.

Security is a Business Enabler

The main objective of security is to protect organizations and people. Organizations prepare for potential security threats by implementing policies and ensuring they have the tools to mitigate and quickly respond to outside threats.

However many low-code/no-code adopters do not have security expertise on their team so they rely on the LCNC platform to offer security features readily available for the apps they build. Because creating applications with custom code can lead to a variety of security issues. And such applications are difficult to secure, with the majority of tested applications containing one or more session management vulnerabilities, and others with input validation errors.

Getting a firm handle on security means considering what to do. That sounds simple enough, but it’s surprising how many startups make blunders because of poor planning and shoddy strategies. “We’ve been looking at a trend. Companies want enterprise-level security like audit logs, SSO and other data security requirements for their apps,” commented Nanxi Liu, Co-CEO of Blaze. “Seeing this strong trend, we worked to design our platform with enterprise security and scalability in mind, since most early-stage companies do not have security expertise on their team and rely on platforms to offer advanced security features for the applications they build.”

Make, however, no mistake — there is no best security but the best practices. “That’s part of why,” Liu says, “compliance-driven businesses like financial services and healthcare companies that require the highest level of security to build their customer portals, consider enterprise-grade no-code and low-code platforms that provide the required level of security.”

With low-code/no-code platforms, your applications are secure with industry-standard protocols, data protection practices, and features to block unauthorized access.

To underscore: LCNC allows non-technical people to build complex apps without needing to be familiar with traditional software logic. You don’t need computational thinking because visual components in low-code/no-code platforms automatically have the logic built-in. “And now with the mind-bending AI breakthroughs,” Liu remarks, “users can tell AI in natural language the workflow or feature they need and see it instantly created.”

February 2, 2024
Microsoft’s 9th Outage in 2023 ¦ RISE of RISC-V ¦ Meta Ends WFH

Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

This week: Redmond SaaS keeps failing, RISC-V is RISEing, and Meta is enforcing hybrid work. (more…)

June 7, 2023
Why Monitoring-as-Code Will be a Must for DevOps Teams

Over the last decade, we’ve seen an increasing number of operations teams and development teams using an infrastructure-as-code (IaC) process for provisioning cloud-based infrastructure. In that model, IaC tools like CDK, Pulumi or Terraform are employed to allow developers to code, deploy and manage cloud-based infrastructure. The advent of cloud services and IaC tools has freed engineering teams from error-prone (and slow) manual infrastructure provisioning processes. The ability to codify your infrastructure next to your version-controlled application code has been a game-changer for many organizations.

An Introduction to Monitoring-as-Code

With IaC becoming an increasingly valuable tool for managing infrastructure, it’s only natural that other parts of the ecosystem follow that shift left philosophy, including how testing and monitoring are done.

Similar to IaC, the monitoring-as-code (MaC) concept allows us to describe a monitoring infrastructure as code. Today, many DevOps teams are employing MaC by using some of the aforementioned IaC tools like Terraform or Pulumi—in conjunction with monitoring platforms like Checkly—to create, run and manage their browser and API monitoring regimens. In these examples, monitoring checks can be defined in JavaScript, TypeScript or HCL, and then those can be committed together with application code. Modern MaC matures fast; it does not even require traditional IaC tools but enables MaC without extra tools. Modern platforms enable this by shipping CLIs to achieve this. Making monitoring an integral and companion part of your codebase comes with many benefits and advantages.

Just as IaC has become an integral part of the new paradigm for managing cloud-based infrastructure, here are a few reasons why I believe MaC will also become a must for modern DevOps teams.

The Benefits That Make MaC a Must for DevOps Teams

Flexibility and Programmability
By adopting MaC, your automated testing infrastructure is defined as code and lives next to your application code in your code repository, giving you all the benefits that entails. Testing and monitoring are no longer treated as separate from your application code.

Update Monitoring With Your Code Changes
As mentioned in the previous bullet, MaC places your testing and monitoring next to your application code. So when your application code is updated, your testing and monitoring ships right alongside it, streamlining the process. That makes your testing and monitoring solutions deployable, with MaC giving you the ability to schedule tests on a continuous, around-the-clock basis from distributed locations across the globe.

Monitor and Test on Staging
In the past, synthetic monitoring was primarily meant to run on production: Once your apps were deployed, monitoring kicked in and alerted you when things failed. With MaC, that monitoring can now run locally alongside your application code in a CI/CD flow, allowing that app code to be tested and even monitored continuously on staging before getting deployed on production.

Speed and Automation Efficiency
With monitoring now embracing the “as code” paradigm, new checks can be spun up quickly and in far less time than a non-MaC monitoring approach. All of that increased speed and efficiency will have a real-world impact on dev, ops and QA teams, saving engineers hours now automating once-siloed manual and inflexible work.

Scale as Needed
Finally, given that your tests live right next to your application code, it’s much easier to observe, manage and understand what is being monitored. That insight and visibility also make it much easier to scale your testing and monitoring efforts across teams, organizations and even across the globe. All of that enhanced efficiency frees dev and QA teams to focus on other tasks while simultaneously providing better testing and monitoring support across the organization.

MaC Benefits in Action
As an example, all of the aforementioned benefits are being employed by a large health care provider that recently adopted a MaC workflow. That organization relies on a MaC testing and monitoring workflow—based on tests written in Playwright—to automate its synthetic monitoring efforts. In particular, a MaC approach has enabled the QA and dev teams there to quickly build, validate and deploy an entire suite of checks from their local development environment.

The Future of Testing and Monitoring

With MaC now moving in the same leftward direction as IaC, I believe that the future of monitoring will become increasingly accessible, flexible and frictionless for any modern developer. MaC will also be increasingly based on open source testing and automation frameworks like Playwright, Puppeteer and others, which have been used and adopted for automation and testing for years.

April 11, 2023
Survey: More Cybersecurity Pros Embedded in DevOps Teams

A survey of 2,500 C-level executives published today by Palo Alto Networks found 81% of organizations have embedded cybersecurity professionals within their DevOps teams.

Despite the presence of those cybersecurity professionals, however, the survey also suggested there is much work to do in terms of optimizing DevSecOps workflows. A full 90% of organizations cannot detect, contain and resolve cybersecurity threats within an hour, the survey found.

Bob West, chief security officer for Palo Alto Networks, said most of the challenges associated with DevSecOps are directly related to persistent cloud security issues. More than three-quarters of organizations (78%) said they had distributed responsibility for cloud security, but almost half (47%) said a majority of their workforce still does not understand their security responsibilities.

In many cases, developers with little to no cybersecurity expertise are responsible for provisioning cloud infrastructure. As a result, misconfigurations that create security issues are commonplace, noted West. That’s especially problematic because three-quarters of organizations (75%) are deploying new or updated code to production weekly, with almost 40% committing new code daily, the survey found. Given that developers far outnumber cybersecurity professionals in most organizations, it remains challenging to ensure application code is secure, noted West.

In addition to improving the overall state of cloud security, organizations need to focus on fundamentals such as training developers to be more mindful of cybersecurity issues, he added. Most developers never had any formal cybersecurity training, so it’s up to organizations to make sure that particular skills gap is closed, he noted. In addition, organizations need to make sure they have a robust set of patch management processes in place alongside a capability to manage permissions and entitlements, added West.

Overall, the survey found organizations are using more than 30 security tools, on average, including six to 10 dedicated to cloud security. More than three-quarters of respondents (76%) said relying on multiple security tools created blind spots that affected their ability to prioritize risk and prevent threats. A full 80% said they would benefit from a centralized security solution that sits across all of their cloud accounts and services.

One way or another, a rising tide of regulations focused on improving the security of software supply chains will force organizations to improve cloud security, said West. The survey showed there is a strong commitment in terms of making cybersecurity professionals an integral part of a DevOps workflow. The issue is that there are still a raft of training and process issues that need to be addressed at a time when cybercriminals are becoming increasingly adept at compromising applications both as they are developed and after they are deployed.

Of course, training and modifying processes take time. DevSecOps is as much about changing culture as it is about acquiring new tools. DevOps teams are still highly committed to building and deploying applications as quickly as possible. The challenge is finding a way to insert a set of cybersecurity gates within those workflows without slowing down the pace at which applications are developed.

March 7, 2023
Solving the Culture Conundrum in Software Engineering

The one crucial ingredient underpinning our transition to a digital-first economy, more than any other, is software. That’s why software engineering has become one of the world’s most in-demand professions. In the UK alone, the median salary for the role has increased 13% year-over-year as businesses look to stay ahead of the competition and attract the very best IT talent. But the high salary often isn’t consistent with where software developers stand in the business; many organizations still view them as suppliers rather than as crucial players in their success. Based on the current speed of transformation, we know that demand for software engineering is only going to increase. So business and technology leaders need to urgently consider vital cultural changes to help better integrate software development teams within the wider organization. But what exactly should they be?

The Development Dilemma

Agility has quickly emerged as a competitive advantage as businesses strive to deliver on customer expectations quickly and effectively. That’s heralded the rise of DevOps, which aims to write high-quality digital solutions more efficiently and have the ability to continuously update in a secure and low-risk way.

The practice is already accelerating feedback loops in the software development of digital solutions on a wide scale, meaning new software is brought into production as fast as possible and with reduced risk. As a result, today’s successful businesses are now releasing software updates multiple times a day. The figure even runs well into the tens of thousands for tech giants like Amazon and Netflix. However, other businesses are struggling to keep up with the speed the market demands, largely due to a lack of clear communication, ways of working and integration between software developers and the wider business. It’s a dilemma that needs immediate attention if businesses are to remain at the competitive edge.

Developers are too often left to deal with huge monolithic pieces of work, which require them to write code for months on end without it being road-tested. This inevitably leads to mistakes that are found only once the updates have already been released to market creating a ripple effect throughout the organization. It’s an all-too-common scenario that demonstrates business leaders’ clear lack of clarity and understanding about the colossal value adopting a DevOps culture can deliver for the wider business, including its customers.

Take financial institutions looking to introduce a new offering, for example, such as a new mortgage product. Without a collective approach to development, getting the backend systems up and running for a product can take up to six months. But modularising the options and breaking down the functionality can shorten timelines to weeks.

Business leaders must look to create unified, cohesive and cross-functional teams that work together on projects that are broken down into simplified and localized components that can be easily integrated together without a negative impact on each other. It might seem like a small strategic change in working practices, but its impact on the speed and efficacy of software development can be enormous.

Revisiting Personalities and Processes

The role of the software engineer has changed; it is no longer about writing code in isolation without much regard for or knowledge of how it benefits the business. Developers work better when they have clarity about the direct impact their work will have on achieving business goals and on the bottom line. It’s down to business leaders to communicate these challenges and goals (in other words, understand the “why”) to help software developers understand what they’re trying to achieve. But doing so in a way that moves towards a better working culture requires a new approach to building and managing software development teams.

The first step is casting aside the negative stereotypes many have of software engineers and celebrating the intellectual and cultural diversity within their teams. Diversity of personnel brings a diversity of personalities, which is crucial to creating more inclusive cultures that accept and welcome all characters with open arms. While this may seem obvious, what is often overlooked is the impact diversity can have on stimulating and increasing innovation.

Improving the diversity of development teams helps unlock multiple ways of responding to and analyzing the challenges brought forward by business leaders. After all, each individual has an array of different soft and hard skills based on their learning, development and experience. So, encouraging individuals to bring their characters and personalities to their roles is crucial; it ensures each and every stakeholder in the development process is empowered to contribute, feels inherently valued, and is able to challenge existing assumptions, helping deliver a more robust end product.

Recognizing and harnessing this spectrum of skills also helps bridge many of the barriers to development that exist within businesses. Some software engineers, for example, might struggle to communicate technical updates in a way the wider business can understand, but tapping into another individual’s strong communication skills can help unite teams–and entire businesses-around one, holistic digital strategy.

Channeling Change to Deliver Better Outcomes

Clearly, cultural change is needed to embed software engineering at the core of modern business. But revisiting project management practices is also imperative to continually deliver software that provides value to the business, the world of scientific management and Waterfall delivery methods is no longer appropriate for the development of digital solutions. With such a heavy reliance on digital services, businesses—and, consequently, developers—need to be able to make changes with minimal effect. So, eschewing monolithic projects and encouraging cross-functional teams is essential. Not only does it reduce the need for sweeping software updates, but it negates the risk of a project failing to meet the initial brief, which could ultimately impact the entire business.

By reviewing organizational processes, and bringing the wider business and software developers together, we can create teams that deliver digital solutions effectively and quickly, so that every user, whether internal or external, reaps the benefits of a more sophisticated approach to software engineering.

November 3, 2022
4 Ways to Scale DevOps in 2021

January is a month often dedicated to planning, setting intentions and preparing ourselves professionally and personally for a fresh year. In my own capacity as a DevOps and SRE leader, many of the clients I work with will reinvigorate internal efforts to streamline how they work in Q1.

I often advise clients to make very concrete goals and milestones for their technology organizations to become more agile, streamlined and modernized. Setting these goals is helpful to articulate to the wider business where you want to go and how you plan to get there. Here are a few DevOps-related initiatives your team may want to tackle in the first half of this year.

#1: Tighten Security through DevOps

Securing your organization’s infrastructure is an evergreen priority for technology leaders. When done properly, security should be baked into all DevOps processes (sometimes called DevSecOps) from the design phase all the way to application maintenance. To be effective and not slow down development, security processes need to move at the speed of today’s fast-moving environments, which is near impossible, or, at least very challenging, unless security is well automated.

Automated security measures can be applied to the full life cycle of product development and should make development time faster and smoother in the long run if you can catch vulnerabilities early. Identify automation tools that work for your team and experiment with what works best.

Similarly, in fast-moving environments, it’s tempting to play fast and loose with privileged access to unblock individuals and teams. Lax policies for user rights exposes the organization to too much risk from potential hackers. Implement a solution or protocol to keep access controlled. Policy and governance are critical for well-rounded DevSecOps. Communicate policies regularly with the entire organization. Ensure that all engineers know how to comply and enforce them.

#2: Make DevOps an Organizational Culture

Much like security, DevOps needs to evolve from an individual role to a cross-functional, holistic, cultural approach to developing software. Organizations should foster a DevOps culture rather than identifying specific individuals in DevOps roles.

So how do you know when this culture shift has happened? A good pulse check is to see how quickly your company can adapt to change. How mired is your team in legacy code or infrastructure? Can individual teams operate autonomously? Teams and individuals that are independent and accountable are able to continuously experiment and learn at a much faster rate.

DevOps cultural transformation won’t happen overnight – but it can be expedited if embraced by the entire company. I typically advise companies to focus on making incremental, consistent progress that builds autonomy, trust and transparency. These are the building blocks of a thriving DevOps culture.

#3: Simplify Your Infrastructure

Complexity, over time, creates duplication, unnecessary systems and technical debt. All of these have a cost, and create security vulnerabilities. Create organizational goals to clean up and reduce complexity. I often suggest teams create a roadmap to move toward self-service and building platforms. As you focus on building a DevOps organizational culture, you will likely notice that teams will identify opportunities to simplify and standardize, which will also remove complexity.

#4 Review system SLAs and SLOs

Establishing and monitoring key metrics are a fundamental part of any SRE role. Service level agreements (SLAs) and service level objectives (SLOs) need to be defined and monitored to ensure your team is fulfilling them. System availability (uptime, latency, etc) is core to any cloud SRE team. Define what reliability means for your organization. January is a good time of year to start fresh and articulate these metrics, how they relate to your core business and what investments or changes need to be made to achieve them.

January 19, 2021
Speed and Security: How to Find a Balance in Development
Time management can help developers realize the necessary combination of security and speed in application development

As software continues to create competitive advantages and market differentiation for organizations focused on successful digital transformation, developers will continue to be measured by how fast they can develop and release code. Business leaders encourage DevOps teams to push the pace of innovation to deliver features quickly while leveraging the newest technologies to gain any available advantage in the market. As a result, development and operations teams work at breakneck speeds to meet the deadlines of short and frequent development life cycles.

Security teams, however, are not measured by speed but rather by certain metrics of success, such as whether they achieve a certain security rating or reduce the number of incidents. Traditionally, security sets corporate standards and best practices centrally and tries to enforce them across the enterprise. With DevOps teams becoming increasingly distributed and decentralized, these conventional security methods no longer work and have actually slowed down security and/or blocked the software development process. Security tries to keep pace, but with numerous disparate reports to review and too many results to manage, they inevitably fall behind. In the rush to catch up, either critical vulnerabilities are overlooked or frustration sets in when releases are delayed.

Developer and security teams both know the importance of delivering secure software but struggle to find the right balance. Let’s take a look at some strategies that can help ease the tension between DevOps and security teams and create a happier work environment, where safer code is delivered to the market.

Incorporating Time Management for Speed and Security

Consider implementing the following time management strategies to make life easier for developers:

Integrate AppSec in the DevOps Pipeline: Application security scanning should be incorporated early and often within the DevOps pipeline. While this statement may sound like a broken record, the days of running scanning tools independent of your pipelines are gone. Studies have shown the earlier you detect an issue, the easier it is for developers to fix—with as much as 50% time reclaimed over late-stage remediation. By including AppSec in the pipeline, you ensure all issues are identified as quickly as possible. This effort will not only improve the quality of your software but also free up more time overall for developers to write code and create cool features. Sounds like a win-win for both teams.

Incorporate automation as much as possible: DevOps teams should look to leverage automation when implementing application security wherever possible. Many of the steps for securing your software development process are repetitive. For AppSec to be successful, the steps must work within the developer’s world and along with the other tools developers love. Developers look for tools that help them move faster.

Here are some areas where application security automation can unburden developers from repetitive tasks:
- Use AppSec tools that can be easily tied into your DevOps toolchains. As a matter of fact, a developer may not even need to know what security tools are being run, only that they are executed on every run of the pipeline.
- Automate the ingestion and correlation of the security findings. There will often be a boatload of redundancies between the findings from different security tools (i.e. SAST versus DAST versus SCA) and the potential compression ratios can be in the order of 10-50:1. There are tools to automate this process and dramatically simplify making sense of all the data. The onus shouldn’t be on the developer.
- Once a security issue has been identified, it should automatically create a ticket in the ticketing system that developers use today. We all know developers don’t like being forced to use a new tool. Give them the findings in the system they are already familiar with.
Tailor security training for your teams: Security training is a great way to reduce the number of security findings within an organization, which in turn frees up developers to work on other pressing issues. However, most security training is ad hoc and not tailored to meet the needs of the development teams. Even the most basic security testing can provide baseline metrics that enable security teams to recommend tailored training for development teams. These sessions can focus on areas that teams struggle with or areas known to be susceptible. Training is also a great way to develop security champions within the development teams, dedicated professionals who have shown to improve the overall security posture and awareness of organizations. Security champions—and the programs they advocate—have the power to improve both AppSec and relationships among people, a sentiment endorsed by 84% of industry professionals.

Summary

Developers know the importance of security and truly want to deliver safe code in the timeframes they are being judged on. By incorporating the strategies outlined above, they will have a fighting chance to reach the lofty goals set by the business, while releasing higher quality and more secure code. Security teams need to meet the developers in their world and help enable application security to be automated and work at the speed of DevOps.
December 11, 2020
The Human Touch: The Key to Optimizing Your Software Value Stream Network
Software has no intrinsic value until it’s working in production and supporting a customer’s business initiatives. With that in mind, it’s imperative that organizations focus on how they reduce the time to value, not just time to deploy. And that’s achieved through people.

A common misconception is that technology underpins a software delivery value stream. This is only half true. Tools add immense value and help people to be more productive—whether through advanced functionality (such as the ability to visualize and manage workflow) or by automating repetitive activities (such as test cases and releasing code). All of this boosts throughput. But it’s actually the human touch that drives a product.

It’s all about how practitioners work together to understand and address a discerning customer’s needs with software. To that end, organizations must ask themselves, “How do we optimize practitioner collaboration?”

It’s All in the Artifacts

Collaboration optimization lies in how organizations handle product-critical information—artifacts such as features, epics, stories and defects—that are created for the very purpose of sharing with collaborators.

Therefore, the follow-up question that organizations should ask is, “What system do we have in place to ensure these artifacts are flowing in real-time, so the information is always up to date, ensuring that all work is always accurate and adding value?”

Fortune 100 companies have already asked these questions, making a number of significant discoveries:
1. The software value stream is actually a social network of collaborators who are connected by artifacts—hence, “value stream network.”
2. This network consists of two different, but equally important, phases: “plan and design” and “build and deploy.”
3. The network by default is not explicitly connected because the tools collaborators use do not naturally integrate with each other and automatically flow artifacts between them.
4. This disconnect forces collaborators to waste precious time chasing up information via manual means such as email, status meetings, spreadsheets, tool-switching and duplicate entry.
5. This manual communication is non-value work that costs organizations up to $10 million in productivity overhead (based on a typical 1,500-person IT department).
6. Such archaic knowledge-sharing practices significantly compromises the fidelity of data as it goes from one practitioner to the next.
7. The “plan and design” phase—the part of the software delivery process that determines what product/feature is to be built/fixed—is detached from the “build and deploy” phase.
Through these discoveries, the last one in particular, organizations came to an important realization: They have no real way of knowing if they’re building the right product because there are six degrees of separation between the people who design the product, and those who build and deploy it.

The result? Disgruntled customers and a big loss of competitive advantage. To address this, they’ve created a new infrastructure that provides a framework to connect and support both phases.

By fusing the value of people and technology into a defined value stream network that is visible and traceable, they have a seamless flow of work that they can see, measure and control. They’re now in a position to identify where value is created and lost, enabling them to make informed business decisions to make better products.

The Software Value Stream Network

The enterprise software delivery process has long been misunderstood as a traditional manufacturing system that is linear and sequential—thanks in part to the industry’s failed adoption of the Waterfall model. The negative influence and impact of that experiment still lingers today.

The process is linear in the sense that there are two clear bookends: A product/feature/fix is requested (A) and then that product/feature/fix is made (B). There are also established phases across the production line: conception, initiation, analysis, design, construction, testing, deployment and maintenance. But that’s where any real similarities end.

In reality, the process is more of a latent network of critical interactions between collaborators. These bilateral working relationships exist at key stages of the software delivery process, such as developer and tester, developer and operations, etc.

When you actually lift up the floorboards of the process and peak inside, it looks more like a social network connected by the flow of artifacts, which looks something like this:

Most of these relationships have developed over time as organizations have introduced a higher degree of specialty in key stages across the value stream. This evolution has been vital in helping organizations to:
- More deeply understand customer requests/issues
- Clearly articulate the requirements/defects
- Enhance product management/optimization
- Acutely break down requirements into epics and stories
- Write more accurate code faster
- Automate and accelerate higher levels of testing
- Continuously deploy
- Introduce tighter feedback loops
- Continuously improve and innovate
While all these new roles, disciplines, purpose-built tools, processes and methodologies have helped different practitioners to perform better, it’s also introduced huge technical complexities. How do you flow those all-important artifacts if the tools are disconnected by design, and when collaborators are working in silos, trapped in “administrivia” hell? It’s tantamount to having a sports car with no gas and a confused driver. Or an airplane flight network with no air traffic control. It’s a banana republic.

Building the Right Product via Value Stream Integration

Agile and DevOps illustrate just how vital integration and automation is to this flow of work. Agile brought in prioritization, feedback loops and sprints to build the most important features as fast and accurately as possible.

DevOps, meanwhile, has accelerated speed of deployment. In that sense, the build and deploy phase is optimized. Automation has work flowing seamlessly between Dev and Ops teams, and eliminated/mitigated cross-team issues, such as miscommunication regarding what products need to be deployed, and when.

But what’s the point of faster delivery if it’s not what the customer wants?

We need to consider how wrong features are developed. If you turn to look upstream, you realize that the teams planning and designing products are affected by the same misalignment that used to plague DevOps teams.

The disconnections between collaborators and their tools in the creative software design process mean that often what’s implemented isn’t right or is delivered too late. In either case, it doesn’t add value.

But that can be radically changed through sophisticated toolchain automation, which shares artifact data across tools and automates the hand-offs between owners in the “plan and design” stage.

From the sales to product to PMO to business analysts, by bringing these customer-centric, product-focused teams together, you dramatically improve the product articulation process and the speed at which its performed.

You build features closer to the customer’s needs. You contain that precious value. And then through automation you can flow that value downstream to developers to create that value. It is as big a revelation as DevOps.

How is this all done? Enter value stream integration. This process is much more than just connecting two tools, say Jira and HPE QC. It’s about connecting all tools, practitioners, disciplines and processes to define and create a free-flowing network that is automated and scalable. Think of it as the plumbing in a house. If even one pipe isn’t connected, there’s no flow of work (value).

Value stream integration connects the pipes to:
- Automate Information Flow Across Value Stream: It enables the frictionless flow of artifacts, as well as information from events across the value stream. This removes non-value-added work and bottlenecks; increases velocity and capacity; enables automated traceability; and dramatically improves employee satisfaction.
- Enable Value Stream Visibility: When managers want to see metrics and dashboards to understand project status, to optimize the process or to ensure compliance, it has been nearly impossible to get a real-time, holistic view across non-integrated tools. Value stream integration unlocks lifecycle data from these application tool silos by automatically compiling lifecycle activity data into a single database. This data can be used to create consolidated, full-lifecycle reports and dashboards, as well as for traceability reporting.
- Create a Modular, Agile Toolchain: Value stream integration enables organizations to use the products that best support each discipline while getting the benefits of a single, integrated toolchain. This drives more value from each tool and allows organizations to easily add, replace and upgrade them, creating a proactive environment for innovation. It creates that value stream network.
Finally … Manageability

With this network, organizations can finally see, manage and optimize one of the most important processes in their business: the engine that drives their prosperity in a digital-centric world. You cannot underestimate how important it is to have this network, this complete system. This is the state where innovation thrives, and where continuous improvement can be executed. And, of course, where you gain the essential visibility to be confident you’re always building the right product.

— Nicole Bryan
April 20, 2018
5 Ways to Ensure IT Service Desk Agility

The agile approach is everywhere. Born in the software development world, agility means adaptive planning, ongoing development and continuous improvement. Rapid and flexible response to change is critical. It is not surprising that the best practices of agile software development penetrated into other areas, and IT service management (ITSM) is no exception.

The Service Desk Can Be Agile

Unless you’ve been away from ITSM for the last 10 years, you know that an agile IT service desk is flexible, automates processes for quicker incident resolution and emphasizes collaboration between technicians and interactions with users.

But how do you adopt these seemingly tough principles to make your IT service desk truly agile? We’ve put together five simple ways to help you assess your IT service desk and move toward agility.

Keep Interactions in Real Time

IT service desks are constantly nestled in webs of interactions between technicians and users. It’s easy for technicians to get lost in endless emails and delay resolution. To avoid chaos and ensure timely ticket resolution, interactions should stay in real time and communication should be as proactive as possible.

Let’s say the sales department of a company uses a sales application. But the application crashes, and the department’s users are unable to connect to it. So, they raise a ticket, and the IT admin immediately checks the server and realizes it’s down. They then check the code management database (CMDB0, which indicates that the application is also used by the finance department. Before attempting to resolve the incident, the IT admin should send a notification to the sales and finance departments to inform the users of both departments that the application is down and that the IT team is working on resolving the issue. That way, they can prevent duplicate tickets and focus on fixing the issue.

Eliminate Productivity Leaks

Most IT service desks are built on ITIL processes, which means that they are already efficient. But to become agile, you have to track IT service desk performance with key performance indicators (KPIs) such as lost business hours, SLA compliance and cost per ticket—all of which monitor both cost and productivity. While KPIs help you measure productivity leaks, reports help you identify their root cause. For example, your service desk KPIs indicate that there have been a lot of SLA violations. A quick look at your reports shows that a lot of time is spent gathering information rather than on finding solutions. By creating a template for common incidents or service requests, all the information you need is gathered in one place, making it easier for technicians to quickly resolve issues and meet service level agreements (SLAs). Similarly, you can reduce the time spent on routine tasks, such as assigning tickets and tasks to technicians, sending notifications to users and more, by automating these processes.

Encourage Collaboration Among Stakeholders

Every IT service desk has stakeholders across various disciplines and geographies. And IT service desks are often rated on how seamless the flow of information is between stakeholders. Therefore, it’s important to have a service desk that provides visibility and encourages collaboration. Let’s say that a company is running its financial application on a legacy server. To cope with increasing transactions, IT proposes a server upgrade. Since this application impacts everyone in the organization, any disruption in service will impact the business significantly. So, IT should keep all business groups and admins in the loop, ask them for recommendations on scheduling the change, ensure backout plans and inform users about the change schedule and expected downtime. An IT service desk application that provides room for this collaboration ensures a smooth upgrade with minimal interruptions.

Establish Self-Organizing Teams

An IT service desk is incomplete without its team. And since IT is essentially the command center of a company, it’s imperative to establish a self-organizing IT team. This starts with looking at the current team’s structure and creating workflows around it. In most IT service desks, the technicians are grouped based on their skill sets and level of expertise. So, you can easily assign a technician (or group) to a workflow that requires a certain type or level of skill. You can also auto-assign tickets to technicians or groups, assign a change manager to coordinate with different teams, automate escalation rules for complex issues, configure a backup technician when a one is not available and more.

Learn Through Iterative Increments

IT service desks are expected to meet the changing demands of their organizations. This means that they have to make a number of small changes over a period of time. In agile terms, this is called iterative increments. Let’s take, for example, a growing organization that has several employees joining every week. A typical employee onboarding and provisioning process requires the IT team to coordinate with different teams including HR, maintenance and administration. This can take up to 10 hours for each new employee. But, you can simplify this process by dividing the request into smaller tasks and assigning the tasks to corresponding departments. You can also automate this whole process, significantly reducing the time it takes to onboard a new employee.

Just follow these simple steps and you will be on your way to creating an agile IT service desk that delivers quicker resolutions, increases user satisfaction and evolves with rapidly changing technologies.

About the Author / Aparna TA

Aparna TA is a product analyst at ManageEngine, the real-time IT management company and division of Zoho Corp., and works in the ITSM products division for the flagship product ServiceDesk Plus. She keeps an eye on various IT practices and studies their impact on IT service management. In her free time she likes to relax on a couch and read the latest crime novels. Connect with her on LinkedIn and ManageEngine on Twitter.

October 14, 2016
Dismantling Inefficiency: The DevOps Point of View

I recently caught up with Paula Thrasher, application delivery lead at CSC and DevOps pioneer in government circles. In our conversation, we discussed a number of important topics including cross-functional teams, software supply chains, paying down technical debt and her search for passionate people to hire. To succeed in managing large projects, she’s taking a different approach—one you might want to apply in your own organization.

Thrasher: I’m Paula Thrasher with CSRA and I work for a division company we call Delivery Services Organization.

Derek Weeks: What was your presentation at the Rugged DevOps conference about today?

Thrasher: We had a panel about the people, process and cultural aspect of DevOps, and the security context, as well. When you’re moving to the Ops transformations, what kinds of behaviors are both challenges and opportunities.

There was a comment at the beginning session about how any sort of transformation that relies on human nature has failed. So you can’t change how we work, but you can leverage how people are motivated to try and encourage the right behavior. I think that’s the thing that’ll resonate with the security professionals.

Link to Panel: https://www.youtube.com/watch?v=IbrY8mm9aI4&index=7&list=PLotLY1RC8HovW-XnZbItSBupjbTzFkfJw

Weeks: You’re setting up a new organization and have a lot of projects that you’re going to take on. Is it possible to achieve a lot with smaller teams? Do you need a big team to do rugged DevOps?

Thrasher: I think the main thing that we’ve been focused on is creating the team that is sort of the center of the universe. I think the most important thing is to have a team that is cross-functional. A lot of times when you think of teams … this is the development team, this is the Ops team, this is the security team … the question is, do you have all the players on the same team, or are they on different teams? I think if you find yourself in a situation where any one team has to deliver to another team, instead of actually being responsible for delivery of the actual business submission function, you’ve got some horrible web of dependency you’re going to have to untangle.

The big focus of what we’re trying to do in the new organization is build that completely cross-functional team and to enable them as a team to be placed on different projects, different missions. So instead of doing single-band rotations, where a single employee moves onto a new project, we’re actually trying to move full teams. As a team, they learn how they work best and how they can deliver. It makes a really powerful solution for actually solving problems. I’m really excited about that.

Weeks: A lot of people at the Rugged DevOps Conference are interested in the rugged DevOps phase because they’re concerned about being left behind by DevOps. Is that a real concern for security teams: getting left behind?

Thrasher: Yes, we definitely see a dichotomy in the world of how security interacts with development teams—between the traditional showing up at the end and inspecting versus really embedded security. It’s so clearly going to this idea that you can’t just inspect security. Security can’t be this checkbox at the end. You really have to build it in from a computer. You have to actually make design decisions about security. You have to make sure the developers know secure coding practices. You have to have tools that scan, check all the time, and get feedback. You can’t just add that at the end.

I think it’s a real challenge to security folks, just as it was for everyone—developers and Ops people—to change how you think to that systemwide view. You can’t just be a phase at the end. We actually have to be part of a whole equation, that whole systems thinking. I think that is so instrumental to what DevOps really is as a group.

Weeks: One of the things that you recently talked to Mark Miller about was an idea of using pictures to help with collaboration and to get everyone on the same page. Can you tell me about that practice?

Thrasher: Back to this human nature piece, I think humans are inherently really visual thinkers. I also think you’re asking people to bring cross-costuming across social teams. Well, if you’re a security person and you’re talking to an Ops person, you probably don’t speak the same language. Or if you’re a developer and you talk to a security person, again, you don’t necessarily speak the same language. But when you speak visually, you can understand each other better. You don’t bring your acronyms to the table. We’re talking about a diagram.

I also think it takes the personal element out of it a little bit. We’re talking about the system. We’re not talking about each other. The security team is not accusing the developers of being a bunch of renegades. They’re talking to them about a process and how they process it. It keeps the conversation where it needs to be, which is on making the process better and delivering better software.

Weeks: How is the growing interest in software supply chains changing the way you’re thinking about DevOps?

Thrasher: I think simplicity is an underused tool in security. Recently, one of our DevOps teams that was going in their rapid fashion had a deployment that had a vulnerability in it. They had to respond quickly, and they actually did respond quickly. But when we unpacked it, in retrospect, we realized: “How did we get here? How did we let this vulnerability get in?” We had all sorts of scanning. We had, supposedly, all the right things to have prevented that security flaw. Yet, how we got there was this Venn diagram of all these things overlapping. It was one of those security bugs that slips through the cracks.

We realized what happened is we had gone to over-engineering; we had over-engineered for performance. In doing that, we had overlooked the interaction of three components in a very particular circumstance. It was like a “every third Tuesday if you spun around three times” kind of bug. But I think that’s exactly what happens a lot. That’s super common in terms of those last defects, and there’s quite a bit that comes out of that overlap of complexity.

Fewer, more secured suppliers reduces the lift of having to upgrade updated components. It also means if you find an issue, your unpacking of that issue is a lot easier because you have a lot less things going on. All engineers need the reminder of “keep it simple.” But I think that’s a real powerful thing. Fewer, better suppliers, from a supply chain standpoint, is one of the mantras that I really appreciate because I just see it match. It really makes a difference.

Weeks: You’re working with a lot of government agencies across the board. What’s their interest in rugged DevOps practices, or just DevOps practices that you’re bringing into play?

Thrasher: I think in the government space, and it’s true for any enterprise, everything has to have security. There is not an agency that we can work with that doesn’t have privacy data, or heavily secured data, in the defense and intel agencies, or just straight-up vulnerabilities from being a target. The scale of the enterprise means there’s a lot of potential systems and a potential surface area for attack. You can think to all the high-profile attacks that have occurred in the federal government recently, and it’s made people really alarmed!

One of the things that’s very interesting is that the whole federal government did a “cyber sprint” last summer, where they did nothing but pay down technical debt, and get rid of systems and their vulnerabilities. It was wonderful! And I think every organization should do just that: spend one month a year doing nothing but eliminating old frameworks and applications. That really simple, easy thing often gets overlooked because businesses are always saying, “More, more, more, more, more.” However, we actually measured the metrics of the teams after the “cyber sprint,” and all of our teams’ velocity increased. After we let teams upgrade legacy components, all of them had an improvement, which is sort of like a “Well, duh!” But I think it’s a win-win really, that if we can allow ourselves to invest in paying down our technical debt we can get better results.

I think that in a government space, it just has to be part of the equation. So much of what we do is so instrumental to everything.

Link to interview: https://www.youtube.com/watch?v=5veGeDAaJSI

Weeks: As we started off the conversation, you have a new group. You have a lot of projects that are going to get underway. Are you hiring?

Thrasher: Absolutely.

Weeks: Who are the type of people that you’re looking for, if someone wants to get in touch with your company?

Thrasher: We are at CSRA.com, and if you go to our jobs and our careers website, you can see some of the openings we have. Actually, I’m really excited. One of the projects we did internally was building a whole new hiring model. We used big data. We built in some DevOps, and we’re taking advantage of our own technology to do that.

Like I said, what we are really trying to do is build good strong teams, and so that’s something we’re very focused on. So one of the pilots we’ll probably be doing shortly is a team-based hiring model where a team actually hires for themselves.

We’re looking for folks who are just really passionate about solving digital government. And I think that’s the main focus of us is really just being passionate about the mission we’re trying to do. We’re trying to help the government be that digital agency. Looking at the interactions we have with some of these Silicon Valley apps, how come we don’t have that interaction with the government? That’s what we want to create. So we’re looking for people who are passionate about our mission and willing and interested in solving problems. Hopefully we can build a great team.

Weeks: Excellent. Thank you.

If you loved this interview and are looking for more great stuff on Rugged DevOps, I invite you to download this awesome research paper from Amy DeMartine at Forrester, “The Seven Habits of Rugged DevOps.”

As Amy notes, “DevOps practices can only increase speed and quality up to a point without security and risk (S&R) pros’ expertise. Old application security practices hinder speedy releases, and security vulnerabilities represent defects that can leave a company open to cyberattacks. But DevOps practitioners can leap forward with both increased speed and quality by including S&R pros in DevOps feedback loops and including security practices in the automated life cycle. These new practices are called Rugged DevOps.”

August 30, 2016