by !! Introduction
Well, as I promised in my first installment, here’s the very beginning of an overview of why USENIX and newSAGE/LOPSA are complementary, probably need each other, yet cannot remain a single organization. Remember that this isn’t about right and wrong, or competition, or past mistakes. It’s just about differences in communities, services and goals.
There are lots of reasons that USENIX and newSAGE (LOPSA) had to eventually split, but the most important are:
* the continuum of research to operations – different communities
* trends in computer science, “Information Technology” and how USENIX and SAGE evolved in response to these trends
* incompatible goals of each organization – the need to serve different communities
In this entry, I want to concentrate on the different communities that are served by USENIX and LOPSA. Yes, there are some stereotypes here, but almost all of you will be able to determine very easily in which of these communities that you (and the people you know) belong. Most people are in multiple communities at different times in their careers, or even as they serve different roles in their work. Don’t get hung up on the details, just look at the broad brush strokes…
!! Research to Operations – Different Communities
In every field there is a progression over time of advancement that leads from research through development to widespread deployment and operations. The best, most obvious example of this is the Internet. From a few government research sites connected with hand-built hardware, we’ve come to online pizza ordering, grandmothers becoming Ebay entrepreneurs, online games, and literally computers in almost every classroom.
So, as a technology matures, it becomes more prevalent, more reliable,and there’s a greater dependency on it. This also means that people move beyond just being amazed that the technology even works, to expecting it to be there 24×7 anywhere they may be.
The community in a field also splits over time. You end up with a stratification of people, ranging from those performing “pure research” down to those who keep the lights on. You need all these people, none are more important than the others. All depend on each other, but they are distinct communities. You don’t need the same numbers of each group, and they have different responsibilities and education requirements. They also have different needs.
You get a pyramid that looks something like this:
|>
The width of the triangle at any point is a rough approximation of the number of people in that role. As you move towards the top of the triangle, there are fewer people, typically with longer or more involved education and training requirements. As you move down the pyramid, you have more people, with different education needs, and you are closer to deployed infrastructure.
! “Pure” Research
“Pure” research folks (the original Bell Labs, MITRE, Cerias, many Graduate Universities) are working on the things that the field will need in 5-10 years. They are thinking “outside the box”, and hopefully they’re already thinking about the hard problems that we’ll be facing over the next decade. If we’re really lucky, they’re also thinking about societal impact, but that’s another issue.
These are really smart people, but you don’t want to call Bell Labs when your lights go out, or Cerias when your firewall is being probed. You do not want a research cardiologist doing your triple bypass, either.
This is a smaller community, it takes longer to enter (longer education, maybe a Ph.D.), but they have a lot of long-term leverage. Don’t expect them to solve the problems today, but when you do get a solution, it’ll be a ”’good”’ one.
! Development
More smart folks, but this time thinking about how to develop that “blue sky” technology into something that can actually be built. They plan to use today’s (or maybe tomorrow’s) technology. That’s why this is development. Sometimes this is “R&D”, “applied research”, or “product development”, but these people aren’t inventing transistors, they’re thinking of ways to use them in the real world, or how to make them affordable.
There’s often some overlap with both the research and engineering communities, but don’t call the development folks to think about faster-than-light travel, or new information theory, or a completely new theory of computer security. But, if you actually give them any of these things they’ll figure out how to turn it into a product or machine or piece of software. They care about building your network backbone and they’ll try to give you the tools to do it, but they don’t provision circuits, order racks of servers or lease co-location facilities.
This community is larger than the “pure research” one, usually has different education requirements, or might require slightly less experience. But this is closer to the real world, too.
! Engineering
These are the people who design (and sometimes build) things. Whether it’s network infrastructure to sell widgets to 3 million people, a bridge or a new car, these people are working with available technology to solve some specific problems, to meets some customer’s requirements. Oh, and on-time and within budget.
Don’t ask them to create (or use!) a completely new steel alloy to build a bridge, or use some completely untested technology in some life-critical medical device. These folks take the best tech and solve problems. They don’t ”’do”’ risk, and they rarely use the bleeding edge tech. They want to ”’build”’ (design, really) things with what’s available ”’today”’.
Engineers still require a lot of education, and it takes a few years before they have the experience to really hit their stride, but you usually have more of them than the research or development communities.
But engineers don’t pour concrete and they don’t do road maintenance. They ususally don’t install servers, but they’ll tell you how many and what kind and where to put them.
Once the problem is solved (the solution is designed, or prototyped), they may hand it over to someone else to build, install and in general provide day-to-day care…
! Operations
Once your technology or solution is designed and ready for deployment, is deployed and in use by the customers, it requires some ongoing maintenance, and often, some repair. Building and maintaining all this infrastructure is Operations.
The people who keep the power coming out of the wall, the packets flowing through the Net, and water coming out of your tap are Operations. They didn’t do the pure research to create a new kind of copper alloy for power transmission lines, they didn’t develop new generator designs, and they didn’t engineer the grid, but they know how to monitor, diagnose and repair all this wonderful stuff.
This community is often characterized or stereotyped by “years of experience” and “grizzled veterans”. What they know they oftren learned the hard way, by doing. They learned from real world experience, their own and others’. They understand the technology in a deeply personal way, they way it is in the real world, not the way it was designed, or sold by Marketing, or purchased by Management.
These are usually the most risk-averse people you’ve never met. They don’t want researchy things; they want their tech
“fully baked” so that installation is actually possible, because people depend on it, and when it breaks, they’re the ones who get paged at 3am to fix it.
When a hurricane takes out your power, it’s Operations that sends linemen to work 24 hours a day until your lights come back on.
! Communities – Summary
These four stereotypical communities work together to dream, design, deploy and maintain all this “stuff” that we depend on. No single one can invent all the stuff we need, deploy it or keep it running. They are all complementary to each other, and we need them all.
And we never have enough skilled people in any of these communities to get all the work done, either.
In the next installment, I’ll talk about where USENIX, SAGE and LOPSA came from, why each exists, and why everything is changing…