August 31st, 2014

2021 год

Ivar Jacobson об Essence и не только

Ivar Jacobson, похоже, смирился с нашей идеей о том, что Essence kernel для системной инженерии нужно немножко подхакать, нельзя его просто нарастить над софтовым kernel. Вот фрагмент из его последнего интервью, где он пишет и о нашей работе в INCOSE Russian chapter (CSI Communications, August 2014 --
Debasish: Is there a distinction between what Essence is and what a kernel is?

Ivar: Yes. Essence is a kernel for software development endeavors. Thus, Essence is a specifi c kernel. There could be other kernels.

Pinakpani: What might be a difference between one kernel and another?

Ivar: As I just said, Essence is a kernel to support endeavors that result in a software system. There will be an extended kernel for systems including hardware and peopleware – a kernel for systems engineering. So there could be other kernels. Now what we have seen is the Essence kernel developed for software endeavors can be easily modified to also work for system engineering. So Essence is inherently more generic, but we now want to focus on software to make sure the kernel is efficient for software development.

Debasish: So could I say in the most abstract sense, a kernel attempts to establish a common ground for a group endeavor, and that group endeavor could be anything. In this case its software, but it could be building a skyscraper or building a bridge or building a company or anything like that. Correct?

Ivar: Yes, in Russia people have realized that a kernel similar to the Essence kernel could work for almost any human endeavor. As a first example, a team in Russia coming from the Russian Chapter of INCOSE is working on extending the Essence kernel so that it also includes systems engineering – hardware and software and people ware. The changes to get there are rather small.
Ещё он вновь разъясняет, почему эти чеклисты именно про альфы, а не про рабочие продукты. Это про результат содержательный, а не результат по форме (увы, нам часто не удаётся объяснить менеджерам и инженерам: все привыкли к внешнему контролю по форме, а о внутреннем контроле по содержанию даже не хотят задумываться):
Pinakpani: You often talk about software project checklist. Checklists have been around forever and ever and not given a value expected. What are these and how do they help a software professional? A developer, a tester, an architect or a project manager? Why do you think your checklists are better?

Ivar: Historically we have used checklists to identify progress. The problem with these checklists has been that they have usually been related to the fact that you have done a particular activity or that you have written a particular work product, a document or something like that. Such checklists are very easy to cheat and not really very useful. The fact that you have written a document doesn't mean the document is valuable. By having states representing real outcome, you know you really have achieved something when you have reached a particular state. And not in terms of written documents or performed activities. For example, the Team Collaborating state cannot be achieved just by listing the names of your team members. It requires that the team members are communicating in an open and honest way, and that the team members are focused on their agreed mission. That is actually the key to the difference. Our checklists are measuring or identifying that you really have achieved something and not that you have filled in a document template or that you have performed an activity.

Debasish: So are you saying that the particular kinds of checklists that you've got are trying to measure the quality of the item or activity or artifact?

Ivar: Not exactly. Essence doesn't care about documents at all, it doesn't care that you have done some activity. Instead, Essence cares that you have achieved something of value like executable code. Executable code is a real result. For instance, that you have written a requirement specification is not something that we would use to measure progress. Instead that you have got consensus among the stakeholders that these are the requirements for what the system is required to do.
Ещё один горячий пункт, это про размытость и невнятность формулировок вопросов в чеклистах Essence. Это сделано намеренно, но именно это в Essence дико раздражает "железных" инженеров, именно в нетерпении к этому и в непонимании этому самая существенная разница между культурой программных и железных инженеров (по крайней мере, железных инженеров советской производственной системы). Железные инженеры хотят в этой части взять под козырёк, но не хотят ничего обсуждать -- "как начальники прикажут, так мы и будем делать. И вся ответственность на предложившем вопросы. Сами же ни о чём договариваться не будем -- о чём там договариваться? Всё и так ясно". А основная идея Essence -- это как раз договориться внутри команды! И не отделываться "готовностью рабочих продуктов", и не обманываться, что "и так ясно". Вот:
Pinakpani: The different checks in the checklists are ambiguous. What value does such checklists give?

Ivar: That is really a very important question. If you go through a checklist for a particular state, it's not necessarily instantly clear what is meant to achieve a state. This is actually intentional. If we tried to make it unambiguous, we would have to express ourselves in a formal way and then almost nobody would understand what is meant. On the other hand if we had no precision at all the checklists wouldn’t give us any hint of the meaning and that wouldn’t make them useful. Let's go back to the Bounded state we discussed earlier and look at the example checklist item in this state that says, “the stakeholders have a shared understanding of the extent of the proposed solution”. Some people might think we need a complete and consistent set of requirements that are frozen to achieve this state but that is not what is meant by Bounded. A “shared understanding of the extent” means the stakeholders agree where the boundaries of the proposed system lie. The team needs to agree that this checklist item is achieved by discussing it within the context of their own endeavor. This is one of the reasons we refer to Essence as a “thinking framework.” Instead we have had to strike a balance and to some extent rely on people’s experience. We know that within a team, people may have different opinions about the meaning of a particular checklist item. That results in a discussion, which is most valuable, and eventually the team will decide on how they interpret the checklist item and take a decision about whether the item has been achieved or not as in the example referred to previously.

Debasish: In one of your prior answers you used the word "consensus" – for example, is their consensus about the requirements. The ambiguous word there is obviously "consensus". Does consensus mean 80% of the people like it or my boss likes it? What is the meaning of "consensus" is partly environmentally determined. That makes it a useful ambiguity. It makes it a useful ambiguity because it brings up discussion which inevitably must be clarifying to the process. Would you agree?

Ivar: Yes, exactly that's a very good example. It brings up a discussion and the team will eventually agree and take a decision about whether we have achieved what the checklist item implies and whether we have consensus or not.

Pinakpani: The ambiguity brings up a discussion of a likely critical aspect of the endeavor as opposed to that being left out of the mind of the developers. Or everybody assuming things are okay without really having had an explicit agreement. Would that be a fair statement?

Ivar: Yes.
Тем, кто дочитал до этого места, будет интересно и замечание Ivar про постепенно восстанавливающийся после воцарения agility вкус к архитектурной работе:
Debasish: Object orientation and component based development stood on strong philosophy of separation of concerns and compartmentalization of responsibilities. But, immature learning as well as lack of fundamentals often leads to poor conceptualization of code reuse. If code is not usable in its first instance re-usability is a far cry. Do you agree?

Ivar: Software reuse is a complex area and much can be said about it. Together with Martin Griss, I wrote a book (Software Reuse…), which discusses the questions you raise. Briefly, I would like to say that software reuse is something you need to architect to get. It is not something you get for free. It requires architecting competencies that have not been promoted since the world became agile. However, architecture practices are on its way back and software reuse will once again be a concern for all IT executives.
2021 год

Сто имён деиндустриализации. Робовей в робовейнике.

В разных странах деиндустриализация aka "четвёртая промышленная революция" называется в госорганах по-разному, а в частном секторе так и вообще глаза разбегаются от изобилия имён. Так, в США предпочитают advanced manufacturing (свежий финский обзор тут:, в Германии примерно то же называют Industrie 4.0 (опять же, свежий финский обзор тут: Там ещё миллион других имён: cyber-physical production system (особенно любят в Industrie 4.0 -- вот тамошняя white paper:, Industrial Internet (как следующая революция после industrial revolution и internet revolution. Вот так, по простому --, "industrial internet is projected to impact 62% of the world's GDP"). Internet of Things масштабов предприятия, всё оборудование в сети. В Industrie 4.0 говорят, что и людей сюда тоже обязательно включают, в самых разных ролях -- Challenges for the human factor in future production scenarios,!/industry%204.0%20-%20full.pdf). Словотворчество на подъеме, как в старые добрые времена (помните information superhighway? Вот и сегодняшние новомодные Industrie 4.0 будут там же, наряду с давно сдувшимся web 2.0 и даже уже сдохшим web 3.0).

В принципе, "сеть -- это и есть компьютер", "человечество -- это есть человек", "предприятие -- это и есть станок", "стая роботов -- это и есть робот" (ладно, не стая. Стадо. Но уж точно не рой!). Птолемеевские модели чего бы то ни было становятся моветоном. То, что человека делает человеком человечество, это понятно всем тем, кто знает про людей-маугли. Вот про компьютер это было не так очевидно ещё пяток лет назад. Но сейчас уже понятно тоже всем. А вот про роботов, особенно про промышленных роботов -- это всё только начинается. Одиночные киберфизические системы это очень интересно, но настоящий рок-н-ролл начинается там, где эти системы объединяются сетью в их кибер-части, объединяясь также и в их физической части -- имея возможность взаимодействовать друг с другом и окружающими людьми.

Я для себя окончательно сформулировал, что одиночные роботы (дроны, промышленные манипуляторы, кибер-физические системы, как ни назови -- я бы сейчас словами не заморачивался) меня интересуют в сильно меньшей степени, чем сообщества этих роботов: робовечество интересно (которое чем дальше в лес, тем меньше будет робовечеством, постепенно сливаясь с просто человечеством). Робот-маугли, одиноко трудящийся в режиме 24/7 мало интересен. Как человек должен быть в человейнике, а не жить как Робинзон Крузо, такт и робот должен быть в робовейнике, а не существовать сам по себе. Впрочем, через некоторое время всё это круто перемешается: человек в робовейнике, робот в человейнике -- всё пойдёт кубарем. Главное, не мыслить про одиноких по жизни роботов и людей как основные объекты (кроме ситуации, когда их нужно починить, конечно). Нет: коммуникация, обмены, совместная деятельность, накопление знаний, цивилизация. Именно это делает человека человеком, делает робота роботом. Нежить, она чуть поднакопится в количестве, и тоже будет социальна. Эта социальность и интересна, а не как изготовить контроллер к пятой ноге робота или научить робота прыгать через канаву. Впрочем, "научить робота" -- это уже социальность, при этом самая крутая социальность тут будет, когда робот одной фирмы и конструкции сможет научить чему-то робота другой фирмы и конструкции.

P.S. Пожалуйста, не нужно тут комментов про скайнет. Я понимаю, что эти комменты идут у многих рефлекторно ("фрукт -- яблоко", "робот -- скайнет"), но уж сдерживайтесь, пожалуйста.