Моделирование на Архимейте -- это создание таких диаграмм, при помощи которых мы можем что-то узнавать про предприятие. Архимейт имеет встроенные в него способы извлечения знаний о предприятии -- он заставляет архитектора задавать вопросы (в том числе и самому себе) там, где есть неочевидные сразу "непонятки". Ответы на вопросы чаще всего требуют либо изобрести чего-нибудь (если речь идет о проектировании нового предприятия), либо разузнать чего-нибудь (если описывается уже имеющееся предприятие), либо просто исправить очевидную ошибку.

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

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

Механизм типов подразумевает задание главным образом одного простого вопроса, ответ на который обычно очень сложно получить. Для каждого встречающегося в жизни объекта спросите "что это?!", "часть чего это?", "с чем это связано?". Подберите тип Архимейта. Получите удовольствие: до вас мало кто задумывался, "что это". Ответ на этот вопрос может оказаться очень нетривиальным, а получение этого ответа заставит задать десятки других вопросов.

Вторым механизмом является предписанное именование. Если у вас практика -- то это отглагольное существительное, например "полевой инжиниринг" (а хоть эта "отглагольность" и идет тут от английского). Существительные плохо ассоциируются с "последовательностью исполнения", кооперативными цепочками действий разных деятелей. А вот процессы -- это глагол, и придется написать "инжинирить в поле". Вы этого хотели? Если нет -- то что вы делаете? Если правильный вопрос к объекту не "что делать?" -- то придется признать, что речь идет не о процессе, а о чем-то другом (практике? роли? -- это все "промежуточные" типы между поведением и активной структурой).

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

Моделирование идет циклически: поглядел на жизнь и что-то про нее понял, затем записал понятое на диаграмме. Поглядел на диаграмму -- нашел ошибки. Поглядел на жизнь -- исправил ошибки в диаграмме. Поглядел на диаграмму -- понял что-то про жизнь. Записал понятое на диаграмме -- и опять начал искать ошибки. Результат такого процесса довольно неожиданный: архитектор вдруг начинает что-то понимать про жизнь предприятия едва ли не глубже, чем непосредственно участвующие в деятельности люди. Архитектор находит в действующих предприятиях бессмысленные работы (activity, кстати, рекомендую переводить как "работы" -- родовой термин для всех вариантов поведений), странные группировки объектов деятельности, лишних деятелей. Он же находит их в проектах предприятий -- как своих проектах, так и в проектах других людей. Формализм Архимейта заставляет продумывать то, что прошло бы мимо внимания. Ошибки и трудности моделирования являются теми ниточками, с которых можно начинать распутывание запутанного клубка деятельности предприятия -- и Архимейт в изобилии поставляет такие ниточки.

Особенностью моделирования на Архимейте является его кажущаяся аскетичность. Моделирование делается намеренно неподробно (при всех заявлениях, что "при потребности вы сможете выразить все нужные детали). Типов объектов и отношений в Архимейте намеренно мало, авторы заявляют что сознательно пошли на удовлетворение только 20% потребностей архитекторов в выразительных средствах (эти 20% покрывают 80% всех случаев, а остальные 80% "выразительности" ушли бы на оставшиеся 20% случаев -- эти "остальные выразительности" просто убрали из языка). Но вся эта неподробность и аскетичность кажущаяся. Архимейт заставляет писать суть дела -- как бы банально и просто эта суть ни выглядела на диаграмме. И -- чудо, чудо -- эта банальная суть дела всегда вызывает много банальных вопросов как к жизни, так и к диаграмме. Архимейт создан так, чтобы задавать правильные вопросы. Ответы на эти вопросы почему-то оказываются небанальными, и в этом главная сила Архимейта.

Обратите внимание, я тут удержался, и ничего не говорил про "онтологию". Но для тех, кому это слово не чуждо, я таки скажу: типы Архимейта таки представляют собой онтологию предприятия -- понимание авторов Архимейта того, что можно найти на любом предприятии. Это означает, что на любом предприятии можно найти объекты деятельности и деятелей, процессы и данные, функционал программ и узлы IT-оборудования. Архимейт заставляет находить в окружающем мире именно эти (а не какие-то другие -- например, "трансакции DEMO") объекты и отношения. Именно задание этой формальной онтологии и порождает вопросы, прежде всего классический онтологический вопрос про обнаруженный в жизни объект: "что это?!".

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

Удобная графическая нотация является при этом только бонусом, секрет успеха вовсе не в ней. Секрет именно в типах объектов и отношений Архимейта, предлагаемых соглашениях об именовании и декларируемом соответствии формальных моделей Архимейта замыслу предприятия или реальному предприятию -- и тех вопросах, которые эти типы, имена и отражение реальности моделью задают архитектору.

Как и в любом другом языке, в Архимейте можно влёгкую вместо "мама мыла раму" написать "рама мыло мамы", или вообще неправильно использовать слова для обозначения реалий окружающего мира. Увы, чтения спецификации недостаточно, чтобы избежать этих ошибок: в спецификации написано, как нужно -- и не предупреждается, как не нужно моделировать. Так что я приведу тут несколько наиболее распространенных ошибок, которые делают новички. Считайте, что это своеобразный чеклист: проверяйте, есть ли эти ошибки на ваших и чужих диаграммах.

1. Описывается только один уровень абстракции -- чаще всего уровень обработки данных. Большинство любителей Архимейта вышли из программистов, обозвали себя "бизнес аналитиками" (даже не задумываясь над тем, причем тут вообще "бизнес") и воспарили мыслью над рутиной оборудования -- поэтому на их диаграммах обычно изображены только абстрактные программы и данные, никак не связанные с деятельностью, и не укорененные ни на каком оборудовании. Это главная ошибка многих и многих "архитекторов предприятия" -- и именно для борьбы с этой ошибкой был придуман Архимейт.

Очень трудно, почти невозможно удерживать в голове и деятельность людей, и работу программ, и "железо" с системным софтом. Но если вы этого не делаете, то вы не архитектор. Извинений для этой ошибки "одноуровневости" нет, следствия ужасны.

Редко-редко бывает и другой вариант: Архимейт используется только для отображения деятельности людей, без учета обработки данных. Такая "деятельностная одноуровневость" не менее плоха, чем одноуровневость отображения только обработки данных -- ведь информационные технологии и правильные приложения существенно меняют сам способ работы. Работа экскаватором по своей организации существенно отличается от работы лопатами, но именно это не будут учитывать те немногие "бизнес-аналитики", которые вышли не из программистов, а из выпускников программ MBA -- и которые не утруждают себя разбирательством с возможностями софта и их влиянием на организацию дела.

Одноуровневости отображения уровня оборудования в Архимейте почти не бывает, но все учебники и блоги практикующих архитекторов предупреждают о пагубности игнорирования этого уровня. Более того, они советуют моделировать оборудование и системный софт довольно детально.

Почему важно отображение всех этих уровней одновременно? Потому что вам придется отвечать на очень и очень неудобные вопросы про несоответствие деятельности, обработки данных и оборудования. Ибо на диаграммах это несоответствие становится хорошо видным и самые разные люди начинают задавать самые разные вопросы. Отвечать на эти вопросы архитектурными решениями (менять диаграммы с "as is" на "to be", а затем планировать работы по переходу к "to be") -- это и есть работа архитектора предприятия.

2. Очень много ошибок связаны с непониманием сервис-ориентированности Архимейта. Вы должны понимать, что на предприятии все кого-то обслуживают, а не самодостаточны. Архимейт требует сформулировать в явном виде: чем занят тот или иной кусок предприятия, отображенный в архитектуре -- какой сервис он предоставляет "наружу", и как этот кусок предприятия устроен "внутри", чтобы иметь возможность предоставлять этот сервис.

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

Любой кусок архитектуры зачем-то нужен -- деятельность обслуживает (service) каких-то клиентов, обработка данных обслуживает (service) деятельность и другую обработку данных, оборудование обслуживает (service) обработку данных и другое оборудование. Явное указание сервисов заставляет трижды подумать, зачем нужен тот или иной кусок предприятия -- и результаты этого размышления часто бывают нетривиальны и заставляют менять архитектуру (а потом менять предприятие в соответствии с этими изменениями архитектуры).

Большинство новичков-архитекторов вообще не использует сервисов на диаграммах, что строго противоречит подходу Архимейта. Отсутствие явно прописанных сервисов верный знак, что в голове архитектора нет разделения на "внутренний-внешний", то есть его архитектура несистемна (не в терминах систем), немодульна -- со всеми негативными последствиями (модуль-подсистема отличается прежде всего тем, что его можно заменить, не трогая всю целевую систему. Модульная архитектура позволяет заменять "внутреннее", не меняя "внешнего" и поддерживать такой стиль мышления, поощряющий замену реализаций по мере получения новой информации и открытия новых возможностей. Если использовать сервисы, то можно легко заменить архитектуру IT-решения, не меняя деятельности, можно заменить одно интеграционное решение на другое, не меняя всей архитектуры IT-решения, можно заменить оборудование, не меняя обработки данных, можно добавить еще пару-тройку каналов предоставления сервиса и т.д.). Если не использовать сервисы, то такие замены очень трудно сформулировать и выделить из паутины объектов и отношений полной архитектуры.

Сервисы можно оказывать по разным каналам -- и для этого используются интерфейсы (которые в Архимейте понимаются именно как "каналы доставвки обслуживания", "места/способы оказания сервиса" -- электронная почта, прилавок, веб-сервис и т.д.). Если есть сервис, то можно думать, как его доставить потребителям -- ибо дорог сервис доставленный, а не просто существующий в природе ("за границей телушка полушка, да рубль перевоз"). Если есть сервис, то хотя бы на мгновение можно будет подумать и о том, кому этот сервис нужен -- и учесть потребительский интерес, независимо от того, внешний этот потребитель или внутренний по отношению к предприятию, формализован ли контракт сервиса, или неформален, оказывается ли этот сервис людям (уровень деятельности) или программам (уровень обработки данных). Если сервиса нет, то на диаграмме ничто не указывает на этот интерес -- и резко возрастает вероятность получить никому не нужный кусок деятельности, или прикупить ненужную софтинку, или закупить ненужное оборудование в порядке реализации такой "бессервисной" архитектуры.

3. Неразличение группы описаний (view) и полного описания в ходе редактирования диаграмм. Полное описание -- это все элементы и связи. Тематическая группа описаний (например, группа описаний информационной структуры) -- отфильтрованные из полного описания элементы. Редакторы Архимейта умные -- они умеют поддерживать общее описание, показывая разные его части на разных диаграммах. Новички часто это игнорируют -- и поэтому вместо использования в разных группах описаний одного и того же элемента порождают новый в каждой группе описаний, причем с одним и тем же именем. Да и не только новички это делают! В примере архитектурного описания для редактора Archi тоже встречается такая ошибка: один и тот же элемент архитектуры в разных группах описаний оказывается не одним и тем же, а разным.

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

Удаление элемента происходит либо из полного описания (в Archi это delete from model), либо только из группы описаний (delete from view). Если вы случайно удалили элемент из архитектурной модели, то вам нужно его завести на диаграмме этой группы описаний заново, "с нуля". Если вы случайно удалили элемент из группы описаний, то вам его нужно вытащить из модели на полное описание -- создание с нуля как раз и породит дублирование.

Элементы дерева модели, которые в Archi даны курсивом, означают такие элементы, которые просто не были выведены ни в одной из тематических групп описаний. Но они не удалены из модели! Их просто отфильтровали из всех диаграмм. Новичкам к такому поведению редактора нужно привыкнуть, но пока этой привычки не появилось, управление конфигурацией вашим архитектурным проектом по мере его разрастания будет проблематичным.

4. Новички (которым к этому моменту обычно промыли мозги "процессным подходом") начинают архитектурную работу с выявления (или придумывания) процессов. Как ни странно, это ошибка (см., например,http://ailev.livejournal.com/867599.html). Начинать всегда нужно с элементов пассивной структуры и предоставляемых сервисов. Процессы появляются потом, когда вы понимаете, что вам нужно делать с пассивной структурой, чтобы добиться полезной работы сервиса.

И только в самую последнюю очередь нужно прописывать элементы активной структуры (когда деятельность понятна, можно кого-нибудь назначить на ее выполнение -- а не придумывать деятельность под известного вам исполнителя).

Сорок дней, душа Нового Года уже болтается в этом мире. Жена час назад дарила тёще новогодние сувенирчики (Деда Мороза и Снегурочку, сделанных почему-то в Ирландии), а прямо сейчас Pandora.com прислала оповещение о новых станциях с рождественскими песенками.

Если в этом году всё так рано начинается, то страшно представить, какой разгул веселья будет к середине декабря. Схватка Деда Мороза с Дедом Лайном в этом году будет явно нешуточной.

1. Информационные модели крупных инженерных объектов – это прежде всего данные информационной модели, описывающие целевую систему ("проектные данные"). А сами информационные модели описываются главным образом в терминах моделей их данных ("справочных данных").

2. Модели данных информационных моделей (пардон за каламбур) описываются на трех уровнях абстракции:
-- архитектурном
-- концептуальном (нейтральном)
-- прикладном (логическо-физической реализации прикладным софтом)

3. Описание архитектурного уровня выполняется в подходе Архимейт, группа описаний информационной структуры (http://ailev.livejournal.com/955954.html). Целью архитектурного описания информационной модели является представить крупные блоки модели, выразить их связь с объектами деятельности и дать понимание о том, какие прикладные системы используются для их хранения. Архитектурное описание в свою очередь разбивается на три уровня абстракции (в соответствии с подходом Архимейт, ):

А) на уровне деятельности архитектурного описания перечисляются объекты моделирования (в том числе и intangible – типа «прибыль» или «сейсмостойкость»). Это «та целевая система, которую моделирует система-модель».

Б) на уровне данных архитектурного описания перечисляются концептуальные (предметные) наборы данных концептуальной (нейтральной) модели, соответствующие микротеориям моделирования предметной области (термин "микротеория" был предложен сначала людьми из CYC, а сейчас по факту принят всеми онтологами). Модель данных для этих наборов данных на архитектурном уровне абстракции не моделируется – она будет детализироваться на концептуальном (нейтральном) уровне абстракции

В) на уровне оборудования архитектурного описания перечисляются варианты реализации наборы данных прикладного уровня полного описания, модель данных которых будет описана на прикладном уровне.

4. Детальное описание концептуального нейтрального уровня полного описания представляется в виде справочных данных ISO 15926 ("модели данных" наборов данных информационной модели). Гранулярность описания соответствует архитектурному описанию уровня данных информационной структуры архитектурного описания, а в ISO 15926 эта гранулярность выражена микротеориями (то есть предметно-гранулированные описания, опирающиеся на какой-то связный кусок картины мира).
Тем самым детальное описание концептуального нейтрального уровня полного описания информационной модели представляет собой библиотеку справочных данных ISO 15926, структурированную согласно архитектурному описанию.

5. Прикладной уровень (логически-физической реализации) полного описания представляет собой описание мэппинга из концептуальной (нейтральной, ISO 15926) модели данных в конкретную (логическую) модель данных информационной системы, выбранной для (физического) хранения информационной модели (хранения данных информационной модели). Тем самым описание прикладного уровня зависит технологии реализации мэппинга к нейтральной модели (.15926, XMpLant, Iring и т.д.). Важно, что на прикладном уровне описания каждый элемент модели данных прикладной системы привязывается путем мэппинга к элементу модели данных концептуального уровня.

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

Интересно, это одного меня раздражает, как журналисты подают описания в качестве реалий? Меня, например, бесят такие высказывания, как "число жертв землетрясения достигло сегодня 38 человек" -- это через неделю после события, когда откопали еще пару трупов. То есть событие уже давно случилось, но в речи (а значит, в головах журналистов) каким-то магическим образом люди продолжают гибнуть в момент обнаружения трупов, а не в момент гибели людей.

Или вот сегодняшнее "У обвиняемого в его убийстве наметился мотив преступления" в Коммерсанте. У обвиняемого мотив был еще в момент преступления, он вовсе не наметился у него в момент обнаружения его следователями!

Вспоминаются вопросы типа "если никто из людей не видел падающего в лесу дерева -- было ли падение на самом деле?". Журналисты сейчас отвечают на этот вопрос отрицательно: нет, события не было, падение дерева произошло только в тот момент, когда оно обнаружено -- заголовок будет типа "упавших от тунгусского метеорита деревьев стало сегодня на три сотни больше".

Мне кажется, что еще лет десять назад такого словоупотребления не было. Но сегодня "упавшие деревья" и "жертвы" -- это уже не про сами деревья и жертвы, а строчки о них в чьих-то отчётах. Изменение этих строчек и есть "реальные события" в головах журналистов, а их речь это честно отражает.

Санкт-Петербург от Москвы далеко, поэтому отказался докладывать на конференции по мобильным сервисам (http://vasforum.ru/win/vas-agend.html), но в компенсацию обещал написать тут несколько замеченных мной трендов в этой сфере. На написание этой заметки я наверняка потрачу времени не меньше, чем на доклад в тамошнем формате -- зато сколько сэкономлю времени в поездах! Это, наверное, символично для конференции по мобильным сервисам:

1. Лет пять назад много писали статей о "нательной компьютерной сети" -- и она таки штатно появилась отнюдь не в форме bluetooth (как многие ожидали, наблюдая за всякими bluetooth-гарнитурами), а в форме internet tethering ("раздача интернета") через полноценное WiFi соединение: мобильные телефоны Android начиная с версии 2.3 это умеют делать "из коробки", а пользуются этой раздачей планшеты. Поскольку иметь множество симок и связанных с ними хлопот никому неинтересно, то очень много людей пользуются именно таким "нательным интернетом" из кармана в руки (от телефона к планшету) -- а рынок на это реагирует выпуском планшетов только с WiFi и отсутствием самостоятельных WWAN возможностей.

2. В отчёте за пятый год STEPS утверждается, что код -- это просто еще один тип медиа (http://ailev.livejournal.com/960827.html), имея ввиду, что фрагменты с кодом вверстываются в страницу примерно так же, как видеоролики и "проигрываются" интерпретатором примерно так же, как плеер проигрывает те же видеоролики или аудиофайлы. Но есть и еще один аспект: покупать и продавать код можно так же, как и любые другие медиа -- газеты, книжки, видео и аудио. И пиратится код примерно так же. Поэтому application store является просто расширением всяческих iTunes. А поскольку простых и сложных программных кодов можно написать примерно столько же, сколько простых и сложных книжек, или снять малобюджетных или крупнобюджетных фильмов -- то можно считать, что началась эра Гутенберга-2. Человечество до этого изготавливало коды чуть ли не вручную, и распространяло их неудобным образом, а appstore произвел тут революцию примерно такую же, как печатный пресс: ранее малодоступное стало массово доступным. Про цены и бизнес-модели я молчу, ибо история тут только-только начинается (так, "продажи внутри приложений" уже существенно меняют жизнь).

Спросите: что же тут нового? Отвечу: эти куски кода из независимых должны становиться общающимися между собой -- мечта о "верстке приложений" случится именно на планшетах, ибо на телефонах для верстки места маловато, а на компьютерах пока нет appstore и необходимой для возникновения удобоваримых стандартов верстки массовости и стандартности.

3. Может ожить идея edutainment. Все огромные вливания в чрезвычайно модное лет десять назад "образование-и-развлечение" оказались пшиком, но пшиком была и идея Apple Newton. Технологии подросли, и "наладонные компьютеры" были уже не пшиком, а планшеты стали вообще хитом. С появлением application store и дОлжного уровня технологий идея edutainment вполне может воскреснуть: достаточно поглядеть, как планшет легко вступил в соревнование с игровыми консолями -- технология оказалась более чем развлекательной, а надлежащий нишевый контент можно будет придумать за счет демократичности appstore.

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

5. Применение мобильных устройств может быть неожиданно большим в составе роботов. Роботы присутствия уже вовсю используют планшеты (на них отображается морда лица присутствующего). Но вот своему дитенку я объяснял, что после окончания курса с нарисованным роботом я куплю ему Lego NXT 2.0, а потом добавлю к этому Lego телефон -- сразу прихватив в состав дешевого крохотного робота гироскопы, датчики ускорения, вайфай, видеокамеру, более мощный компьютер и память, громкий динамик и качественный микрофон -- да еще и экран вдобавок. Роботов хороших и разных будет больше и больше, и часть мобильных сервисов очень скоро будет уже не для людей, а для роботов.

Наткнулся в Сети на отличную инфографику, иллюстрирующую мой тезис про малонужность системной инженерии в нынешней России:



Я сам не слишком хорошо отношусь к военной системной инженерии, но картинка верна в России и для любой другой сложной техники.

Опять в Нижний -- на пару дней (вторник и среда) к любимому клиенту. Буду заниматься системной инженерией, архитектурой предприятия, интеграцией данных жизненного цикла и прочими интересными вещами.

Было уже несколько прецедентов, в которых предвыборная агитация против России с жуликами и ворами признана агитацией против "Единой России" -- с соответствующими административными мерами. Мне понравился комментарий: "оппозиционные партии пока не попытались обойти этот запрет через агитацию «за жуликов и воров»" (http://www.mr7.ru/news/politics/story_47063.html).

В этом духе агитации "за жуликов и воров" можно предложить еще много вариантов:
-- пиарщики ЕР убеждают местные администрации не принимать никаких мер к оппозиции: "не бывает антирекламы, бывает только скандальная реклама".
-- ЕР регистрирует на себя торговую марку "жулики и воры", и подаёт в суд на обидчиков за нарушение интеллектуальной собственности.
-- ЕР оценивает де-факто появившийся бренд "Жулики и воры"(tm) (есть методики!) и берет кредит на предвыборную компанию под залог бренда. После выигрыша отдаёт кредит из выигранных бюджетов.
-- жулики понимают, что "жулики и воры" вот-вот окажутся в законе, и превентивно учреждают свою организацию "жулики в законе", аналогичную "ворам в законе", получая тем самым хоть какую-то позицию в торге с властью "жуликов и воров".
-- оппозиция провозглашает своей стратегией "разделяй и властвуй" и пытается поссорить между собой единоросские фракцию жуликов с фракцией воров: агитирует отдельно против жуликов, и отдельно против воров.

Попкорна мне, попкорна.

Функции целевой системы:

1. Содержание образования (чему учим):
-- контринтуитивные современные дисциплины (дисциплина -- "то, что загружается в голову": более мелкое деление, чем "учебные предметы" -- проще всего думать о "дисциплинах" как отдельных пунктах типовой современной образовательной программы по какому-то учебному предмету, или о главе учебника -- все эти "оператор цикла" и "деление с остатком" вполне подходят по уровню гранулярности).
-- возможность распознавать несколько предыдущих культурных образцов этих дисциплин (например, "использование блок-схем алгоритмов" или "субстанциальная парадигма"), знать их недостатки и конвертировать описание в терминах этих старых дисциплин в описания в терминах новых ("реинжиниринг" старого знания, по мотивам подхода книжки BORO).
-- набор дисциплин начальной серии может быть из учебных предметов математики, философской логики, алгоритмики, и даже музыки (помним, что музыка имеет формальную модель -- ноты). Использование формализмов и формальных моделей -- это основное, чему учат в STEM (http://en.wikipedia.org/wiki/STEM_fields). "Физик" всегда имеет шанс стать "лириком", а вот "лирик" обычно уже не имеет стать шанс "физиком". Образование должно давать рост числа возможных жизненных траекторий, а не их ограничение (в отличие от просто обучения, которое обслуживает одну заранее выбранную жизненную траекторию). У нас идет обучение в рамках каждой дисциплины, но сама совокупность этих обучений (компетенции моделирования на формальных языках и рассуждения о реалиях жизни с использованием этих моделей) задаёт образование.
-- учим сначала science (созданию компактных описаний сложных явлений, и операции с описаниями), а инженерии (коллективное создание рабочих продуктов) учим потом.

2. Кастомизация: возможность индивидуально определять границы ("уклоны", "специализации" -- в терминах необходимых к освоению отдельных "дисциплин" внутри общепринятых учебных предметов) в общем курсе и подстраиваться к начальному уровню и способностям. Т.е. предлагается не набор из нескольких комплексных обедов, но a la cart.

3. Особенности результата обучения: выпускникам не нужно уметь давать определения для понятий и операций и рассказывать "как это устроено" (т.е. "зубрить" учебник -- на что нацелена нынешняя школа), но нужно уверенно:
-- решать типовые задачи изучаемых дисциплин
-- распознавать объекты и операции дисциплины "в жизни" (уметь отождествлять "яблоки в жизни" и "яблоки из задачи"),
-- проходить тест "исправления ошибки по телефону": умение не просто указывать не пальцем на "эту фиговинку", а называть (этому, кстати, пока непонятно как учить -- и через лазейку этого требования могут просочиться желающие научить определениям, а не сути дела)

4. Дистантное образование:
-- доставка через планшеты (это, кстати, потребует решить множество интерфейсных проблем -- нормальной-то клавиатуры и мышки нет, зато жесты пальцами более удобны, чем жесты мышкой).
-- поддержка не только "канала ученика", но и "канала наставника" (наставник/тьютор -- это может быть родитель, учитель, репетитор и т.д.). Дело тут не только в том, что ученик не является заказчиком, но и в возможности дистантной поддержки очного образования высококачественным контентом (прежде всего -- задачи, идеи для объяснений, тестирование и т.д.).

5. Старт обучения должен быть при любых начальных компетенциях ученика, окончание при любых заданных компетенциях: технология должна предусматривать кастомизацию для входных компетенций ученика, так и адаптацию к его способности обучаться в ходе курса. Конечно, объем осваиваемых дисциплин и время обучения при этом являются переменными параметрами.

Пресуппозиции:

6. Правильно подобранным тренингом можно обучить любым телесным и мозговым практикам:
-- абсолютному слуху
-- разбиванию кирпичей голой ладошкой
-- высшей математике
-- функциональному программированию
-- онтологическому анализу
Фактор "биологических способностей" тоже корректируется (нейрокоррекция, например) -- но не входит в предмет проекта.
Другая формулировка этого тезиса: нет "неотчуждаемых от гениев искусств", есть просто плохо (или вообще никак) отмоделированные или даже спроектированные (designed, искусствено и намеренно созданные) технологии мышления, движения и т.д..

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

Приципы решения:

8. Конструктивизм -- съесть слона можно по кусочку за раз, знания прирастают инкрементально -- "модулями" ("понять что-то -- это уметь такое сделать, в том числе отмоделировать"). То есть в основе лежит не "текст содержания дисциплины", а "набор (в том числе мыслительных) действий, подразумеваемых дисциплиной".

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

Средства модульного подхода к мультидисциплинарному образованию (создание образовательной траектории из осваиваемых дисциплин -- от диагностированной начальной точки имеющихся компетенций к требуемой конечной точке в пространстве компетенций):
-- особый аппарат для обслуживания инкрементальности (связей образовательных модулей): хранение зависимостей, если есть и средства динамической "вёрстки курса" в зависимости от стартовой точки, требуемого конечного "уклона" и проявляемых способностей.

Образовательная траектория делается не столько из "учебных предметов", сколько из тесно связанных дисциплин, поддерживающих друг друга: природа не поделена на факультеты.

Ключевым моментом тут является переход от сегодняшней определяющей роли "содержания дисциплины" и мутных объяснений с традиционными "определениями основных понятий" к определяющей роли упражнений (по словам А.П.Ершова, это "сержантский метод").

9. Конструкционизм -- создание (конструирование) учениками внешне наблюдаемых артефактов (рабочих продуктов) как основная образовательная деятельность. В качестве таких артефактов предлагается представлять для проверки решения задач:
-- мелких для отработки отдельных операций в одной дисциплине
-- крупных для отработки комплексных операций в нескольких дисциплинах одного учебного предмета
-- очень крупных для отработки междисциплинарного взаимодействия в разных предметах (не хотелось бы это называть "проекты", ибо "проекты" я связываю с коллективной работой, а тут пока речь идет об индивидуальном образовании)

10. Языкоориентированность: поскольку учим моделировать предметные области, то есть учим формальным языкам (STEM):
-- использование DSL для дисциплины обеспечивает формализм представления предметной области (DSL-язык=микротеория+нотация)
-- обеспечивает необходимую модульность конструктивизма (гранулированность по языкам, гранулированность по текстам на
-- это обеспечивает учебные рабочие продукты конструкционизма (тексты на языках, которые должны представить ученики)
-- это обеспечивает автоматизм проверки и распознавания ошибок (опыт систем автоматизации проверок решения программистских задач -- систем автоматизации тестирования)
-- понятная метафора связи между учебными модулями ("линковка библиотечных образовательных модулей")

Итого: задачи решаются в комплекте учебных миров, но устроенном как language workbench (с доработками в части управления образовательными модулями с их задачами и разными языками).

11. Иерархия языков разной степени богатства для прорыва возрастного/общеобразовательного ценза:
-- разделение концептов (дисциплины) и оформляющего дисциплину представления (нотации программирования). Фишка в том, что в конечном итоге и набор концептов, и выражающий их предметно-специфический язык должны быть полными (а часто и мультипарадигмальными) -- но в начальный момент должен быть ограничен и набор концептов, и нотация. Думать нужно прежде всего о принципах работы пары ПиктоМир-КуМир.
Это означает, что language workbench поддерживает разнообразные учебные миры (языки иконографические, как в ПиктоМире, затем языки тайловые, затем языки полные-учебные как Ершол и Схема, затем языки рабочие как Питон и Скала).

12. Автоматическая линковка учебных модулей в курс -- если попросили компетенцию в дисциплине "интегральное исчисление", то необходимые для овладения этой дисциплины модули должны быть определены вплоть до умения складывать и вычитать целые числа -- а затем оттестировано владение нижележащими модулями и сформулировано, какие дисциплины из требуемых уже освоены, а компетенций по каким дисциплинам у этого конкретного ученика не хватает для начала занятий сразу по запрошенной теме -- и общий курс формируется только из нужных дисциплин, но не меньше, чем нужных.

Если считать, что учебные модули, поддерживающие дисциплины, это исполняемые (учеником) модули на "языке описания учебного процесса", то это аналогично задаче разрешения зависимостей (думайте о task linker/builder/make). Далее нужно из "пирамидки зависимостей" построить последовательность -- "образовательный маршрут", причем с адаптивной перемаршрутизацией по мере понимания реальных способностей и начального уровня ученика в ходе продвижения по маршруту.

Конечно, обеспечение такой линковки требует не просто тщательного моделирования отдельных дисциплин, но и какой-то общеонтологической проработки: вряд ли удастся достигнуть унификации всей используемой терминологии и понятий во всем комплекте дисциплин (возьмём хотя бы classes и sets), но должны быть средства выражения связей и при отсутствии такой унификации.

13. Главное в предлагаемом подходе -- кастомизация (каждому свой курс -- по его знаниям на старте и возможностям "в пути" и требуемым компетенциям на финише): предъявление созданных дефектных артефактов -- это диагностика того, что не освоил ученик, и можно добавить упражнений/задач на освоение именно этого материала. Невозможность создать артефакт за заданное время (как в IQ) -- это тоже диагностика, и это заставляет перейти к более простым подготовительным задачам, дополнительным объяснениям и т.д.. обеспечивается:
-- необходимым уровнем детальности в описании мыслительных операций
-- библиотекой "ментальных затыков" (ошибок) и связанным с ней библиотекой задач на прохождение этого затыка (в этой последовательности задач -- педагогические новации, "как объяснить")
-- автоматизированная диагностика затыков по артефактам
-- алгоритм планирования обучения: "пила" из последовательности заведомо сложных (диагностических) и заведомо простых задач.

Гипотеза: мы можем в существенной мере автоматизировать эту кастомизацию.

14. Дистантность может быть нестандартна: технологическая компонента доставляется сразу ученику, но отсутствующая компонента человеческого участия доставляется родителям/гувернантам/репетиторам альтернативным каналом (то есть делаем "сервис для ученика и его учителя"). Скорее всего, "полный бот" при существующем уровне технологий не может быть разработан, но вот инструментально поддержать и кое-что автоматизировать для пары "ученик-наставник" (снизив тем самым вдесятеро требования к мастерству наставника и способностям ученика) можно уже сегодня.


Минимальные компетенции для такого проекта:

15. Платформа
-- Системный инженер (архитектор) и его команда (разработчики платформы)
-- Менеджер
-- Организатор частного образования (специалист по бизнес-моделям, массовому обслуживанию и т.д.)

17. Разработка учебных модулей
-- Специалисты-предметники по каждой дисциплине (могут вообще ничего не знать о педагогике, но должны хорошо знать дисциплину и связанные с ней практики)
-- Модельеры (онтологи, логики и т.д. -- специалисты по работе с формально выраженными знаниями: представление знаний, алгоритмы работы со знаниями и т.д.)
-- Программисты учебных миров (интерфейсы, среды исполнения -- language workbench)
-- Нейролингвистические модельеры (обнаружение затыков, их моделирование -- пополнение библиотечки, такой хитрый knowledge aquisition вполне в духе нелперов: знание о незнании)
-- Дидакты: придумывание способов объяснения, придумывание упражнений, придумывание учебных миров
-- Спецы по презентации, инфографике и т.д. (ибо дидакты сами рисовать не умеют)

Бизнес-модель:

16. Не обращаться к государству -- ни за лицензированием, ни за сертификацией, ни за деньгами. Частные решения якобы государственных проблем вполне возможны. Так, проблема сертификации была решена уже неоднократно: можно условно говорить об "уклонах" (математическом, алгоритмическом, музыкальном и т.д.) и "уровнях" на этих уклонах -- и дальше решать вопрос так, как это делают сейчас почти любые MMORPG.

17. Продукт может быть необязательно русскоязычным. Но нужно понимать, что локализация будет весьма и весьма непохожа на локализацию программных продуктов.

18. В принципе, целевая система чем-то похожа на DisciplineStore (по примеру AppStore, которые были открыты по примеру iTunes). Дисциплины при таком подходе -- это один из типов медиа (стрим объяснений и задач). Напомню, что в проекте STEPs отрабатывается идея, что исполняемый код -- это один из типов медиа, и его можно использовать при верстке "активных эссе".

19. Использовать "генератор бизнес-моделей" и тамошние паттерны для первых прикидок. Так, можно подумать, как торговать учебными модулями, как торговать платформой, на какие сегменты образовательного рынка можно с этим выползать (или создавать новые сегменты), политику ценообразования и т.д.
* * *
Я понимаю, что этот текст практически непонятен тем, кто не следит за моими публикациями. Каждую строчку в нём нужно бы расшифровывать, снабдить ссылками (хотя бы на мои постинги) -- но у меня, если честно, сейчас просто нет на это времени. Ценность для меня этого текста в том, что я попытался соединить тут мои рассуждения о технологиях образования с пониманием возможнстей их поддержки современными информационными технологиями, плюс выразить это в модной сейчас форме "венчурного проекта".

Проект получается очень сложный (хотя бы по набору помянутых в нём множества технологий, часть из которых далеко не вышла из исследовательской стадии, поэтому "венчурность" тут просто зашкаливает -- ну, и сложности сбора минимальной работоспособной команды проекта), и чтобы его как-то двигать с заметной скоростью, нужно бы бросить любимую работу консультанта, и заняться этим проектом full time -- на что я пока не готов. С другой стороны, фирма у меня называется TechInvestLab, и была когда-то задумана ровно для стартов подобных проектов (каковых некоторое количество и произошло в разной форме и разного размера). Так что будем это пока считать моими личными заметками "для памяти" в Лабораторном Журнале, а там посмотрим.