Anatoly Levenchuk (ailev) wrote,
Anatoly Levenchuk
ailev

Выбор архитектуры информационной системы

[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, она надстраивается над текущей инфраструктурой, она устанавливается "задарма" разным службам? Сколько организационных/менеджерских/консультационных усилий потребуется для того, чтобы "пропихнуть" новую технологию?

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

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

Содержательного рассмотрения по указанным мной пунктам обычно не избежать, если относиться к делу честно. А оформить результаты обсуждения -- возьмите любой понравившийся вам или вашему начальству метод...
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

  • 13 comments