Author: Bill Doerrfeld

  • Enterprises Face Growing Technical Debt

    Enterprises Face Growing Technical Debt

    Technologists are always espousing new, trendy development solutions. More robust frameworks, increased delivery, better integration. But rarely do these proponents consider the long-term side effects of introducing new technologies. As a result, technical debt is an all-to-common occurrence in most companies.

    Nearly a third of IT budgets are dedicated to addressing technical debt. Devoting so much effort to maintaining legacy code leaves fewer resources to support the status quo, let alone develop new solutions. In fact, a recent study found that 69% of IT leaders identify technical debt as a significant threat to their companies’ ability to innovate.

    “The Growing Threat of Technical Debt,” a report from OutSystems, surveyed 500 IT leaders about this conundrum. Below, we’ll explore the top causes of technical debt and consider ways to prevent it from getting out of control.

    What is Technical Debt?

    Technical debt seems counterintuitive. Isn’t technology supposed to help organizations become more productive? Why would it be a burden? Well, technical debt often arises from hasty decisions taken in the short term that have long-term consequences. It’s also often the result of a company juggling many competing technologies, some of which have become outdated.

    Technical debt can carry a hefty price tag. But this debt isn’t so much measured in the cost of hosting legacy technology or running broken code, but in the hours lost maintaining and patching it. The report found that, on average, businesses devote 28% of their IT budgets to addressing technical debt. This number increases to 40% within large enterprises.

    Common Causes

    There is not one single factor causing technical debt. Many issues within an organization contribute to the problem, including reliance on stale technology, pressure to deliver in the short term, constant change, developer churn and incorrect architectural decisions.

    The top cause of technical debt is too many development languages and frameworks, cited by 52% of respondents as a big or critical problem. Legacy technology can weigh an IT department down. But, it’s not necessarily only old tech getting in the way—it could be that IT is supporting too many competing agendas.

    The second top cause is a high turnover rate within developer teams. In today’s competitive climate, quality engineers are in short supply, and hiring can be challenging. It is thus difficult to attract and nourish steady engineering talent. If developers frequently leave for greener pastures, especially before documenting their procedures, best practices can easily be lost and efficient use of technology is stunted.

    The study found that other common causes include accepting known defects to meet deadlines, using outdated programming languages and frameworks and dealing with challenges in serving new markets or segments. At times, teams release software with known defects simply to meet deadlines. The sheer size of a large organization can lead to increased technical debt, and not addressing it compounds the issue further.

    In terms of industries, the report found the health care and social assistance category hit hardest. In this sector, 35% of IT budgets go toward addressing technical debt, on average. The next most-burdened group is the financial category, which was at 29% according to the report.

    The Costs of Technical Debt

    What are the costs of technical debt? There’s a high price to maintain, reduced hours for innovation and a detrimental effect on overall software performance. Team dynamics could also incur adverse reactions from sustaining technical debt.

    Technical debt requires an disproportionately high amount of time to maintain. On average, engineers spend 33% of their time dealing with technical debt, found Stripe’s “The Developer Coefficient” study. This equates to about 13.5 hours of an average work week.

    The more debt you take on, the smaller the budget left for running status quo operations and building new capabilities. Supporting technical debt not only has financial implications but could stifle future prospects; in fact, 69% of respondents said technical debt limits their capacity to innovate. In today’s acceleration economy, not setting aside resources for digital innovation, could break a business.

    “The combination of old code along with the new generation of mobile apps, stack applications and SaaS sprawl are robbing organizations of resources, time and the ability to innovate,” said Paulo Rosado, CEO, and Founder of OutSystems.

    Technical debt could also stunt performance. According to the survey, 61% of respondents said it causes a significant drag on their company’s performance. Stale projects could interfere with streamlining customer experiences and digital transformation goals.

    Lastly, technical debt could also negatively affect morale. Few engineers take pride in repeating inefficient processes or working with obsolete tech.

    Alleviating Technical Debt: Be Intentional

    Similar to financial debt, technical debt comes with compounding interest. This interest could grow exponentially if left unchecked. So, what steps can organizations take to reduce their technical debt?

    To help alleviate the problem, the report recommends reversing the top two causes of technical debt by stemming turnover in development teams and limiting the number of new programming languages and frameworks you adopt.

    Other methods involve taking stock of your holdings to understand the presence and impact of legacy technologies. Next, rethink and redirect your strategy from simply maintaining legacy dependencies to addressing them and replacing them with modern styles.

    “A lot of bad tech debt comes from building too much and getting stuck spending more time on maintenance and bug fixes than expected,” said Jon Thornton on the Squarespace blog. ”The key is to be intentional about what you invest time in and aware of the costs you’re taking on.”

    Of course, enterprise IT must take on some form of technical debt to function—it’s futile to get rid of it entirely. Therefore, as Thornton advises, be intentional about it and stay aware of the costs you take on. When adopting new technologies, it’s best to consider maintenance implications and plan with longevity in mind.

    For more insights, download “The Growing Threat of Technical Debt” report in full here.

  • Majority of Orgs Lack Visibility Into Container Vulnerabilities

    Majority of Orgs Lack Visibility Into Container Vulnerabilities

    Today’s blend of third-party application dependencies and polyglot software development often makes assessing risk difficult. With many new cloud-native deployment models, it can be tricky to discover potential vulnerabilities. These threats take the form of insecure default settings in Kubernetes, over-permissive states, CVEs that threaten container integrity, and other vulnerable conditions.

    Plugging gaps throughout the cloud-native strata is now crucial to avoid exposing data and breaking privacy regulations. Yet, gaining visibility into these holdings is challenging, and traditional application security practices may not cut it within a cloud-native context.

    A new 2021 CISO Report released by Dynatrace, “Precise, automatic risk and impact assessment is key for DevSecOps,” demonstrates increased false positives and a general lack of real-time container runtime vulnerability scanning among enterprise IT departments worldwide. Of the 700 CISOs surveyed, most report that microservices, containers and Kubernetes have caused security blind spots across their organizations.

    Below, we’ll cover the major takeaways from the study to see why new cloud-native development models are leaving security gaps. We’ll consider how CISOs can increase security throughout the cloud-native IT stack while still reaping the rewards of container-based delivery models.

    Cloud-Native Security Blindspots

    Adopting new container-based technologies may introduce multiple nuanced security implications. Of the tech leaders surveyed, 89% report that microservices, containers and Kubernetes have created new vulnerabilities within their organizations.

    Engineers are shipping code to maintain release velocity and to meet the demand for digital innovation. In the process, 28% of CISOs say application teams sometimes bypass vulnerability scans to speed up software delivery. Due to these realities, it’s no surprise that 71% of CISOs admit they are not fully confident code is free of vulnerabilities before going live in production.

    As some teams bypass security pre-production, it follows that more aren’t applying holistic security scanning during production. As a result, nearly all organizations (97%) lack real-time visibility into runtime vulnerabilities, found the report.

    Adding to the number of cloud-native blindspots is information overload. The report calculated that, on average, an organization receives a staggering 2,169 new alerts of potential application security vulnerabilities each month. Out of this high volume of alerts, 77% of CISOs say they are mostly false positives and not actual exposures.

    Due to minimal testing and a high number of false positives, organizations are likely to leave many vulnerabilities unpatched. To make matters worse, developers, pressed for time, may lack the bandwidth to resolve known issues.

    Faster Delivery, Harder Detection

    Much of the setbacks in vulnerability detection may lie in a general shift toward new ways of working and faster delivery cycles. For example, 63% of CISOs reported that DevOps and agile methodologies are making it harder to detect and manage vulnerabilities.

    In addition, 74% of CISOs say traditional security controls such as vulnerability scanners no longer fit today’s cloud-native world, and 77% of CISOs agree that automation could help. This could involve replacing manual deployment, configuration and management with more automated approaches. Others agree that security-as-code is required to ensure high container security best practices.

    Another result of more frequent delivery is increased over-reporting. Of the total security vulnerability alerts received per month, CISOs report that only 42% of these alerts require action. More rapid release cycles could thus exacerbate already crowded vulnerability detection systems.

    Who Owns Vulnerability Management?

    Only 3% of organizations have real-time visibility into runtime vulnerabilities in containerized production environments, the study found. In reality, vulnerability scanning in production is only happening once a month or less within 68% of organizations.

    To compensate for this gap, most CISOs believe the onus is not on the security team but the application and DevOps teams to manage and respond to vulnerabilities—85% of CISOs believe these groups should hold responsibility for vulnerability management. These findings come to light as other stakeholders advocate for increased full-cycle developer control and encourage the DevOps mindset across roles.

    Handing more control to developers sounds good, yet, 64% of respondents say developers don’t always have time to resolve vulnerabilities before code goes into production. As a result, over one-quarter of application teams bypass vulnerability scanning entirely. Often, engineering teams may not frequently sync with security groups, and DevSecOps principles are not yet pervasive throughout all organizations.

    The report also highlighted the fact that existing security tools are often ineffective; 69% of CISOs say security tools slow down DevOps because they only focus on one state of the software delivery cycle.

    Cloud Use Requires Security Repositioning

    As cloud architectures rise in prominence, organizations are adopting cloud-native tools like microservices, containers and Kubernetes. There is also the chance of multi-tool conditions further complicating the vulnerability scanning process. With more systems to protect than ever before, teams may have to reposition their approach to vulnerability detection.

    “The increased use of cloud-native architectures has fundamentally broken traditional approaches to application security,” said Bernd Greifeneder, founder and chief technology officer at Dynatrace. “This research confirms what we’ve long anticipated: manual vulnerability scans and impact assessments are no longer able to keep up with the pace of change in today’s dynamic cloud environments and rapid innovation cycles.”

    The Global CISO report, “Precise, automatic risk and impact assessment is key for DevSecOps,” from Dynatrace, queried 700 chief information security officers (CISOs) on their monitoring practices concerning vulnerabilities. To review the report’s full findings, you can download it here.

  • Digital Customer Experiences: The Future is Modular

    Digital Customer Experiences: The Future is Modular

    With the proliferation of microservices and APIs, will UIs go modular too? Some technologists note a rising trend around smaller, intent-based customer experiences that more directly mirror API endpoints.

    I recently met with Adam Evans, co-founder and CTO of Airkit, to better understand what’s broken with today’s digital customer journeys and how they need to evolve. He predicted that single-purpose experiences will become more pervasive in the future. In the process, we’ll likely encounter fewer native apps and fewer downloads. To enable all this, he’s putting faith in low-code to bring easier integration and automation patterns to more developers.

    The State of Digital Experiences

    Digital customer experiences are becoming increasingly connected and web-based, and at times, disconnected from the core service. In headless environments, end users are engaging with companies through more and more abstraction layers, such as chat, SMS, voice or email notifications. These interactions are increasingly modular and event-driven, noted Evans.

    Increasingly, user encounters are the result of trigger-based patterns activated when user action is required. Not only is the communication style changing, but new devices and platforms have emerged, further making a case for a decoupled development approach. B2C apps become more modular in this transition, presenting experiences built around specific tasks and closely reflecting the specialized microservices or APIs that drive them. Consider the rise of the single page application (SPA) style or AWS Lambda as evidence.

    As more automation and subscription models enable a “set and forget” attitude to commercial software, Evans predicted we’ll likely see more intent- and event-driven workflows emerge. He said these reimagined UIs would shroud platform complexity and, instead, focus on single, specialized actions, like submitting an insurance claim, checking the status of a package or updating your coffee subscription.

    A Broken Customer Journey

    So why would end user digital experiences evolve into more intent-driven applications? Well, complex digital platforms can get feature-bloated very quickly. Bulky applications with many menus are difficult to navigate, thus impacting user experience.

    As Evans describes, generic interfaces often display tons of information irrelevant to the task at hand. “Don’t make me go through generic interfaces to help me do something specific,” he said.

    Clunky interfaces are at odds with small digital tasks that involve an attention span of 20 seconds or less. Evans describes these as “micro touchpoints in our daily lives where you don’t need traditional, large applications.” These actions could be, for instance, looking up COVID-19 infection rates, checking your credit card balance or updating a streaming subscription, he said.

    Organizations have other imperatives to improve user experience, too. For example, if a platform isn’t self-service, it can increase support calls, which can cost a company significant resources. Plus, if the service isn’t event-driven, users must routinely check in of their own accord, which could waste time and encourage tech anxiety.

    Single Page Applications

    In the age of modular microservices, the days of bulky apps and “manual polling” may be limited. To Evans, the solution lies in expressing the “minimum way to represent the transaction of that interface.”

    “How do we keep moving smaller divisions from the back end to the way interfaces are built?” Evans asked. Similar to the way microservices architecture separates domains, Evans noticed UIs segmenting attention along API endpoints. He envisioned more single-purpose experiences being constructed that extend APIs and microservices with a user interface.

    Technically, this may result in more single page applications being developed. Niche UI layers that map APIs would likely carry a data model, Evans described, so that micro apps are delivered with data for entering fields into API calls. As they are web-based, asynchronous single-purpose experiences could also transcend the barriers of app stores and third-party marketplaces.

    Potential Benefits of Modularity

    More intent-based workflows mean less overhead for the user, bringing quicker, more convenient access to the problems they want solved. Sure, users still register with a core service, such as their bank, coffee subscription service or insurance agency for centralized account management. But, users frequent account centers less often, as the periphery of interactions around them continues to grow.

    “The future of apps will look more like individual, intent-based micro apps,” Evans reiterated. These would reflect a metronome of touchpoints Evans called “little moments of delight.”

    Pinging users only when action is required could reduce check-ins, thus reducing digital anxiety. Aside from the user benefits, deployment and maintenance for small applications may be easier to support, said Evans. Lastly, more isolated intentional customer experiences increase engagement, response rates and sales, he added.

    Using Low-Code For Customer Experiences

    Connected digital experiences are relying more and more on APIs. Yet, API integration can be difficult, even for experienced programmers. So, how do we make it easier for people to build interfaces to hit these APIs? Building user-facing layers on top of APIs will require great developer experience, says Evans.

    Lately, low-code has been dominating these discussions. With greater emphasis on visual-driven development, low-code is empowering non-technical employees. To Evans, low-code capabilities will be essential to influence how future customer journeys are constructed.

    Evans noted how low-code “changes the whole game around how apps are built.” For example, branded experiences often require reusable code and common libraries, all of which low-code platforms excel at. In addition, when working with APIs, a “layer over REST design is essential to maintain state and enable long-term processing,” he said.

    Will The New Digital Journey Go Micro?

    Complex interfaces seem to work for conglomerate giants like Amazon. But other scenarios may benefit from more single-purpose workflows. As platforms become more extensive, the user interactions need to become leaner to avoid added stress. As a result, Evans predicts that micro, trigger-based B2C touchpoints will become more common in the coming years. In this paradigm, better UI extensions of common APIs could help bring people into the equation.

    “We’ll see a lot of cool stuff in the next decade,” he said. “Future apps won’t look like what past ones looked like.” As IT moves to support new, multiple channels, such as chat, voice, web and VR/AR, our perception of what an application is also will inevitably alter.

    In tomorrow’s “great unbundling of apps,” as Evans called it, “if you don’t use it every day, there’s a pretty good chance it doesn’t need to be there.”

    There are many schools of thought on the best methods to retain quality user experiences. Do you think modularity is the answer? What do you think tomorrow’s digital experiences will look like? Feel free to let us know in the comments below.

  • 10 Actions IT Can Take to Curb Climate Impact

    10 Actions IT Can Take to Curb Climate Impact

    Digital technology is responsible for 3.7% of total CO emissions, according to estimates from The Shift Project. This could increase, as cryptocurrency mining is leaving a massive carbon footprint. With the world’s climate at stake, every percentage point matters.

    Thankfully, many tech companies have announced significant climate pledges to reduce emissions or offset their carbon footprint. For example, Microsoft states they will be carbon neutral by 2030. Amazon has committed to a deadline of 2040, and other companies such as Infosys have co-signed. Netflix’s climate commitment states they will reach net-zero greenhouse gas emissions by the end of 2022.

    Sustainability goals are vital long-term benchmarks, but on-the-ground technologists must make immediate optimizations to realize them. So, what exact steps can enterprise IT take to reduce their energy consumption and thereby reduce greenhouse gas emissions?

    I recently met with Anant Adya, Infosys, to explore the overall energy footprint of enterprise technology. Below, I’ll cover 10 ways IT can reduce its impact on the environment, including actions like auditing legacy infrastructure, optimizing cloud operations and moving toward renewable energy sources. Many of these energy optimizations bring the added benefits of cost savings and code consolidation.

    1. Reduce Resource-Heavy Legacy Infrastructure

    One potential cause of unnecessary energy consumption is legacy infrastructure. To reduce power consumption, Adya recommends going straight to a network compute storage setup. You may find energy consumption savings by porting resource-heavy legacy systems to the cloud. This will be especially effective if you’re running older end-of-life machines with less efficient processing.

    2. Reduce the Number of Clouds

    Next, look at the number of clouds your organization has adopted, Adya recommended. In recent years, companies have moved to multi-cloud setups for reasons like performance, cost or features. However, these movements could cause unnecessary duplication. For a large enterprise, refactoring your multi-cloud usage could mean reducing from five or six clouds to two or three, said Adya. With the right combination, you could very likely reach equivalent benefits with less reliance on multiple clouds.

    3. Reduce the Number of Core Data Centers

    Look at the number of sites in your core data centers and reduce the footprint, if possible. In his digital transformation work, Adya described working with a client to consolidate six large data centers into three essential locations — one for disaster recovery and two others to support American and European zones.

    4. Move Edge Locations to the Cloud

    Large organizations may be supporting a lot of edge infrastructure. Yet some locations, such as offices, don’t require that kind of infrastructure, Adya suggested. He recommended reducing local servers and embracing more cloud-based computing solutions, overall. He described one case in which an organization consolidated 600 edge sites to 350, thus reducing power consumption by 40%. Adya credited the cloud for delivering lower costs and greater scalability and resiliency.

    5. Embrace Cloud-Native Administrative Operations

    Cloud computing is arguably more energy efficient than traditional on-premises arrangements with its pay-per-use model and multi-tenant approach. To get the most out of the cloud, Adya recommended moving to the cloud, along with adopting cloud-native software. Most operational and administrative work can be processed in the cloud, he noted.

    6. Consolidate and Rationalize Resource Utilization

    Another way to stem energy consumption is to check for underused or forgotten assets. While the cloud can help optimize software, there is a good deal of unnecessary cloud spending on underused resources. In 2020, companies wasted $17.6 billion paying for idle resources and overprovisioned computing instances, reported ParkMyCloud. Adya thus recommended looking at the entire server and storage estate to calculate the server utilization and slimming down wherever possible.

    7. Increase Power Usage Effectiveness (PUE)

    Hardware is much more efficient these days — sometimes by as much as 10X more powerful with 10X less energy consumed. As storage technologies also are always improving, it could make sense to upgrade to new hardware to reduce overall power usage. It’s important to monitor power usage effectiveness (PUE) and check power ratings before and after migrations. Adapting your information life cycle management tiering practices for storage could also help optimize to reduce wasted power, Adya added.

    8. Meet Sustainability Goals on Campus

    Have you ever driven by an office park at night and seen thousands of empty rooms with all the lights on? This has got to change. Another way to reduce power is to limit a campus’s energy consumption, described Adya. Smart automation and remote monitoring could be used to manage power efficiency by turning off lights and heating and cooling to meeting rooms when empty, for example.

    9. Power the Business With Renewable Energy

    Run your campus with solar power. Adya described how Infosys is doing this by mounting 40MW solar panels at their corporate centers, in effect sourcing 43% of its energy from renewable sources. Another more passive way to invest in renewables is to choose a data center provider that commits, under contract, to using a high percentage of renewable energy.

    10. Purchase Carbon Offsets

    The previous goals are all active steps to reduce energy requirements. However, once an organization has attempted these optimizations, another option is carbon offsetting. This indirect method effectively cancels out a company’s emissions by funding green activities, such as tree planting.

    However, there is debate over the effectiveness of carbon offsetting, as trees take decades to become effective carbon consumers, and the practice doesn’t advocate for immediate change to harmful practices. “To be serious about tackling climate change, [organizations] need to stop carbon emissions from getting into the atmosphere in the first place,” wrote Alia al Ghussan for Greenpeace.

    IT’s Role In Curbing Climate Change

    Dire climate circumstances require quick action from all business units. In the process, organizations will likely consider many initiatives simultaneously to address their climate impact. However, as more companies become digital-first businesses, the onus falls on IT to support these changes.

    In addition to the above actions, there are undoubtedly other ways enterprise software architects can stimulate sustainability initiatives within their organization. This could include refactoring code into more lean iterations or eliminating unnecessary records storage. Tech leaders could also vocalize their support for global pledges, such as the Paris Climate Agreement, RE100 or Global Optimism.

    It would take a solar power plant covering 115,625 square miles, roughly the size of New Mexico, to power the world with solar energy! As you can see, it will take a lot of work to reverse our reliance on fossil fuels. But with scalable cloud computing and more intelligent infrastructure optimizations, IT can do its part to contribute to curbing climate change.

  • Unifying Partner Ecosystems With a Distributed Ledger

    Unifying Partner Ecosystems With a Distributed Ledger

    Blockchain has become famous in recent years for powering the cryptocurrency craze. But the fundamentals behind blockchain could prove helpful in other areas of the data economy, too. Because, as the value of data rises, so does the need for accurate, real-time data sharing across multiple partners.

    As we saw recently, global trade is surprisingly fickle. If a 1,300 ft long cargo ship can end up blocking the Suez Canal for an entire week, imagine how many data record incongruities the shipping and logistics industries have to sort out each day. Similarly, other partner networks, such as food distribution or airline affiliates, for example, must constantly share data back and forth to remain in business.

    Since a distributed ledger is external yet sharable with partners, it opens some interesting data-sharing possibilities. Similar to merges for collaborative software, partners would retrieve and manipulate the distributed ledger, which would act as a source of truth for status on a physical object or a piece of data. Essentially, this process could reduce manual reconciliation efforts and avoid disputes when something goes wrong.

    I recently spoke with “father of serverless” and AWS Lambda inventor Tim Wagner. Wagner, now heading Vendia, shared with me why he foresees distributed ledgers as the future for real-time, business-to-business data sharing. “Supply chains are surprisingly brittle,” Wagner said. To solve this problem, we need an “automation of that workflow that isn’t centralized any longer,” he said.

    Role of a Distributed Ledger

    A distributed ledger could be especially relevant for a multi-party supply chain. Within multi-partner agreements, data tracking is complex, and many partners struggle to come together. “Companies are struggling for a lack of truth,” said Wagner. “Everyone wants their own copy of the data, but they want it to be locked to what everyone is seeing at the same time.”

    For example, take supply chain management. Suppose an automotive parts manufacturer produces a chassis. They send it to a shipping logistics provider, who then sends it to an automaker to complete assembly of an automobile. If the chassis breaks at some point during these handoffs, whose fault is it? Without a system of record, you open a big problem of distrust, Wagner explained.

    Or, consider an airline ecosystem. Partner airlines must often coordinate multi-carrier flight plans, apply discounts or settle unused travel vouchers. Often, it’s difficult to track the journey of these transactions between organizations. An externalized ledger could help partner airlines follow the route of a single passenger, helping to ease financial settlements.

    “It’s not just about sharing, which is hard enough, but it’s really about sharing with control,” said Wagner. These days, tracing the lineage of data is critical, as is having real-time visibility into an object’s state. A distributed ledger could help these partner ecosystems have a record they can all trust. Wagner describes this as a tamper-proof, immutable record — an “unassailable source of truth.”

    Would This Replace Partner APIs?

    What’s especially interesting to the integration-minded is that the distributed ledger concept could supplant established business-to-business communication models. Over the last couple of decades, most partner integrations have moved to RESTful API connections. One company opens up data access, and another authenticated partner makes HTTP API calls to integrate data into their own application.

    Yet, the issue here is that the API is only a layer on top of a private database owned by the provider. Located behind closed doors, there’s no industry-wide real-time data synchronization. API calls are good for data retrieval and manipulation, but stringing a sequence of thousands of transactions together is difficult, described Wagner. Retaining the time-series integrity of a complex database is a little too much for synchronous calls to handle.

    Instead of opening access to an internal platform via API, Wagner believes that a distributed ledger is a better fit for certain business-to-business machine automation. “Any place where you see API-level protocols developed to maturity is a good sign; there is a good chance distributed ledgers will find greater speed,” he said. “Trying to pull that information through APIs and pray you’re finding the right data is difficult to manage.”

    For example, Wagner referred to how some animal shelters are creating a global repository to avoid siloed records. In doing so, they are making a global animal rescue schema for a unified database that could hopefully help every pet find a home.

    Communicating with the ledger would still involve calls, but likely not your typical RESTful requests. Wagner advocates for the use of GraphQL as a better method to involve clients around changes. With a GraphQL API, stakeholders can query, mutate and subscribe against changes in a distributed system. GraphQL isn’t perfect, but its easy data mechanics make it a Goldilocks-style middle ground between REST and SQL, said Wagner.

    Getting Buy-In

    A synchronized distributed ledger could help resolve disputes and reduce manual checks. But, how do we get buy-in? How can you convince an entire partner ecosystem to align around a distributed ledger as a source of truth?

    Wagner says there is usually a leader or single manufacturer leading the charge. This figure is likely a more prominent, well-respected player in the process. But for a digital ledger system to be successful, it must also satisfy other criteria too, Wagner said:

    • Data schema forethought: Agreeing upon a shared data schema may be a challenge. Ecosystems will require forethought when designing a data model for the long haul.
    • Compliance: There are many new data regulations to consider, such as GDPR, CCPA and PCI. “You can’t blindly copy data the way you used to,” said Wagner.
    • Governance: As enterprises deal with data crossing boundaries, they must apply governance measures to satisfy compliance and maintain security. This governance needs to be tightly associated with data and offer fine-grained control.
    • High performance: A distributed ledger requires operational flexibility for large objects, such as a 5 TB file, noted Wagner.
    • Redaction capabilities: Whereas some partners must see all fields, others may, by law, be limited in what they can view. Thus, a ledger must include the ability to redact fields. Wagner described this as “intentional redaction or visibility control of individual customer records.”

    Of course, different industries are at very different points along their digital journey, some more advanced than others. Change may be easier for, say, financial services supporting ACH payment technology, which Wagner described as being “ripe for natural organic expansion into a data-centric methodology.”

    The Poor Man’s Blockchain

    Tapped into the same feed, an extensive partner ecosystem could use a blockchain-esque arrangement to stay on the same page. This could help reduce manual reconciliation typically handled through email or over the phone.

    Yet, as distributed systems experts are few and far between, implementing such technologies will most likely involve a cloud platform solution, said Wagner. He jokingly calls this the “poor man’s blockchain.” Such a solution must be cloud-friendly, enterprise-focused and easy to integrate and deploy.

    As more and more critical data begins to reside outside company walls, “organizations have to reconstitute that data to work with partners,” said Wagner. A distributed ledger could, in effect, act as a sort of outsourced centralized IT, enabling a data model for serverless environments.

  • Will App Dev Become a Normal Competency?

    Will App Dev Become a Normal Competency?

    With a shortage of available developers, companies are considering low-code methods to meet massive application development needs. As a result, by 2024, citizen developers will be responsible for 65% of applications, Gartner predicted. So, if technical ability rises across the board, will application development become an expected skill set for tomorrow’s digital workers? And if so, when?

    “Application development will become a normal competency,” said John Bratincevic, senior analyst, Forrester. Bratincevic recently gave a talk at the Rethinking “How” into “Who” with Low-Code event, presented by TrackVia.

    I asked Bratincevic to dive deeper into how application development is becoming democratized. In short, the low-code movement has permanently altered expectations around who can be involved in application development. To him and others within the industry, leveling up with citizen development knowledge could be vital to retaining a competitive advantage in the future digital-native workplace.

    The Undigital Condition

    As more and more companies digitally transform, they are evolving into software companies. In this new paradigm, “software is an expression of the business,” says Bratincevic. Yet, most organizations have not entirely digitally transformed. According to Forrester’s Q1 2020 Global Digital Process Automation Survey, 76% of companies still rely on paper-based processes, and 94% use Excel or email-based processes.

    Unfortunately, developer talent is too few and far between to rectify this “undigital condition,” and existing IT teams are struggling to keep pace with demands for more software-based processes. Too often, teams are told to get in line and wait for experts to develop software when they can, said Bratincevic. This gap results in a less adaptive structure that limits new ideas.

    “All organizations are probably, to some degree, adaptive, but their improvement and adaptation are typically only periodic and conducted by specialists,” wrote Mike Rother, Toyota Kata. “In other words, such organizations are not, by their nature, adaptive.”

    A New Generation of Citizen Developers

    The old model is not realistic anymore, said Bratincevic. Instead, a new generation of citizen developers could use no-code and low-code platforms to program operational tasks themselves. These tools use visual, declarative techniques instead of programming and are “empowering employees outside of IT to deliver apps,” Bratincevic said.

    So what is the demographic behind citizen development? Reports show that younger, digital-native employees are more likely to use low-code platforms. According to the TrackVia report The Next Generation Worker: The Citizen Developer, 50% of citizen developers are 18 to 29 years old. The study also found that citizen developers are 13% more likely to expect promotions, correlating citizen development experience to career advancement.

    In this projected economy, “digital elites” seem well-positioned to progress, whereas others are in dire straits. “Knowledge workers with simpler, more focused roles (e.g., a “coordinator”) and without digital skills are at risk,” said Bratincevic. Thankfully, low-code could offer a practical way to enter the tech field and increase job security.

    Leveling Up From Productivity Tools

    Today’s average worker is quite familiar with personal productivity apps such as email, social communications, calculations and other consumer technologies. Just as productivity tools have become commonplace, Bratincevic predicts that application development will become a standard skill set in the future.

    Other IT leaders agree that coding literacy will soon become ubiquitous. Apple CEO Tim Cook, for example, recently emphasized to the U.S. president that “we believe strongly that it should be a requirement in the United States for every kid to have coding [education] before they graduate from K–12 and become somewhat proficient at it.”

    Application development may become a typical proficiency; however, the exact nature of software development is up for debate — especially as development environments add more abstraction layers to the lower stack that only involve programming languages indirectly. For example, Bratincevic describes how those learning to code often use a service like code.org, which involves low-code tooling and games to help educate students. “I see the same pattern for the adult professionals in the workforce,” he said.

    Future application development may not even resemble programming in the traditional sense. “Once ‘development’ on these kinds of tools becomes ubiquitous, we may not even call it application development anymore,” Bratincevic said. “It will just be — work.”

    Goals for Citizen Developer Programs

    According to an Outsystems report, 20% of companies adopted low-code to enable citizen developers to construct applications. “One of the main reasons firms are buying low-code is to enable non-IT folks to develop,” noted Bratincevic. “I routinely get inquiries from enterprises who are looking to accomplish this very thing, at scale in their organizations.” In particular, he notes apps of substance being created within health care, vehicle manufacturing, oil and gas and insurance industries.

    It appears more and more organizations are sanctioning a new wave of citizen developers. So what goals should these new citizen development programs aim to achieve? Bratincevic shared the following benchmarks:

    • Digitize. Everything. Always: Foster a digital problem-solving culture and develop a digital workforce.
    • Balance autonomy and control: Citizen developers shouldn’t have to ask permission to make a spreadsheet. Yet, guardrails are necessary for more far-reaching programs.
    • Take charge as privateers: He recommends organizations start by adopting an autonomous, business-led team, which he calls a Privateer model.

    Low-code could also help bring shadowy, rogue IT to light and rehabilitate it in a sanctioned way.

    The Era of Low-Code

    In 2021, the low-code market is estimated at $13.8 billion, said Gartner. SD Times even coined 2021 the “year of low-code.” But, since the citizen developer movement has permanently raised the bar, I would edit this statement to say we have entered the era of low-code.

    For more information and case studies on citizen development, I recommend watching the panel webinar Citizen Developer Movement with Forrester: Rethinking “How” into “Who” with Low-Code. In addition to John Bratincevic, it features Dave Garret, chief strategy and growth officer, PMI, (who I’ve spoken with in the past on How To Foster a Culture of Citizen Developers) and Joshua Yaklin, SVP of operational risk, Stearns Lending.

  • The Role of APIs In Digital Transformation

    The Role of APIs In Digital Transformation

    Digital transformation is increasingly propelled by rapidly changing user expectations. Release frequency is increasing, as is the need to connect a growing number of applications and digital experiences. As a result, 83% of IT specialists consider API integration critical to their business, found the State of API Integration Report.

    Application programming interfaces (APIs) hold powerful sway in tech discussions of late. Building API-first could increase internal reusability. APIs have become a standardized machine-readable mechanism for connecting partners. There is also a hot market for API startups, meaning APIs are becoming products in their own right.

    APIs are also enabling change for large enterprises. I recently connected with Bernd Gross, CTO at Software AG, to get his perspective on the role APIs and integrations are playing within the new wave of enterprise digital transformation. Below, we’ll see how connected customer experiences, digital business excellence and a new ecosystem-driven economy are driving the emergence of more API-based strategies.

    Three Drivers of the Connected Enterprise

    Businesses continue to transform into more connected enterprises. Once relegated solely to improving back-office efficiency, digitalization efforts are being applied across the board — to employee management, assets, machines, partners and the supply chain at large, said Gross.

    Amid rising digitalization, connectivity is the glue that unites disparate elements and tools. A fully connected world is “the new flavor of digitalization,” said Gross. To his point, ‘connected experiences’ is a crucial driver for 68% of platform providers, The State of API Integration Report found.

    So, how are APIs fueling the new connected enterprise? Gross identified three key reasons why integration is now fundamental to enterprise digitalization initiatives.

    Software AG Marketecture, used with permission.

    1. Connected Customer Experience

    Many organizations “want to transform into a technology and software company,” said Gross. To participate in the connected digital economy, organizations are striving to create advanced 360-degree customer experiences. Today’s technology needs to “look beyond a PC application,” Gross said. These experiences must cater not only to desktops and smartphones but also to IoT devices and physical assets.

    For example, he explains how one large elevator company architected an embedded connected experience, incorporating digital touchpoints within elevators to showcase signage, entertainment and ads, opening new monetization possibilities. This change was so radical that the mechanical engineering company pivoted its mission statement, reimagining itself as a “vertical transportation company.” Soon, their AI-enabled elevators will predict behaviors and optimize travel times, so they are always on the right floor, waiting for human riders.

    Intelligent building technology is similarly being applied by digital-savvy hotels, Gross explained, which is especially important for contactless visits during the pandemic. A fully digitalized customer experience could involve automated check-in, a room access code sent to a smartphone, an online billing system, physical sensors and more. Enabling a seamless digital hotel experience sounds easy, but it’s technically quite challenging — there are endless integration requirements to connect. In some cases, it would take 24 integration points, noted Gross.

    2. Digital Business Excellence

    Gross recognized the high expectations for modern digital experiences. He described a “new trend of business excellence in delivering more of an end-to-end digital experience.” This means data can no longer be locked up; even traditional companies must transition to platforms to offer software and data to their end users. In the process, interesting things may occur — your customers could become partners, Gross adds.

    He described how one medical company, a leading centrifuge producer, sought to build more digital experiences to complement their hardware. Though the machine functioned seamlessly, there was no easy way to port data results to other applications. This inhibited initiating the fully digitalized workflow required for a smart lab experience.

    In this case, APIs were imperative to opening up back end cloud services to enable smooth user interfaces and end-to-end workflow automation. “Intuitive user interfaces must integrate all services, including cloud and on-premises services, to create and automate workflows,” Gross explained. “To do this, you need integration.”

    3. Ecosystem-Driven Economy

    The network effect of platforms is that they enable an ecosystem to form. And, according to Gross, involving partners in this new digital experience matrix is imperative for success. For example, the API gateway is one area where partnerships help an integration strategy; “You need an API gateway for security and governance reasons,” he stated.

    Throughout his experience overseeing APIs on many projects, Gross often noticed a naïveté associated with defining the ecosystem. “When [clients] engage in the first phase of these projects, they think they know how to do it, but they typically don’t,” he said. Potential API providers often don’t fully realize their monetization strategy, the security implications or the complementary software providers necessary to support a working model. “Partnerships often facilitate a value-add to customers — they enrich the total offering through APIs and ecosystems,” said Gross.

    Similar to how a machinery company may embed a bill of materials into the product they sell, digital partnership ecosystems can open up data so partners can access and innovate with it, Gross said. Frequently, ecosystem partnerships make a lot of sense, as they can better meet consumer expectations. For example, Gross suggested that integrating a ticketing system into a conditional monitoring system would bring compelling value.

    The Next Stage: Self-Service Integration With APIs

    According to the report, 40% of companies said that digital transformation is driving their need for app integration. Truly connected enterprises must embrace digitalization and integration across all aspects of the business. As a result, this is forcing a business shift toward more open ecosystems.

    But building these systems will require newfound knowledge dissemination around developer experience and self-service capabilities. “Self-service has become fundamentally important,” said Gross. It’s not enough to simply open interfaces — you have to also add self-service capabilities to integration tools, he added. This could mean offering low-code options alongside APIs — such drag-and-drop UIs would help facilitate integrations for more citizen developers. A self-service approach to digital platformification is an emerging trend, yet one that’s “not fully at mass market,” described Gross; it’s still in its early stages.

    Open ecosystems are guided by consumers, who often desire connections between your tool and external partners. But, opening up data isn’t just helpful for partner integration; it could also benefit internal use. As Gross described, time-series industrial analytics could empower operators on the shop floor or production facility to make sense of local data. “You need self-service analytics tools to give them that ability,” Gross said.

    Building new customer experiences to cater to various devices and platforms is a big driver for API adoption. As a result, headless styles are emerging to address multi-platform requirements. For these reasons and many more, APIs are fueling new digital transformations across enterprises, powering innovative customer experiences and hiding complexity in the back end. With APIs, smart processes, smart machines and smart partners can all come together.

  • More and More Enterprises Go Headless

    More and More Enterprises Go Headless

    IT faces high expectations for building and supporting omnichannel digital experiences. Simultaneously, web developers hold an evolving toolkit of architectural approaches to deliver content. One such framework gaining mindshare is headless, a style that decouples front end user experiences from back end application logic.

    Legacy options for content delivery can be somewhat cumbersome in that they don’t apply well to scenarios beyond websites. On the other hand, a headless framework uses web APIs to communicate with clients, making it a more adaptive model to support new devices and use cases.

    WPEngine recently released global research on the state of headless. Below, we’ll review the top findings from The State of Headless: A Global Research Report. I also met with Matt Landers, developer relations manager, and Jason Bahl, principal software engineer at WPEngine to discuss the evolution of headless and its future implications for developers.

    What is Headless?

    First off, what is headless? Headless decouples the front end from the back end, thus separating the user interface (UI) from the data and code that powers it. The headless movement represents a shift from traditional content management systems (CMSs) such as WordPress, Squarespace and Wix.com. These platforms are less extensible, as they intrinsically unite the back end with user-facing representations. Traditional CMS is “typically not that easy to scale,” noted Landers.

    Headless challenges the status quo by offering more flexibility. As headless adopts API-based content negotiation, it could essentially deliver highly personalized experiences to any connected device. This could help support emerging platforms, like mobile, voice assistants or augmented reality (AR).

    Simply put, headless is “a CMS that is not responsible for rendering the site,” Landers explained. “What attracts people to headless is component-based architecture and the ability to build isolated components,” he added. For example, a headless framework could include an author bio component that is reused in any custom style across devices. By deploying to a CDN, headless could enable high-speed performance, as well.

    Headless Adoption Surges

    Interest in headless is increasing across the board. Currently, 64% of enterprises surveyed adopt a headless approach, representing about a 25% increase from 2019. Furthermore, headless use is expected to grow: over 90% of organizations not currently using a headless setup plan to evaluate a headless option in the coming year.

    The strong interest in headless likely represents a growing necessity for large enterprises to support various digital channels in a consistent manner. In fact, 92% of organizations credit headless with delivering a more consistent content experience, the report found.

    Benefits of Headless

    A key benefit to introducing headless is the decoupled nature of the approach. This makes it possible to support multiple platforms, such as websites, mobile apps, IoT devices, connected kiosks, smartwatches, voice assistants, AR and virtual reality (VR) from the same source.

    Respondents also cited additional benefits to adopting headless such as increased performance, quicker time to market and rapid innovation. These positive attributes make sense because, with headless, applications only request the data they need. Therefore, headless could certainly facilitate more dynamic applications and custom-tailored user experiences. If used effectively, headless setups reduce bloat to create fast-loading digital experiences that further the SRE agenda.

    Tech Choices and Use Cases

    An average organization is spending $2.6 million on their headless implementation, found the report. So, what are they spending it on? Well, some common headless frameworks and SaaS platforms include Contentful, GraphCMS, Atlas, DatoCMS, Cosmic, Netlify, Sanity.io and Prismic, among others.

    While the report didn’t query respondents on their exact headless stack, it revealed a general satisfaction with headless solutions, with relatively high net promoter scores (NPS). When selecting a headless provider, respondents tend to consider performance (41%), e-commerce (35%), scalability (33%) and APIs and extensibility (30%).

    Though headless spans many use cases, e-commerce is clearly a primary use case for the headless stack, with 51% of respondents adopting headless to support e-commerce. Other top use cases for a headless approach include a website (52%), IoT (47%) and progressive web apps (40%).

    Drawbacks of Headless

    Though headless provides impressive malleability, it does require a shift in thinking, and implementors must inevitably overcome certain drawbacks. API security, for example, is at stake as API attacks and threats increase.

    Headless could also require additional administrative burden in terms of data integration and upkeep. With headless, instead of using plugins, IT must enlist front-end developers to integrate data and build front-end behaviors. Debugging a decoupled front end and back end can also be an added development burden. “There is an opportunity in the headless ecosystem in general to mature the experience for the content publisher,” describes Bahl.

    Future of Headless

    Within today’s remote economy, most acknowledge that digital experiences are now crucial to supporting business at large. In fact, 92% of organizations believe digital experiences are vital to their organization’s success, found the report.

    Headless architecture promises to retain a stable back end to support these escalating digital demands — especially useful considering the ever-changing nature of front end clients. On that note, the report found that 32% and 31% of respondents adopt headless for VR and AR experiences, respectively. Therefore, the headless approach appears to be a valuable technique to future-proof current investment against emerging digital trends.

    The State of Headless: A Global Research Report, conducted by Vanson Bourne between January and February 2021, surveyed 400 IT/technical employees with knowledge of headless. For more insights, you can read it in full here.

  • ‘Old Man Yells At Cloud’

    ‘Old Man Yells At Cloud’

    These days, software programmers are increasingly estranged from hardware. Most millennials and Generation Z developers have never had to mount physical servers. They have never been lulled by the gentle hum of a server room chugging along in synchronous harmony. Today, you don’t even necessarily have to build your own PC or worry too much about disk space.

    Instead, cloud-native software developers conveniently offload the server burden to cloud service providers (CSPs). Hosting in a cloud, like AWS or Azure, for example, makes a lot of sense — it allows programmers to hone in on their own specializations. Elastic computing models are cost-effective for startups, and CSPs typically offer a vertical stack with helpful integrated platform-as-a-service (PaaS) and software-as-a-service (SaaS) offerings. However, what are we sacrificing?

    Well, first, research shows the cloud model becomes less cost-effective as a business scales. Second, as more companies transform into technology platforms, cloud usage could better enable their competition. Third, more direct access to bare metal could be an attractive option for certain service providers to increase ownership and control workload optimizations.

    These arguments are bolstered by large companies such as Dropbox, Facebook, Walmart, and others that chose to cut their cloud allegiances in favor of building their own data centers or adopting colocation (in other words, running your own hardware in someone else’s data center, also known as “colo”).

    I recently met with Zach Smith, managing director, bare metal, Equinix, to understand the current state of hardware-as-a-service and the future of hybrid server models. He believes that in the coming years, improved interfaces that access low-level infrastructure will arm IT with better consumer choice that brings them closer to the metal. Yet, to enable this, the hardware world will need to take some lessons from the upper stack regarding transparency, open source community, programmability and improved developer experiences.

    Sidestepping the Cloud

    Public clouds arose as a convenient one-stop-shop to host entire software application environments. As a result, “we have a generation of developers who will never physically touch that hardware,” Smith said.

    The cloud infrastructure services market was worth $39.8 billion in Q4 2020, estimates according to estimates from Statista. Having witnessed the “movement toward verticalization of hyperscale clouds,” Smith now sees the infrastructure-as-a-service (IaaS) market as an industry of high margins and escalating fees. This is echoed by others who seek to reduce rising cloud expenses.

    Though cloud computing usage is growing considerably, the data center isn’t dead. Instead, computing models are morphing and becoming hybridized. “By 2025, 85% of infrastructure strategies will integrate on-premises, colocation, cloud and edge delivery options, compared with 20% in 2020,” predicts David Cappuccio, distinguished VP analyst, in a Gartner report.

    As hybrid multi-cloud approaches emerge, Smith notices a resurgence of attention being paid to infrastructure. Some massive service providers are starting to construct their own data center estates; others, such as Box, now own and lease servers from data center providers.

    Benefits of Bare Metal

    As mentioned above, there are a few reasons to move back to the metal. First, it may simply be more cost-effective for large deployments. In his well-researched article, Antoine Beaupré compared monthly recurring costs for colocation versus an AWS bill, and found the break-even point rested at $100,000 per month, or 150 Amazon m4.2xlarge instances. His research also found that I/O-heavy applications are more costly in the cloud than via colocation.

    “While many services simply launch in the cloud without the organizations behind them considering other options, large content-hosting services have actually moved back to their own data centers,” Beaupré said.

    In addition to cost savings, automating colocation with a programmable layer could also offer more fine-grained control over computing optimizations. “I believe what we’re creating is an operating model for a rapidly changing hardware substrate,” said Smith. He described how bare metal opens up a neutral infrastructure substrate to control physical networking aspects such as cross-connects, IP transits and peering — a benefit Smith half-jokingly called ‘NetDevSecOps.’

    Another argument is that investing in hardware could, ironically, bring sustainability benefits. A report conducted by ITRenew estimates that, of the total embodied energy required within a server’s entire lifespan, 77% is used to manufacture the hardware itself. In contrast, the operational energy used over a server’s lifetime only accounts for 22%.

    Thus, there is an environmental benefit to reversing the trend of a make-dispose economy continually producing new servers. Instead, hardware ownership could encourage a more circular economy. “A circular economy aims to end our take-make-dispose economy, which is a very linear approach, and instead, keep products at their highest possible value for as long as possible,” according to the ITRenew report.

    Learning From the Upper Stack

    How can we build a fundamental non-opinionated infrastructure platform? According to Smith, the industry needs “hardware and networks that are programmable and usable by a developer generation.” To Smith, changing firewalls at a kernel level, altering how the runtime works or controlling the IP stack, should all be operational via API commands.

    Yet, hardware accessibility is still rather opaque and, historically, not as developer-friendly. “How can we take abstraction and community-driven ideas from up the stack?” Smith asks. To enable these changes, he believes the hardware world should model itself on the upper stack in a few key areas:

    1. Transparency: The hardware world is not as easy to comprehend. “When you get to the physical side of switches and routers, it’s still arcane,” Smith said. Increased transparency in functionality and ownership will be required to turn servers into something all developers can operate.
    2. Open-source community: In the same way the software world is built on strong developer communities, hardware will require an open community to normalize things like firmware, boot order and support for differences between drives.
    3. Programmability: “Self-service and programmability are requirements for most things these days — there’s no difference with physical infrastructure,” says Smith. Take the rise of the API economy — today’s mantra is, essentially, if something is possible in a UI, it should be possible through an API. Similarly, if it can be done in a server, it should be controllable with an API.
    4. Quality developer experience: Self-service, programmable infrastructure is just the beginning — interfaces to operate infrastructure require good developer experience. Smith feels that hardware requires an improved buying experience and better life cycle management capabilities. This could be enabled by open source tools like Tinkerbell, a provisioning and workflow engine supported by Linux Foundation.

    Back to the Metal — A Platformer’s Dream?

    All this is not to say the public cloud isn’t valuable – it absolutely is. The cloud has been necessary and has proven resilient enough to support online business and digital life as we know it throughout the pandemic and for years prior. “In 2020 and beyond, most organizations are going to be transforming into a completely cloud-based environment,” said Werner Vogel, CTO, Amazon, during an online AWS summit.

    But, even if most organizations are in the cloud, that doesn’t mean all of their assets will be. Service providers, especially, may cling to hybrid models for more control, to avoid supporting the competition and, perhaps, even to save money. Private data centers could also increase security. In an era where raw computing power is becoming a new asset (quite literally, in the case of cryptocurrency), the server rack is starting to look sexy again.

    “The magic happens when software and hardware work together,” said Smith. But, giving access to physical technology to a generation that has never touched it will require some ingenuity. As Smith says, this could be done by “automating colo” through more usable, standardized interfaces for hardware management.

    “We will see a future in next 10 years where operated software is separated from cloud infrastructure,” Smith said. That’s a bold statement, as such a dramatic change would, in effect, usurp the current cloud provider IaaS market share, altering the distribution and economic model associated with global software.

    While this dream may seem far-fetched, if more platforms decide to cut out the cloud middleman and go it alone, it could materialize.

  • Seeing the Bigger Picture With BizDevSecOps

    Seeing the Bigger Picture With BizDevSecOps

    Not long ago, if you can believe it, software was shipped on physical floppy disks and CDs. These physical relics contained dense paper instruction books that humans read diligently for hours on end (I guess they had more time to spare back then?). Complexity was a given for computer-based tasks.

    Fast forward past the consumerization of IT to 2021, and you’ll find extremely high standards for technology. End users now expect intuitive apps with instant end value and 100% uptime. If they don’t receive gratification within minutes, they’re likely to trash it.

    In the race to meet digital innovation demands, software companies are increasingly tapping new strategies to deliver iteratively. Thus, disciplines like DevOps, DevSecOps, low-code and SRE have flourished. But are we adequately considering the end value of that work? Some feel business leadership needs a larger seat at the table and more input: enter the newest iteration of these disciplines, BizDevSecOps.

    I recently met with Gregg Ostrowski, CTO at AppDynamics, to discuss how to introduce BizDevSecOps in an organization. For Ostrowski, it boils down to having full-stack observability to connect application performance, security threats and revenue generation. Only by democratizing access to important metrics and identifying runtime weaknesses can business outcomes truly drive production.

    Full-Stack Observability

    Within our new pandemic-first reality, all organizations are amplifying their use of digital services to interact with customers. However, software teams are struggling to keep pace in this new environment — 89% of technologists report feeling under tremendous pressure at work, the Agents of Transformation 2021 report found. This strain has only increased as IT complexity soars amid the pandemic — 83% felt their job became more complex over the past year.

    IT staff is under mounting pressure to perform, and they may not have the correct elements in place to support elegant and profitable applications, said Ostrowski. When it comes to monitoring, in particular, alert fatigue could especially hamper innovation attempts and make it difficult to know what to prioritize.

    Instead, Ostrowski advocates for letting tangible business outcomes, such as conversion rates and performance, drive development. To correlate the impact on revenue more directly, he encourages “giving business leaders a seat at table during the entire CI/CD pipeline.” One aspect to roping in business, security, development and operations is unified observability across the entire stack.

    The Pendulum Swings

    But wouldn’t it be challenging to give business leaders a seat within a technical software delivery process? Well, this wouldn’t be the first time business has directed technological change.

    Ostrowski recalls the mid–2000s and the dawn of the mobile market. During this period, IT became consumerized for laypeople, with glossy apps and impressively intuitive experiences. He recalls a general loss of faith in IT staff, as workers often had “better tech at home than they did in the office.” This drove business leaders to invest heavily in modernizing their companies.

    In the following years, cloud solutions quickly re-empowered IT with new computing models, emboldening them to compete using the same tools as tech companies. However, simple deployments using a single server quickly morphed into arranging multiple workloads on various cloud service providers (CSPs). Virtualization, serverless and microservices architectures also brought novel complexities into the stack.

    “The IT staff is being asked to do jobs they’ve never done before,” Ostrowski said. He explained that SREs, for example, must understand networking, infrastructure and security — a vast portfolio for a single person and role. Supporting many disparate paradigms is simply beyond the scope and scale of what a single person can do, meaning new automation must be constructed — because “if you’re too busy debugging, you can’t innovate,” says Ostrowski.

    Amid mounting complexity and the burden of rising cloud costs, it appears business leaders again have a role in directing and prioritizing technological efforts.

    Getting Busy With BizDevSecOps

    According to Ostrowski, connecting IT and business with BizDevSecOps all hinges on collaboration. “If you don’t get to a point where you can collaborate with all these pillars, you’ll degrade your business,” said Ostrowski.

    BizDevSecOps also could help connect the dots to comprehend anomalies. For example, suppose a commerce application is experiencing a 15% conversion rate, but it drops to 7% after an upgrade. In this scenario, collaboration is crucial to identify usability bottlenecks in production and adjust accordingly.

    Tracking business outcomes can align development around improving the user experience. If broken features are hurting conversion rates, all stakeholders need to know to adjust accordingly. “User experience is the golden gem,” said Ostrowski.

    Other benefits of a BizDevSecOps approach may include:

    • Correlating activity and revenue: Ensuring spikes of activity are associated with revenue generation and not attacks or faulty instances.
    • Workload optimization: Monitoring business outcomes can help adjust the scope and size of machines as needed.
    • Before and after: Comparing financial results before and after migrations, new versions or new feature additions.
    • Postmortems: Pinpoint and correlate data when conducting postmortems.
    • Progressive delivery: A more rapid release frequency helps a business retain agility and pivot when needed.

    Visibility Enables BizDevSecOps

    DevSecOps is now a common philosophy — it promotes development with security baked into the application. Now, BizDevSecOps could be the next iteration; a collaborative approach that considers additional perspectives. BizDevSecOps is a vital method to “continue to build trust and collaboration so everyone has a seat at the table,” said Ostrowski.

    Ninety-six percent of technologists agreed that monitoring the entire IT stack to connect technical performance to business outcomes will be important in 2021, the Agents of Transformation Report found. To enable this, business, security and development must inevitably de-silo. According to Ostrowski, adopting BizDevSecOps depends on a window into performance management and business intelligence, because “when changes happen and no one knows about it, it’s a serious problem,” he added.