A Major Milestone: On the way to a new standard

Semat Blog Release by Shihong Huang

We are now happy to declare that Semat has reached a milestone in its history. The OMG RFP (Request for Proposal), entitled “A Foundation for the Agile Creation and Enactment of Software Engineering Methods”, was approved by OMG on June 24, 2011. The RFP is heavily inspired by the work of Semat.  Becoming adopted as part of a standard body is a great achievement. The full version of OMG RFP can be found in [1].

1. Challenges we face

The number of people developing software is exceeding 10 millions.  Some sources (for instance Evans Data Corporation) estimated in 2010 the number was 20 millions.  Most of these people have no clearly defined method to follow; they just do it.  Most of them think they know why, what and how they work. So even if not explicitly defined, they have a method.  However, improving these methods to help developers build software better, faster and with happier clients and developers, we need to better understand what software engineering is.  This is why Semat was created with the vision to refound software engineering as a rigorous discipline based on a solid theory, proven principles and best practices.

Some Semat theses include:

(1)        Every method is just a composition of practices, either human- or technology-related.

(2)        Practices are reusable over many application areas and technologies.

(3)        Underneath all practices is a small kernel of universals, things that we always have, do or produce when building software.

(4)        Methods and practices are described by a light Language.

Could we address the need of millions of practitioners, could we bridge the vast chasm between academic research and industrial practices? Today, by reaching this milestone of Semat, we are more confident than ever – yes, we can.  However, it won’t be easy.  We need to create something fundamentally new.

2. Two principles we follow

First, we will rely on two leading principles – ‘separation of concerns’ and ‘agile in everything’, inspired by which some distinctive features have been found.  We believe these features are essential to what we would like to achieve.

2.1. Separation of Concerns

A key principle of the Semat initiative is the principle of Separation of Concerns (SoC) (  It penetrates much of what we do. It allows us to specify a core, and then through extensions without changing or complicating the core, add what is needed for the more specific cases.  In this way we can be inclusive of all relevant work in software engineering and not excluding anything that is or will be beneficial to someone.  Below are some examples of the application of this principle, more to come later.

(1)   It separates at least two different views of methods: the practitioners’ view and the method engineers’ view. The primary users of methods are project practitioners (developers, testers, project leads, etc.).  We should target the practitioners uncompromisingly. Through extensions the result will also support method engineers efficiently without complicating its usage for the practitioners.

(2)   It separates the essentials from the non-essentials, such as key guidance from detailed guidance, or explicit knowledge from tacit knowledge.

(3)   It separates the generalized definitions of terms from specialized definition details, allowing for the inclusion, rather than the exclusion of earlier work on methods.

2.2. Agile in everything

Being agile and light-weight is the key to be successful. We should be agile in whatever we do, nothing else would be acceptable. In a separate blog we have made an attempt to capture what we mean by ‘agile in everything’.  Please, read and give your comments and suggestions.

3. Three distinctive features we identify

In our previous blog “The key points of the OMG RFP draft: call for a widely accepted kernel” (, we highlighted three striking features of this initiative:

(1)   Finding a kernel

It emphasizes that the RFP is not creating a new method; instead, it is to build a foundation that “consists of a kernel of software engineering domain concepts and relationships that is extensible (scalable), flexible and easy to use”.

(2)    Practitioners focused

The kernel has to be agile and lightweight to be successful. It focuses on people who do the work: the practitioners (e.g., analysts, developers, testers, etc). This foundation is created by practitioners, and serves the practitioners. Without getting the practitioners to adopt the result of this initiative, it will frankly just be an intellectual exercise.

(3)   Focus on the usage of methods, not the definition of them

The priorities of practitioners are to actually develop software and to get the job done. They can do this without a lot of descriptions.  This is why our language must primarily focus on method usage, whereas method definition is a secondary objective. The use of a method can be defined as the carrying out of that method in the context of a specific project effort.

4. Call for participation

Getting the RFP approved by OMG was one of the major milestones of Semat. Quoting Churchill: “Now this is not the end. It is not even the beginning of the end. But it is, perhaps, the end of the beginning.” Now we need to create something that will go beyond anything previously done by any standards body working with methods: getting the standard adopted by the broad developer community.

This is a challenge that cannot be overestimated.  This requires new fresh ideas that are not typical for standard bodies and methods work.  Fortunately, the Semat teams have several such new ideas. ‘Separation of concerns’ and ‘agile in everything’ will guide us, but more is needed.  Thus we would like to have more very talented people involved in our work.

Please let’s us hear from you – your feedback and comments on our blogs. Your involvements are critical in making a difference to the community.


[1]   OMG RFP “A Foundation for the Agile Creation and Enactment of Software Engineering Methods”, online at

(Reading tips: You can skip sections 1—5, since they just introduce general rules for OMG proposals and standards; you can start reading section 6, since the actual technical content starts here.)

No comments yet. Be the first.