Core and periphery

Software systems are among the most complex of the artifacts that our species creates. In the design, use, and evolution of such systems, a dynamic tension exists between what I have come to call the core and the periphery. Some examples of cores include the Windows and Unix kernels, the Java and Perl virtual machines, the browser, and the XML 1.0 specification. Some corresponding peripheries include the Win32 and BSD interfaces, Java's classes and Perl's CPAN (Comprehensive Perl Archive Network), browser plug-ins, and XPath, XSLT (eXtensible Stylesheet Language Transformation), and SOAP. Of course, today's periphery becomes tomorrow's core as we ride an upward spiral of abstraction. Fewer programmers write to the Win32 interface; more choose the higher-level vistas afforded first by Visual Basic and now the .Net Framework. SOAP is also receding into the woodwork as business process choreography comes into focus.

It's hard to decide what should be pushed into the core and what should be pushed to the periphery. We know, in a general way, what the trade-offs are. The core defines a universe of certainty. You can pretty much count on the fact that a browser will read an HTML document. The periphery defines a universe of possibility. A browser can acquire the plug-ins it needs to read PDF files or play Flash animations. But even though these are two of the most widely deployed plug-ins, they are not the browser's core features.

Our decisions on what to put in or leave out have powerful and long-lasting effects, both positive and negative. A well-defined and stable core with an organically growing periphery is the sine qua non of a healthy software system, one that's used by lots of people for a long time. Over that time, though, as the upward spiral progresses, those boundaries must, as we've seen, be constantly explored and redrawn. So the partitioning that serves us so well can also become an evolutionary ball and chain.

Successful evolution can't simply be a matter of choosing the right boundary because that's a moving target. Even at a given point in time, there are many ways to draw the "right" boundaries. Linux, for example, is a so-called monolithic system. It shunned the microkernel architecture that became fashionable years ago, yet it enjoys wild success. And while Windows and Mac OS X embrace the microkernel approach, nobody calls that the key to their success. In all these cases, other kinds of boundaries are being drawn, and other balances struck.

There's no easy answer here, but I do have a hunch about what works best. Many years ago, I worked for a company that built its own virtual machine (based on Lisp), and built applications on top of that VM. The membrane that separated the core (the VM) from the periphery (the applications) was permeable in both directions. Sometimes the VM guys would get bogged down in things that could more easily be handled in the application layer -- where I was working -- so we'd push those things out of the kernel. But sometimes I'd get bogged down in things that could more efficiently be handled in the kernel, so we'd push those things in. The upward spiral progressed, as upward spirals always do, in fits and starts. But it did progress nicely, in part because we were able to stretch the boundary in both directions.

It's vital to separate the core from the periphery. But it's equally vital to connect these realms -- and the very different kinds of people who inhabit them -- with elastic bands.