Toward the middle of May, Computer Society presidents start preparing for a major Board of Governors meeting in June. It’s a large job and requires me to write the agenda and get the members ready for the meeting. Since the society is run by professors of computer science or software engineers, most of the members have little experience with Boards of Governors or how they make decisions. Many assume that the board is the absolute authority for the society and can make any decision that it wants to make. In fact, it makes only certain kinds of decisions because the society organizes its decisions in layers, in much the same way that we organize software or hardware in layers.

Let’s start with a quick overview of the society so that we can see how it operates. I’m going to make a few simplifications to the process because the society is actually part of the larger organization IEEE. However, the basic principles still apply.

The IEEE Computer Society is a nonprofit organization. All of its assets are managed by the Board of Governors. (If the Computer Society were an independent organization, it would also own the assets of the Computer Society. However, those assets are actually owned by IEEE.) The Board is responsible to make sure that those assets are used well. To meet this goal, the Board generally makes only four kinds of decisions. First, it can create new entities within the society. Second, it can write the rules that describe how those entities work. Third, it can approve a budget, which gives money to entities within the society. Finally, it can appoint members of the society to leadership positions.

The Board of Governors makes only certain kinds of decisions is because the society is organized in a way that separates technical issues from political issues. Most of our members work on technical issues. We want to make sure that they answer technical questions with technically sound answers that are free from any kind of political influence. By political influence, we mean the kind of politics that occurs in science, which is not usually the same kind of politics that you find in nations. We don’t want the society to approve a conference because the organizer is a friend of the society President, or approve a paper because the author went to the same school as the journal editor, or create a standard because a company has made a donation to the society. Our reputation, like that of any technical organization, depends on the fact that when our members make technical decisions, they do so for good technical reasons.

Of course, the Computer Society is not free from politics. No organization of human beings is free of politics. However, we adopt a layered structure to try to isolate political issues and keep them away from technical issues. This layered structure is much like the layered structure of the (OSI) Protocol Stack.

OSI stack was developed in the late 1970s and early 1980s to simplify data communications and to isolate certain kinds of activities. (It was first published in 1984). It has seven layers. The first layer, the Physical Layer, deals only with the issues of the physical connections on the network, the problems of putting bits on a wire or a fiber optic cable. When you work in this layer, you don’t worry about the meaning of the bits, you just get them to enter one site of a cable and come out the other. The top layer, Layer 7, deals with application programs. In that layer, engineers would be concerned only with the nature of the application. They would not worry about how data gets from one program to another.

Between layers one and seven, the OSI has five other steps. If we start at the bottom, each step moves one step further away from the physical network and one step closer to the abstractions of an application. Those steps begin with

Physical Layer: Signals on cables, etc; and then move to:

• Data Link Layer: How bits are organizations into structures on the net;
• Network Layer: How data structures are routed from one point on the network to another;
• Transport Layer: Ensures that all data is correct when it reaches the end of its journey;
• Session Layer: Handles how you create and terminate a communications session;
• Presentation Layer: Determines how to interpret the bits as ASCII code or a .pdf file, or some other entity,and finally;
• Application Layer:determines how applications deal with data on the network.

Many know the details of the OSI stack well and also know the little secret about it. The OSI stack does not correspond to how we have developed software for network communications. We generally identify Layer 3 with the IP protocol and Layer 4 with the TCP protocol. However, these identifications are not perfect. Both protocols bleed into other layers. I often find that students are quite upset when they discover that we are using a model that does exactly correspond with current software. However, I try to help them understand that the OSI Stack illustrates a fundamental principle of computer science. That principle demands that we build complicated programs by isolating details in layers.

We generally trace the idea of building computer systems in layers back to a 1967 paper that the Dutch computer scientist Edsger Dijkstra gave to a joint IEEE Computer Society/ACM conference. Prior to this paper, engineers had struggled with the problem of how to organize software. If you look at early examples of programs, and you can find many in the electronic library of the Computer Society, you will find that most code of that era is complicated, difficult to read, hard to modify, and challenging to reuse. In his 1967 paper, Dijkstra described how software could be constructed in layers and gave an example of a simple operating system that used five layers. He admitted that this system might not be a realistic test of his ideas but he argued that the “larger the project, the more essential the structuring!”

The idea of using layers to control complexity has become a mainstay of software architecture. We see it in many forms and apply it to many problems. We see it in the hierarchy of classes in object-oriented programming and in the structure of Service-Oriented Architecture.

SOA is a relatively recent application of layering in computer science. It was articulated in 2007 as a means of controlling complexity in business systems, especially distributed systems that make substantial use of the Internet. Like Dijkstra’s plan for system development, its layering system is called the SOA Solution Stack or S3. The S3’s nine layers are: 1) operational systems, 2) service components, 3) services, 4) business processes, 5) consumer actions, 6) system integration, 7) quality control and assurance, 8) information architecture, and 9) system governance and policies.

Like the layers of the OSI stack, the layers of S3 are not perfect. Real systems can easily straddle two of the layers. Furthermore, researchers have had to add units, such as one for business rules, that cut across all the SOA layers. Still, they provide a reasonable tool for organizing complex systems. A quick survey of the recent Computer Society Digital Library shows that the ideas of SOA and S3 are being applied quite creatively in China. In the last year, the society has published articles on using these layering ideas for Chinese manufacturing systems, oceanographic information systems, and multimedia systems.

However, as I noted at the start of the paper, we may be able to best understand layering by seeing how it is applied in the operations of the Computer Society to separate the technical from the political. In our publications, we give our editors in chief broad powers to make decisions about which articles are technically appropriate for their periodicals, which are done correctly, and which have technical value. The editor in chief gets technical advice from an editorial board and reviewers. However, the editor in chief has the final judgment over technical matters.

Still, the editors in chief work in a stack of three layers. Above the editors is the Publications Board. Every two years, the Publications Board reviews each periodical and determines if the periodical is being well run. This decision is partially political and partially technical. First, they determine if the editors in chief are running the periodical well. They check to see that the journal has enough submissions, that the reviewing is being done promptly, and that the time to publication is not too long. Next they get into the technical details of the periodical and try to determine if the editors have been accepting papers for sound technical reasons. However, they don’t do all the technical work that the editors can do. For example, the Publications Board cannot accept papers that the Editors have made on defensible technical reasons.

Finally, the Publications Board reports to the Board of Governors, which makes purely political decisions. They take information from the Publications Board and ask how to best utilize the resources of the Computer Society for publishing technical information. Since the resources of the society are limited, as those of all societies are, they have to make tough decisions.

A few years ago, they decided to sell a periodical. Technically, the periodical was fine and the editor was making good decisions. However, the Board of Governors decided that the society did not have enough members who were interested in the periodical and so they decided to sell it.

More recently, the Board of Governors has decided to start a new magazine for cloud computing. We already have a sample version of the magazine in circulation. It is accepting submissions and will start regular publication in January 2014. One of the fields that is contributing to Cloud Computing is service-oriented computing, which is already covered by a Society journal. However, in the new cloud magazine, I expect to see plenty of applications that will use layering to control complexity and separate technical details from operational activities. This is a fundamental principle of computer science and computer engineering. We even use it to help govern the Computer Society.

About David Alan Grier

David Alan Grier is a writer and scholar on computing technologies and was President of the IEEE Computer Society in 2013. He writes for Computer magazine. You can find videos of his writings at video.dagrier.net. He has served as editor in chief of IEEE Annals of the History of Computing, as chair of the Magazine Operations Committee and as an editorial board member of Computer. Grier formerly wrote the monthly column “The Known World.” He is an associate professor of science and technology policy at George Washington University in Washington, DC, with a particular interest in policy regarding digital technology and professional societies. He can be reached at grier@computer.org.