SEMAT is a very welcome addition to the ongoing discussions on what software-engineering is (craft or engineering), and how the endeavor of building software must be organized. The initiators of SEMAT quite rightly point out that many of the discussions about methods tend to look at the question from a particular viewpoint at the expense of other viewpoints. As a result single truths emerge where some aspects of the endeavor outshine others: Artifact-centric, management-driven processes like RUP versus action-driven, people-centric lean processes such as SCRUM or XP versus architecture-centric methods verses test-centric methods such as TDD versus etc. SEMAT is the result of several years of discussions among some of the figure-heads of software engineering, and thus the result, for the first time explained in the present book, should be considered with interest.
SEMAT takes a bold step backwards. It advocates looking at the software endeavor in a more balanced way by identifying the key areas of activity which together are part of the endeavor, and where failure in any of the ereas would imply failure of the overall effort. These key areas are called alphas (a choice of name which seems somewhat arbitrary and may make you feel uneasy if you dislike management waffle or sectarian talk). By default, there are seven such areas: Opportunity, Stakeholders, Requirements, Software System, Team, Work, and Way of Working. For each area there is a high level work-flow with states through which the endeavor progresses from initiation to finish. You may, if you find it necessary, add more such areas, but where exactly the delineation between alpha and the doing within an alpha is remains somewhat unclear. SEMAT has nothing new to offer in terms of content: But unlike, say RUP, which clouds the horizon by too much detail, or SCRUM, which narrows perception to exclude just a little too much, SEMAT highlights what really matters.
'The Essence of Software Engineering' for the first time sums up, and explains by way of example, what SEMAT is all about. Which, given the effort apparently spent on the discussions that lead up to the book, seems precious little. The one immediately obvious feature of the book is its repetitiveness: The same statements seem to be made ad nauseam, and the same illustrations shown more often than one cares to look at them. There are seven parts to the book, but most of what can reasonably be said will have been said by the end of the first part. From then on you might find yourself flicking the pages rather quickly to avoid the boredom of repetition. A slimmer and less expensive book would be much welcome.
And yet, in spite of these immediate misgivings, you cannot miss 'The Essence of Software Engineering' if you want to stay abreast of the discussions on software engineering as a whole. The bold step backwards taken by SEMAT may indeed help you, in whatever capacity you work in software, get a clear picture of what counts in the software endeavor. This is made quite explicit by SEMAT, and taking in that lesson may help being less zealous about some aspects of working on software at the expense of others.
This is the book to read on SEMAT - but of you can help it get one copy only and share it among your colleagues to make the price come in proportion to the actual content. And then let's go away and do alphas.