DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Related

  • Stop Using the ATM-Didn’t-Kill-Jobs Story to Reassure Developers About AI
  • The 7 Pillars of Meeting Design: Transforming Expensive Conversations into Decision Assets
  • How AI Is Transforming Software Engineering and How Developers Can Take Advantage
  • When AI Crashes: Classifying Failure Modes in Safety-Critical Software

Trending

  • Real-Time Risk Signals for AI Agent Authorization
  • Rethinking Java Design Patterns: From OOP to FP
  • How to Build Living AI Coding Assistants With Quarkus Agent MCP
  • The Tectonic AI Platform: A Framework for Taming App Sprawl and Data Fragmentation

The Democratization of Development in the Enterprise

Learn how the democratization of development tends to play out when it comes to generating and delivering business value.

By 
Tim Johnson user avatar
Tim Johnson
·
Jul. 23, 21 · Opinion
Likes (2)
Comment
Save
Tweet
Share
2.7K Views

Join the DZone community and get the full member experience.

Join For Free

The software development process has been opening up to non-engineers through concepts like low-code and no-code, ushering in the age of the democratization of development. The people involved in making software are changing — anyone with an Internet connection can build an application, even without programming knowledge.

Plenty has been written about the implications for individuals. But what does this overarching trend mean for businesses? How does the democratization of development tend to play out when it comes to generating and delivering business value? And what does it look like at an enterprise level?

We’ll explore those questions in this article. Before we get started, though, let’s get clear on what the concept really is, and what it isn’t.

Mythbusting: the Democratization of Development

We need to put a few preconceptions to rest. Coders will not be automated out of existence. Non-coders will not transform overnight into coders, and they won’t be expected to code, either. Traditional coders are not going to be required to move to more abstract tools like low-code/no-code. Given the growing necessity to secure the software supply chain and ensure all aspects of software delivery are auditable and compliant, it’s much more likely that low-code/no-code and traditional software development will coexist—each contributing to software delivery pipelines as appropriate to their roles.

What’s really changing is who’s involved with defining, creating and delivering value. As software becomes the primary component for delivering value through an organization (which we’ll get into later), more people are going to get involved in the software development process. It’s no longer solely the engineers’ domain. 

Organizational Shifts

And it’s not just the pipeline that’s transforming, either. Organizations have to rethink decisions on what they’re going to deliver, how to prioritize what they deliver, what to expect in return, who’s responsible, and so on. They also have to figure out how to optimize resources in changing circumstances, as well as how to be compliant with high-stakes regulations and standards. All these types of considerations have to be rejiggered and reorganized as development processes join together and evolve. 

Software = Business Value

There’s an old saying that IT doesn’t understand the business it’s in, and the business doesn’t understand what IT does. That’s probably still the case to an extent in many places, but things are changing. The business side is becoming more of a peer in the software development process because software delivery is now so integral to the success of the business. Software delivery is now a critical component of business value—the two “sides” are now on the same side. So how can they work together better?

They need some sort of Rosetta Stone or Star Trek Universal Translator. They need a way to communicate their priorities and key metrics to help each other understand how they’re making a difference in the business, so they can align and make decisions as one. From where I’m standing, that “Universal Translator” tool is value stream management.

Value stream management tracks the flow of value through a business. It forces the technical people and the business people to get together and agree on what things mean and what’s important. Value stream management (VSM) tools and techniques help technical people translate their work into concepts the business can understand and use. On the reverse, VSM also helps the business folks frame their concerns to the highly technical folks.

Right now, there are a number of tools on the market designed to give the business visibility into the technology. That’s the first step—the business gets the visibility and analytics to make decisions. The next step is to have the control and automation in place to execute those decisions.  This will open the door for the business being brought into software development in a more hands-on way, as true equals in the process. Different departments and different types of users are empowered to contribute to building software — and therefore, are empowered to generate business value. 

And in essence, that’s what value stream management is. It’s the democratization of business value in a software-driven world. It allows the business to get directly involved in what the company produces—and with software tied so closely to business value, it’s essential for this group to have a say. The democratization of development in the enterprise helps lay the groundwork for value stream management, the most promising effort I’ve seen to bring a common vantage point to business and IT.

Software development

Published at DZone with permission of Tim Johnson. See the original article here.

Opinions expressed by DZone contributors are their own.

Related

  • Stop Using the ATM-Didn’t-Kill-Jobs Story to Reassure Developers About AI
  • The 7 Pillars of Meeting Design: Transforming Expensive Conversations into Decision Assets
  • How AI Is Transforming Software Engineering and How Developers Can Take Advantage
  • When AI Crashes: Classifying Failure Modes in Safety-Critical Software

Partner Resources

×

Comments

The likes didn't load as expected. Please refresh the page and try again.

  • RSS
  • X
  • Facebook

ABOUT US

  • About DZone
  • Support and feedback
  • Community research

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 215
  • Nashville, TN 37211
  • [email protected]

Let's be friends:

  • RSS
  • X
  • Facebook