?

Log in

No account? Create an account
Лабораторный журнал -- Day [entries|friends|calendar]
Anatoly Levenchuk

[ website | Лабораторный журнал ]
[ userinfo | livejournal userinfo ]
[ calendar | livejournal calendar ]

Выбор архитектуры информационной системы [03 May 2011|03:49pm]
[UPDATE: переработанная версия этого текста в приложении к СУЖЦ вошла в текст http://ailev.livejournal.com/929655.html ]

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

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

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

Вот мои тезисы о критериях для архитектуры крупной информационной системы:

1. Расшитие ограничений поддерживаемого workflow: как увеличить "проход" (либо сократив время для текущего объема денег/комплектующих, либо увеличив объем -- если, конечно, этот дополнительный объем можно как-то гарантировать извне).
Главные критерии (увы, их тоже много) связаны со скоростью протекания поддерживаемых системой workflow. Ежели в жизни ничего не ускорится, то архитектура непригодна. Это главные функциональные критерии: будет ли система работать, т.е. увеличивать проход в объемлющей ее системе деятельности. Речь идет об использовании теории ограничений Голдратта (TOC, theory of constraints) -- можно оценить увеличение "прохода" (throughput) от снимаемого ограничения. Вполне возможно, что предлагаемая архитектура снимает ограничение не на критическом ресурсном пути (не путать с критическим путём) -- тогда такую систему вообще не нужно делать.

Обратите внимание, ROI не является главным критерием (ибо содержательно рассмотреть ROI никто не знает, как. Поэтому оставим ROI желающим оформить результат содержательного рассмотрения).

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

2. Возможность инкрементального жизненного цикла разработки информационной системы. Инкрементальным в ISO 15288 называется такой жизненный цикл, при котором функциональность пользователю выдаётся не сразу вся, а постепенно -- но и вложения в разработку тоже делаются постепенно (ага, в том числе учитывая закон убывающей полезности: каждый инкремент обходится всё дороже и дороже, а пользы от него всё меньше и меньше, пока разработка не затухнет сама собой). Если выясняется, что нужно вбухать много-много денег, и сразу получить 100% пользы через пять лет "под ключ", то это совсем плохо. Если выясняется, что нужно разработать и ввести в эксплуатацию какое-то компактное ядро, и далее много-много однотипных модулей с понятным механизмом их разработки, то это очень правильно. Это не совсем про agile, это часто определяется архитектурой и задаваемой этой архитектурой модульностью и/или технологией.

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

Я тут не имею ввиду ICM (incremental commitment model), хотя смысл тут такой же: лучше та архитектура, при которой можно получить какую-то рассрочку платежей за систему, а нужную для увеличения прохода функциональность получать как можно раньше.

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

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

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

Это очень хитрый пункт: если его хорошенько раздуть "коэффициентами", то экскаватор в отдел землекопов, а также автомобиль в отдел гужевого транспорта никогда не будут заказаны.

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

4. Масштабируемость. Поскольку вы хотите, чтобы системой пользовались, она должна будет быстро расти. Насколько "пилот" или "полигон" смогут вырасти? Скорее всего, они вырасти не смогут. Поэтому нужен не "пилот" или "полигон", а "первая очередь". Это тесно пересекается с требованием инкрементальности, но чуть-чуть другой аспект -- не столько растяжка по времени, сколько растяжка по накрываемому объему. Тут два основных вопроса:
а) насколько резиновое решение в плане объема прогоняемой через него информации? Опыт показывает, что на тестовых объемах справляются все системы, а на промышленных -- не справляются. Как нелинейно будет расти стоимость аппаратуры и софта при росте объемов/скорости?
б) нет ли какой-нибудь гадости типа небольшой цены на лицензию на каждое рабочее место, на котором нужно будет установить доступ к системе, или небольшой цены на каждое новое соединение на сервере? Вполне может быть, что более-менее симпатичное решение для 10 рабочих мест резко станет неподъемным для 1000 рабочих мест.

5. Организационные проблемы, в том числе отношение к любимым legacy-системам в расширенной организации. Как много архитектура потребует "отдавать функций", "отдавать данных" и вообще чего-то "отдавать" по сравнению с текущей ситуацией? Мейнфреймы, как мы помним, массово проиграли соревнование мини-компьютерам, а те -- персоналкам. Назад (к централизованным системам) пути почти нет, ибо всё legacy software работает, и данные лежат там. Вытащить данные из legacy в новые системы почти нереально. Как устроена архитектура: она замещает legacy, она надстраивается над текущей инфраструктурой, она устанавливается "задарма" разным службам? Сколько организационных/менеджерских/консультационных усилий потребуется для того, чтобы "пропихнуть" новую технологию?

Этот пункт тесно связан не только централизацией/децентрализацией, но и с рассмотрением системы мотивации в расширенном предприятии, т.е. его оценка далеко выходит за рамки рассмотрения целевой информационной системы.

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

Содержательного рассмотрения по указанным мной пунктам обычно не избежать, если относиться к делу честно. А оформить результаты обсуждения -- возьмите любой понравившийся вам или вашему начальству метод...
13 comments|post comment

OpenQwaq -- промышленный виртуальный мир теперь бесплатен [03 May 2011|08:00pm]
Teleplace (http://www.teleplace.com/) сегодня учудил праздник: опубликовал для свободного пользования платформу OpenQwaq -- одну из самых мощных промышленных платформ для виртуальных 3D-миров. Промышленных -- это которые гораздо круче, чем Second Life.

Собственно, публикация OpenQwaq (в девичестве -- OpenCroquet) тут только половина истории. Вторая половина -- это выпуск очередного коммерческого продукта, Teleplace Connect, представляющего собой помесь виртуального мира и MS SharePoint (плюс обещание и дальше смешивать в этом мире другие корпоративные приложения).

Куда оно всё катится в TelePlace? К поддержке синхронной коллаборации, "погружению" в синхронную работу (в отличие от асинхронных асек, issue trackers, форумов и прочих). Обоснование этого подхода, вместе с жесткими фразами типа "At its core, the Facebook experience is a clever amalgamation of voyeurism and narcissism" вот тут: http://teleplace.wordpress.com/2011/05/03/moving-immersive-collaboration-forward/

А пока наслаждайтесь, выкачать OpenQwaq под GNU GPL v2 можно тут: http://code.google.com/p/openqwaq/.
2 comments|post comment

Об Moshidora и "Ивановские ситцы" [03 May 2011|10:14pm]
Moshidora (http://www.animeultima.tv/watch/moshidora-english-subbed-dubbed-online/, анонс был тут: http://ailev.livejournal.com/927113.html) представляет из себя по стилю типичный текст типа "Ивановские ситцы". Цитируется пара строчек из описания метода (учебника/регламента), а затем показывается пример из жизни. Вот так просто -- и, замечу, такой способ подачи материала отличается от просто "производственного романа" (типа той же голдратовской "Цели"), в котором не цитируется метод.

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

Альтернативный стиль -- это наши обзоры (которых немало на http://prompolit.ru), в которых текст метода перемежался выделенным курсивом и отступом текстом примеров. Но сквозного примера там не было, поэтому при таком стиле подачи показать целостность применения метода трудно -- повесть не заменяется набором анекдотов.

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

Еще важно то, что пример в случае Moshidora писал/рисовал не сам Друкер (как и "Ивановские ситцы" писали не те консультанты, которые разрабатывали приватизационные постановления).
1 comment|post comment

navigation
[ viewing | May 3rd, 2011 ]
[ go | previous day|next day ]