Общее впечатление — конференция гниловата, в отличие от AgileDays. Живых докладов мало, выбирать конкретно приходилось не по принципу интересующей темы, а по принципу живого доклада. Хотя, может, я пристрастен…

Доклады, которые слышал, можно разделить на три группы.

• Собственно, про архитектурные решения в том или ином виде.
• Про великую и прекрасную архитектуру вообще и ее описание.
• Про конкретные продукты, который можно использовать — от вендоров этих продуктов.

Собственно, в этом порядке и буду делиться впечатлениями.

А еще я выиграл сертификат на 12 часов online-курсов в Люксофт до 31.03.10. Если кому нужен — у HR.

В эту группу попадает четыре доклада из числа услышанных.

• Михаил Заборов. Аналитические планы счетов как архитектурный артефакт
• Дмитрий Завалишин. Архитектурные детали ОС нового поколения Phantom
• Дмитрий Завалишин. Архитектура высоконагруженных java-приложений (отчасти условно)
• Сергей Горицкий. Использование MS BizTalk Server для разработки приложения с потоковой, сервисо-ориентированной архитектурой для реорганизации работ предприятия.

По словам Игоря Беспальчука, о том же должно было быть «Сергей Ваганов. Tree в одном. ОС, метод, архитектура», но он пересекся с докладом Заборова, так что не знаю.

Михаил Заборов. Аналитические планы счетов как архитектурный артефакт

Безусловно, сильно отличается от всех докладов конференции. Единственный, где был представлен реальный шаблон архитектуры, использованный более чем в одном проекте, как артефакт. Слушали заинтересованно, задавали вопросы. Но доклад был последним, с 16:35 — много народу сочло, что рабочий день уже можно закончить и просто ушли.

Доклад пересказывать не буду. В целом — очень хорошо получилось, не только на фоне данной конференции, а в целом.

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

Дмитрий Завалишин. Архитектурные детали ОС нового поколения Phantom

Это проект новой, с чистого листа разрабатываемой ОС. На отличных от Unix принципах. Есть ли принципы у Windows, я не знаю, но. возможно, они примерно туда мигрируют…

Идея — приложения живут вечно, то есть вечно открыты. Система обеспечивает их прозрачное сохранение в виде консистентного образа памяти, причем в случае сбоев восстанавливается имеющийся консистентный слепок. В такой архитектуре становятся не нужны файлы — вообще, разве что как вид транспорта данных. А весь диск тоже превращается в одну большую память.

Возникают интересные эффекты — сборку мусора начинает работать не только в памяти, но и на диске, в том числе — удаляя всякие временные файлы (вернее, аналогичные им объекты), старые версии приложений и тому подобный мусор :). Сменные носители можно рассматривать как транспорт, либо как образ памяти отдельных «компьютеров», для которых включается свой версия ядра.

Правда, со сборкой мусора на терабайтном пространстве есть проблемы, но тут помогает то, что у нас есть консистентный snapshot, а мусор — он не может стать нужным. Поэтому собирать в фоне можно на нем, и это не будет влиять на текущую производительность. если ресурсов в целом достаточно.

Правда, аппаратные ресурсы при перезагрузке теряют свое состояние, их сохранить нельзя. Но это проблема драйвера, и архитектурно обеспечивается обязательность решения: ресурсы к аппаратному обеспечению предоставляются как пограничные объекты, которые заведомо пропадают при перезагрузке, и драйверы должны обрабатывать соответствующие исключения. Плюс — такая архитектура хорошо поддается автоматическому тестированию.

Вторая идея — защита не на уровне процесса, а на уровне объекта, объекты и ссылки на них можно легко передавать между приложениями. Включая передачу по сети и организацию прокси-объектов. Правда, это порождает задачу сборки мусора уже в рамках совокупности компьютеров, но это тоже решаемо…

Проекту примерно год. Нынешнее состояние — ядро в целом как-то работает на эмуляторе в Windows и почти запустилось на голом железе (проблемы драйверов), есть основные драйверы, есть некоторое GUI (TinyGL), в каком-то виде TCP-стек, есть ограниченное портирование байт-кода JVM в байт-код этой машины. Планы — запуститься на железе, обеспечить OpenGL и поддержать JVM в хорошем объеме, избавиться от остатков GPL-лицензии и выложить все в OpenSource, но под другой лицензией.

Все. Вполне интересно. Хотя пошел потому, что альтернативы — гнилые.

Дмитрий Завалишин. Архитектура высоконагруженных java-приложений

Тот же автор, что и проект ОС Phantom. Пошел потому, что тяжело было с альтернативами.

Основная мысль — надо думать. Потому что язык многое делает за тебя, скрывает сложность конструкций. Но если не думать — то приложения будут медленные. У них — позитивный опыт, в том числе — система судовождения Gardemarine, которая должна жить в realtime независимо от сборки мусора и прочего самочувствия системы. Ну и детали — где именно надо думать. И местами — как они преодолели трудности. Например, отрисовку фона с градиентами — через кеш, который встроили на базовом уровне в отрисовку, а не в конкретный объект. Хотя лично я бы просто убрал градиенты — но стремления эстетов — понятны.

Сергей Горицкий. Использование MS BizTalk Server

Вроде выступал раньше на других конференциях, но я слушал в первый раз — потому что с альтернативами было трудно. Это начальник IT-отдела на ФГУП Воткинский завод (Искандер, Тополь и многое другое). Производство — уникальное и сложное. И оборонное, поэтому сами разрабатывают модули вокруг Паруса.

Они не могут позволить централизованное решение на СУБД. Моя интерпретация — потому что не получается сделать команду поддержки проекта. Поэтому режим — человек-проект, модули — небольшие. И дальше они пытаются использовать современные технологии интегрирования для их объединения, наступая на многочисленные грабли. Но идут вперед. О чем и был рассказ. Правда, самые большие грабли — не получается у них читать английскую документацию, а по-русски всего очень мало. Но это, во многом, тоже объективные условия — Удмуртия.

Я слышал два проекта. Первый — заявленный в названии, BizTalk. У них быстро получилось взлететь на текстовых файлах. А вот построить взаимодействие через сообщения вместо файлов — почему-то не выходит… Второй — связать несколько модулей через SharePoint. Выставить web-сервисы — получилось быстро, а вот заставить взаимодействовать с помощью какого-то дизайнера бизнес-процессов в VS — не получается. Максимум — один к одному, просто коммутация, а хочется — более сложные схемы. Пока научили нопрямую вызывать сервисы модулей друг друга без SharePoint — так оно работает. Но они борьба продолжается…

Такие вот романтики. В целом — вполне понятно желание выступить, но архитектура…

Из этого заходил только на один доклад — «Александр Хельвас. Adobe LiveCycle. Какие гвозди подходят к этому молотку», опять-таки по отсутствию альтернатив, и слушал частично. Вообще эту секцию проводили в одном из больших залов, но народ шел сильно неохотно, с третьего доклада ее перевели в маленький зал…

Александр Хельвас. Adobe LiveCycle

Рассказывали про решения на основе AdobeReaderExtention. Это как создаешь в этой штуке форму, которую дальше пользователь обычного AdobeReader может заполнять. При этом в форму можно вставить справочники, включая ОКАТО (но это — предел сложности). И проверку логики на JavaScript или чем-то похожем. Анонсируемая область применения — сбор всякой информации, если у отправителя нет доступа к инету. Правда, если формы не тривиальные, то у них должен быть достаточно мощный комп, чтобы все шевелилось. А в российских условиях там, где проблемы с инетом, и компы стоят не новые, типа P3… Передача результата — заполненный xml, который при необходимости можно зашифровать и электронно подписать.

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

А лицензируется все это — на одну изготовленную форму, плюс отдельно — инструмент изготовления.

В целом — неинтересно. Такая примитивная платформа для простых и кривых приложений…

В эту группу попадает три доклада из числа услышанных.

• Олег Боев. Документирование архитектуры ПО: обеспечение потребностей заинтересованных лиц.
• Андрей Вербицкий. Что такое «хорошая архитектура». Субъективные и объективные критерии.
• Дмитрий Безуглый. Как добиться понимания Архитектуры заинтересованными лицами проекта. (Презентация архитектуры)

Олег Боев. Документирование архитектуры ПО: обеспечение потребностей заинтересованных лиц

Был аншлаг. А получился отстой. Докладчик рассказывал про то, как надо описывать по стандартам. Учитывая, что архитектуру — читают разные люди и им нужна разная информация. Показывал ER-схему, где есть система, архитектура, лица, представления (view) для них сделанные с помощью viewpoint — шаблонов, описывающих интересную этим категориям информацию. Эта схема, кстати, была еще у Безуглого, но в более авторсокй интерпретации. а тут — взята из стандарта, причем квадратики большие, а надписи маленькие.

Все это было в таком ужасающе медленном темпе подачи содержательной информации, что я не выдержал и ушел.

Но в начале был перл: «Лучше описывать архитектуру кратко, а то потом замучаешься все это поддерживать». Такая вот авторская интерпретация, почему описание архитектуры должно быть небольшим…

Андрей Вербицкий. Что такое «хорошая архитектура». Субъективные и объективные критерии

Весьма живой и интересный докладчик. В докладе много аналогий программной архитектуры и архитектуры реальной. Выводы — что архитектура определяется не технологиями, что красивое решение не гарантирует хорошей архитектуры, равно как и функциональное. Что архитектура должна учитывать ландшафт, окружение.

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

Говорил о компромиссе между универсальностью и функциональностью — универсальность ограничивает функциональность в конкретных условиях. О том, что сравнивая и выбирая решения надо рассчитывать на послезавтра, когда приложение будет работать: сегодня проектируем, завтра разрабатываем, послезавтра выпускаем. Упоминал ТРИЗ, в частности метод маленьких человечков, принцип Парето.

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

В качестве текущих вызовов архитектуры выделил Identity (единая авторизация и система прав), CRM (ориентация на клиента в самом широком смысле) и SelfCare (самообслуживание клиентов, тоже в широком смысле, когда им доступны те же интерфейсы, что и сотрудникам с точностью до прав). Но конкретика у него не слишком убедительная.

Сожалел по поводу того, что в отличие от реальных архитекторов, программисты не могут посмотреть и пощупать другие успешные решения: нет библиотек, внутри все весьма закрыто. Шаблоны — это да, но это — наработки, а не готовые решения. Тут у него была дискуссия с аудиторией, но она не слишком получилась — все-таки уровень у него и у аудитории был сильно разный.

В целом — интересный взгляд сверху.

Дмитрий Безуглый. Как добиться понимания Архитектуры заинтересованными лицами проекта

Впечатления — смешанные. Не понравилась позиция автора — Гуру, который учит зеленых технарей, определенное высокомерие. Правда, на определенные амбиции он имеет право, это видно из информации (крупный проект — 50 чел, 30 чел-лет, большой бюджет — 2.5 млн$), и вообще из уровня мышления. Но надо уважать слушателей.

Если отстраниться от позиции, то доклад — эклектичен.

Первая компонента доклада — про описание архитектуры в целом. Описание должно быть коротким и не включать большие заумные схемы. И вообще стремление программиста поместить все на одну большую схему — не для презентации. Потом в авторском варианте была ER-диаграмма из стандартов — система, архитектура, лица, представления (view) для них сделанные с помощью viewpoint — шаблонов, описывающих интересную этим категориям информацию. Определения архитектуры и обязанностей архитектора он не дал, хотя из зала хотели. И про описание тоже, была триада

• Проблематизация — выявление проблем,
• Тематизация — набор решений,
• Метафоризация — упаковка решения,

но попытки как-то конкретизировать не получились.

Вторая компонента доклада — о том, что архитектура — это не очередная модная технология или серебряная пуля, она должна быть связанна с потребностями заказчика и отвечать его вызовам по цепочке «Вызовы — Цели — Преимущества — Проект — Архитектура». Почему Вызовы, а не Проблемы? Потому что наличие проблем означает сомнение в качествах менеджера от бизнеса, а он не любит, если в нем сомневаются. Поэтому сейчас и можно говорить, что проблем нет, есть вызовы. При движении по этой цепочке для архитектуры были упомянуты некие Сценарии атрибутов качества, связывающие архитектуру с бизнесом.

Докладчик ссылался на подход Microsoft по поводу продажи архитектуры, вроде, что в презентации должны быть ссылки.

Из зала попробовали зайти с другой стороны — с обязанностей архитектора, указав на то, что связь с бизнесом — это, скорее, бизнес-аналитик. В ответ было пренебрежение бизнес-аналитиком. А определение архитектора он дал вполне интересное: «тот, кто связывает точки зрения».

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

И третья компонента доклада — про подготовку презентации, восприятие. О том, что проект дают под людей, а не под технологии. О том, что надо задействовать все каналы восприятия, потому что 55 % картинки, 30 % слух, 3 % чтение и 12 % соучастие (действие). Стили восприятия — 35 % обсуждение (вопрос почему?), 22 % логика (нужна первичка), 18 % практический опыт, 25 % самообучение. Принципы принятия решений — сфокусированный, логический, креатив, эмоции. Соответственно, когда готовите презентацию, то надо иметь ввиду все группы. Это сложно, но можно, и потому — нужно. Интересный факт, по статистике для обычных людей в 80 % случаев достаточно уверенно сказать «причина есть», можно даже ее не обсуждать.

В целом все.