What Enterprise Architects and Time Travelers have in Common

Note: This post was inspired by Manfred's post "You don't do repository driven development? Where have you been?". It immediately made me think of Star Trek...

When I roll up to a new client in desperate need of build help, there's always a chance I'll have a "Scotty moment" - a moment when I pick up the mouse and attempt to ask an Apple II to synthesize transparent Aluminum. ("Computer, bring up the repository and scan for vulnerabilities.") If you don't get the reference, I'll walk you over to IMDB and point you towards the movie Star Trek IV. In Star Trek IV, James T. Kirk and company travel back in time to 1986 in a "bird of prey" to rescue a humpback whale which is being summoned by a mysterious alien probe in the year 2286. Leonard Nimoy directed Star Trek IV and it had a comedic "fish out of water" feeling to it that made it appeal to a wider audience.

The crew of the Starship Enterprise is thrown into a 1986 San Francisco and if you haven't seen the movie, you can imagine that the plot was a series of "future meets past" vignettes. So, let's go back to this scene where Scotty shows up at a materials factory. Scotty and Bones need to fabricate several tons of transparent aluminum - the container for the to-be-rescued whale. They have some discussion about the pros and cons of giving this engineer a recipe from the future for transparent metal.

It only took real scientists 23 years to catch-up with science fiction. A group of scientists succeeded in turning metal transparent during research in 2012 to create quantum computers.

What does this have to do with Repository Managers?

Right, right, I almost forgot that you are here to learn about Nexus or something like that. Back to reality...

While I'm certainly not giving corporations recipes for game-changing transparent aluminium, I'm very often walking into enterprises that have no idea what they've been missing because they've been "out of the game" for about a decade.

You see, "enterprise architects" at very serious organizations often work on applications that have a decade long life cycle. When your critical banking application has been alive for 10 years, it's very likely that you haven't changed much in that interval. For example, I just heard of one company that wanted help migrating to Maven 3.... we can do that, but wait, they are using a heavily customized Maven 1 build (with Jelly, yikes). Moving from Maven 2 to Maven 3, no problem. Moving from Maven 1 to Maven 3, now that's like going back in time to rescue a humpback whale.

You see enterprise architects and developers - they might only come up for air once a decade, and the rate of technology adoption is all over the map. Companies like Google and Facebook are far ahead of the curve updating a development stack every year. Yet, in other companies, say a large insurance company, it isn't a priority to update technology more often than is absolutely necessary. In those companies, you might still be running some Cobol or a system on a very early version of the JDK. Teaching a training class at a company like that is surprising - they might not even know what Central is yet.

When you roll up to these places and start explaining the benefits of repository managers. You start by talking about dependency management... Client: "what's a dependency?" You realize you have to go further back into the past. You: "Ok, do you guys have a CI server?" Client: "What's CI?"... then you go even further... You: "Ok, do you use Ant or Maven?" Client: "Neither of those were available in 1999, we use gmake." That's when you realize you've crossed into the deep past, your job is no longer to guide people through an easy transition, that's when you need to just dive right into delivering future tech.

Need to transport a humpback whale to 2286? I'll give you the recipe for Nexus.

At this point, at these clients, it would take several days to run through the progression of the industry. These people have missed Agile, web applications, build tools, dependency management, repositories, the rise of dynamic languages atop the JVM, etc. You don't have time to to run long seminars on how the application lifecycle has changed, what open source did to the industry, and how the nature of corporate development has shifted to smaller groups collaborating with one another using methods of communication inspired by open source projects.

Instead you just have to give them the recipe for the future. And, to me, that's Nexus. Nexus, and repository managers more generally, this is the technology that enables software development at scale. In the late 90s, large software projects were monolithic. You checked out the entire codebase, ran a multi-hour build and hoped it worked. Teams were large and the reality of software in the 90s is that you couldn't scale beyond a certain size (both team size and code complexity) without incurring massive management inefficiency.

With the rise of Maven Central and the ability to effortlessly distribute components, software applications have been much more modular and component-driven. When you assemble a modern web application in 2012, you already have a pre-made "warp core" in the form of the Spring Framework, and you can just add on fully tested "transporter room" in the form of MyBatis. As systems become more interoperable and more complex, component-driven development is the only way we're going to achieve computing systems of complex.

Did you know that Sonatype's Building the Starship Enterprise?

Just look at science fiction, and think about the software complexity of something like the Starship Enterprise. Do you think we're going to get there by building bigger monolithic projects? Do you think we're going to get there by building thousands of software projects each with uniquely difficult builds? Nope. Large scale technology projects are only possible if you break a system into isolated components and use some mechanism to manage and distribute those components.

This is what a repository manager does. It enables technology at scale, and once we've all understood this we can start building the next generation of applications and stop reinventing the wheel every time someone decides to reinvent a new way to distribute software.

Anyone have any Spock ears?

Ok, so this post has been 80% hand-waving and 20% telling you that Nexus is the answer. Maybe I've made my point using a bit too much grandiosity, but I'll leave you with this...

When someone asks why Nexus is important, I answer: "Look at Star Trek. Do you think they manage all those systems with an Ant build and a bunch of WAR files deployed to Tomcat? No. Have you ever heard Sulu going on and on about some crappy Bash script that failed to update the software for the Friday patch? No. They don't have problems because the Federation standardized on Sonatype Nexus in 2215. The Holodeck software, the transporter room management console, the phaser charging subsystem.... all of those are components and they use Nexus to both distribute software and scan it for Federation CVE vulnerabilities. You should see what we did in the holodeck for Nexus training, it's intense."

Start working on the future today, and go download Nexus. Also, does anyone have any Spock ears? I'm going to be Spock for Halloween.