Share

Reposted from Medium

When Node.js was first released in 2009, nobody could have foreseen how high, far and fast it would succeed in capturing the imagination of software developers and application architects. But in the years that followed Node’s introduction we’ve seen a rapid advancement of development infrastructure and tooling, DevOps and deployment processes, and the refined organizational roles that surround the evolving Node open source project itself.

As a company whose mission it is to bring Node to the enterprise and vice versa, NodeSource has developed a method of tracking an organization’s progress with Node along the familiar axes of People, Process and Technology. The resulting model is called the Node Maturity Curve which we recently introduced in our State of Node for the Enterprise paper.

The Node Maturity Curve™

It is important to note that a maturity curve, as applied to Node in particular, may not reflect a serial process along all stages of the curve. Each stage is managed and sequenced differently for every organization and the progress realized can vary greatly from company to company.

For example, early-stage, born-of-the-web companies have the advantage of not having to drag forward legacy tech. This allows them to rapidly reach a high level of maturity with Node.js because if they don’t their chances of survival, let alone success, are slim. Established enterprises have existing investments in legacy tech and entrenched organizational behaviors so they are naturally better able to withstand some experimentation and a slower maturing process with Node. We’ve dealt with both of these scenarios.

The Node Maturity Curve is simply a means to apply the experience we’ve had with our many production customers to a continuum of increasing Node sophistication across people, process and technology.

Let’s take a quick look at each stage.

Labs

Node.js enters enterprise IT organizations in any number of ways. Often, a web development team that is proficient in JavaScript hears about an elegant solution for a server-side problem that Node offers. They are quickly able to extend their JavaScript skills to the application backend and suddenly they are newly empowered as full-stack, frontend-to-backend developers.

Others go through a more rigorous and structured vetting process and then slowly but surely migrate legacy applications. Either way, a modest lab or developer sandbox is the initial way that Node is introduced. NodeSource engineers have worked with many different development and operations teams to create early success with Node in a Lab environment. We then help train them to maximize Node benefits like speeding time to market for new applications and constructing the type of organization and processes needed to sustain success and self-sufficiency with Node.

People

Reaching high levels of maturity with your people is not just achieving an optimal headcount number. Your development team matures as it successfully adapts to the particular strengths of Node: asynchronous programming, module-driven development, and package management, among others. Also, their ability to embrace the rapidly expanding factors of the open source model — and the Node.js community in particular — is a telling sign of where your people are on their Node journey.

In terms of the relative Node maturity of an IT organization, we look to see if Node champions are identified, if a training regimen is established, if staff augmentation or consultative resources are planned, and if executive buy-in is in place for Node.js to flourish.

Process

Any professional development, DevOps or IT operations team will have mature processes in place to accomplish their goals. Identifying the net-new processes for Node.js focuses on the blurred lines between frontend and backend teams. New definitions and standards must be created for resource ownership and management while embracing external tools and services such as npm and GitHub will offer some significant challenges to business-as-usual. The tweaking of agile development practices, developer collaboration, change management and even IT/operations culture is a delicate thing to orchestrate. NodeSource can provide some real-world perspective on navigating through these types of changes based upon our experience at the customer site.

The end goal of evolving internal processes is to establish Node as a peer platform to existing legacy environments like Java and .NET — always asking and answering the question: how far and how fast can we take Node in our organization?

Technology

Ironically, technology is the least flexible of resources. The commitment to a new language, IDE or framework causes much hand wringing for development leads. The good news is that Node is especially conducive to starting with an existing framework like Express, Hapi or Restify and then adapting and evolving that framework to best fit your current model.

The technology decisions that are essential to get right are your package management solution (usually npm), your runtime (Node.js version, product support, performance management, scale) and your application infrastructure (Linux distribution, cloud provider, et al.).

Plotting the Node Maturity Curve

With the Node.js platform and community moving so quickly, the Node Maturity Curve will need to evolve along with Node itself. However, we think it is useful to build out the curve to reflect the next 12 to 18 months and to continually add detail and substance to the model. It helps NodeSource strategize about our product designs, release schedules and service offerings. It also helps us set useful expectations and goals for our customers and the Node.js community at large.

So, in the near future we will be diving a bit deeper into the model along each major axis: people, process and technology. We’ll also consider the key characteristics of successfully bootstrapping a Node program. Keep an eye out for “Plotting People along the Node Maturity”, the next in this series.