With more than 40 years of experience in standardization, Jean Bérubé has participated in dozens of committees and witnessed firsthand the evolution of standards for systems management and information and communications technologies. His leadership of Canadian committees, including more than 25 years as the head of the Canadian delegation to the International Organization for Standardization and the International Electrotechnical Commission’s Joint Technical Committee 1 Sub-Committee 7 on Systems and Software Engineering (ISO/IEC JTC 1 SC 7 – Systems and Software Engineering), has provided tremendous value to Canada and the international standardization system. In late 2018, the Standards Council of Canada (SCC) presented Mr. Bérubé with a certificate of recognition and sat down with him to discuss his impressive résumé and the importance of standards.
You have an extensive history in the international standardization system. Can you tell me about what initially prompted you to get involved in standardization?
I started working on standards after seeing an SCC notice in a trade journal, Computer World or something, which was seeking someone to work on a standard for the programming language PL/I. That was in 1976, and I had one of the few PL/I shops in Montreal, so I responded to the notice.
When I went to my first standards committee meeting I was impressed by the way the chair of the programming language group — it was Robert (Bob) Kearney at that time—managed the meeting. I think I hit the jackpot there. Bob Kearney actually became president of Bell Canada, so he had some natural talents. But that’s what got me interested in participating—I thought the committee was well-organized, and the topic was interesting.
So I was interested in the domain, and I found that standards are a good mechanism for sharing and acquiring knowledge. Going to standards meetings, for me, is like going to a conference or seminar. It puts my brain in a different gear for one week, discussing things with people who have good ideas and—more often than not —who are brighter than me and articulate.
The choice of committees in which I participated was not only motivated by my personal interest, but by my work at the time. I was an employee of an insurance company until 1980, when I started consulting. I was in a consulting company until 1990, and since then I’ve been on my own as a consultant. I’ve done well, and participating in standardization has been very beneficial.
I also got involved in doing administrative work and management work in standards. I have always liked to organize the work of people, and to facilitate the work of other people.
Why is standardization so important?
Naturally, standards by themselves are important, and there are many reasons why you would want to be involved in standards. For me, a standard specifies something on which there is a consensus, and I kind of like both the specification part and the consensus part.
This is a view different from that of university professors, for instance. When they publish papers, it’s the nature of their work that they have to describe something new and differentiate it from the work of others. If they say, “I agree with my esteemed colleague about this,” they won’t get anywhere. They have to disagree. It’s the same thing with commercial products, where corporations sell something of their own—not something based on consensus. In standards work there’s been a forced consensus, in a sense, so I feel it’s more reliable.
Standards are important for all the typical reasons—reliability, interoperability, consumer protection, trade—but I’m more on the knowledge side of standards than the certification side. Initially I worked on standards for things such as programming languages. However, a process standard – such as one that outlines the requirements to follow before coding even takes place – is developed for a human being to follow. Programming human beings is somewhat more difficult than programming computers
Most SC7 standards define processes, but we also have standards for human resources, such as qualifications for systems engineers. Those standards get slowly and surely integrated into university curriculum for teaching, because systems and software engineering is somewhat distinctive. There are very few places where it is taught in university. In civil engineering, the process of how to build bridges is taught at university, and the standards applying to concrete and all these things are well-established standards. But for software engineering and systems engineering, it’s not like that; it’s a new discipline, and we’re learning while we’re doing it.
How did your initial involvement expand to cover the range of committees to which you have contributed in your 40 years of standards work?
I seem to have been hopping from one committee to another, but there is a common denominator to my activities.
Like I said, I started in 1976 in programming languages. I worked on PL/I, then I worked on Ada (which is another programming language). Then I worked on operating systems and command languages, again in the language area.
After that, I discovered that there was a committee devoted to database languages and data management, which is now SC 32 [ISO/IEC JTC 1/SC 32 – Data management and interchange]. In software systems engineering, if you want to develop a system, you need to develop a programming language, for which you have databases. I also discovered that data management standards are not only related to database languages, but that there was also some work developing metadata-type standards for dictionaries and other things connected with the system. So I started working on that in 1986, and I remained active in that group for about 10 years, until 1997. It complemented the work I was doing in SC 7 in modelling languages.
When JTC 1 came along I got involved in SC 7, which was closer to my line of work at the time as a consultant for a company that sold system development methodologies and tools. During that period, SC7 went from 4 standards to more than 100. One characteristic of SC7 is that it has extensive collaboration with other groups and consortia, such as IEEE, OMG, ITU and INCOSE.
I also monitored many other groups. For instance, systems management was a working group in SC 7, and later moved to its own sub-committee, SC 40 [ISO/IEC JTC 1/SC 40 – IT Service Management and IT Governance]. But in SC 7, we were already working on some standards about service delivery, so I kept some contact with that. Same thing with SC 38 [ISO/IEC JTC 1/SC 38 – Cloud Computing and Distributed Platforms]. I kept monitoring that committee because of its focus on service-oriented architecture and portability, which was relevant to my work. But in those groups I mostly monitored and produced comments.
Finally, because of my current work at the Canada Border Services Agency - where I was hired to be the enterprise architect for security and privacy—I have become interested in security standards and privacy standards. So I’ve registered on a couple of committees, and I’m probably going to become more active in that area once I’m more comfortable.
So that’s my history, in terms of standards work, but I also got involved in management. In 1987, I became the chair of the Canadian Mirror Committee to SC 7 three months after the group was formed.
I enjoyed that work, to be honest. Early in my career, I had the choice of going into management or going into technical work. I’d selected technical work, but the experience I gained doing management work in standards was good in the sense that you don’t have formal authority; you have to convince people. You need to manage projects with volunteers, and more often than not, I found I had more success having volunteers do the work than my own employees, because their level of interest was higher. I was also able to gain some skills in getting things done in that environment.
I also like administrative work. I’m a strange kind of guy who likes to get libraries organized and have documents filed in the proper places, as well as produce templates so that everyone can do documents the same way. So almost by default, I became secretary of many of my groups, or set up the infrastructure and turned it over to the secretary later. Naturally, everybody says that my sites are overly structured and organized, but I’ve never complained about SiteScape or about using a library system.
I also like how, being secretary of a group, you have the power of the pen when you write the minutes. You’re aware of what happens, and you can organize things in such a way that they are clear and people understand what they have to do.
What have you gained as a result of your contributions to international standardization?
There are some things I learned while doing management work that I wouldn’t have learned otherwise, such as dealing with politics and getting consensus. Canada is generally kind of a negotiator in the standards world. We find common ground; in my day it was between the U.S. and the U.K. We try to find common ground and arrange things so they can move forward. I had to do that because in SC7 there were very large producers of software, and the clients including many government departments and agencies-were also very large.
Is that often Canada’s role? To bring different (and sometimes opposing) parties together in international standardization forums?
Yes, it became somewhat expected that Canada would do that type of thing. I’ve seen that in all the committees. We’re kind of seen as a non-threatening, neutral party. We didn’t have a lot of commercial interests in some things, so we were seen as a trustworthy negotiator. That was interesting, because it can give you a sense of achievement that you wouldn’t always get with the technical work of producing documents. It was a more immediate sense of satisfaction. You start the plenary with war on the horizon, and then are able to negotiate peace (at least for the next six months or so) by the closing of the plenary.
What are some of your personal highlights from your time working in standards?
The first major highlight was when SMC SC7 won an SCC award in 2006, with the gala dinner at the National Gallery of Canada. Another highlight is enabling the use of profiles, which are standardized documents that assemble material from multiple other standards for a specific purpose while offering similar benefits as standards do. I’ll start by saying that SC 7 standards tend to be very heavy. They aren’t typically used in smaller organizations like the one I was working in. A very small enterprise, or a very small project in a big enterprise, could not use the big standard, so they did nothing, and improvised their own system-development lifecycle. But Canada was instrumental, in 2004-05, in making the material from SC 7 standards more accessible. Actually, Anatol Kark, who was the convenor of 12207 (ISO/IEC 12207 – Systems and software engineering -- Software life cycle processes) and 15288 (ISO/IEC/IEEE 15288:2015 – Systems and software engineering -- System life cycle processes) at the time and is now its secretary, is the one who triggered those improvements.
Initially, we called a meeting in Brisbane to discuss the possibility of condensing 12207 to make it more accessible, and we got two reactions: The first was from the author of the big standard, who said it would be impossible not to implement the whole standard. You cannot carve it and reduce it to a 20-page document, he maintained. So they said not to touch it, and this is why we started another group.
But the other response was from Thailand, who said, “Well, we’ve started doing that—since 12207 was tailorable, we’ve packaged a subset of the standard, and we’ve published it as a national standard. It works, and we’re ready to put money into that.” So an alliance emerged between Canada and Thailand, and Thailand was named the convenor of the group. I was the secretary because I had experience organizing things, and could serve as the de facto convenor while my colleague was in his training period. We invited a panel of experts to Thailand for three meetings to prepare the project definition and all the required documents, so when the project started, we already had a requirements document and did a survey of clients. Then we discovered that Mexico had done the equivalent with a national standard of its own, but on a somewhat bigger scale, and targeting SMEs rather than very small enterprises. It had a national standard that was about the size of the thing we were considering. So Mexico took that standard, translated it into English, and provided the material for us to use as a base document. We developed a series of documents (20) under the umbrella project 29110.
Initially, my involvement was to provide management and administrative support, but I became very interested in the topic itself. One good thing I did was discover an obscure OSI [Open Systems Interconnection] document about preparing profiles, which is a methodical way of taking parts of other standards and assembling them in a standardized document. So I discovered that option, and I convinced everybody that that was the way to go. This way, we were allowed to depart from the original standard, but this option allowed us to select requirements from any SC 7 standards. Through this method, we were able to produce an integrated document that had requirements for the processes, tools, resources and skills needed in a small document. That project has been very successful so far.
What might the world look like today if not for all the work done by you and the committees you worked on? How have standards mattered in these areas?
In terms of impact on the real world, that’s tough to say. Most of our standards are used as reference material, but they are not necessarily implemented as-is. They serve as the baseline for systems and software engineering, helping organizations to integrate standard practices of their own. Given the nature of its process standards, SC7 had to develop and standardize a process assessment method, based more on outcomes and capability evaluation than conformity with requirements.
However, there are new ways to hide these things inside tools, so we’re starting to see some of our standards hidden in project management tools or workplan tools. A systems-development methodology is a business process, and it can be put in a business process tool and delivered that way. That’s probably the path forward in delivering our standards; as a workflow spec, to put in a workflow tool or a project management thing. That’s how companies have success.
Do you have any advice or insight to share with someone considering getting more involved in standardization? What would young professionals gain by getting more involved?
One thing that participants will get—besides the satisfaction of participating in the standardization world, of course—is access to a repository of knowledge that is invaluable. You also develop personal rigour and discipline in preparing deliverables, and you get skills in negotiation and getting consensus. That’s the benefit I got from it, and I think it’s a good selling point.
When I try to explain to people why they should join the group, that’s one of the things I say: you will get from it at least as much, if not more, than what you put in. It’s not just a one-way street where you give everything away and get nothing. You may not gain money from participation in standardization, but you get other benefits. I gained contacts, friends and marketing benefits. Some contracts I was awarded were because of contacts I made in the standards world. There are a lot of ways you can justify the expense of spending a few weeks a year on these committees.