Цель - выявить взаимозависимость между разнообразием условий бизнеса и используемых в нём КИС-архитектур. Как показывает анализ, количество устойчивых бизнес-конфигураций невелико и каждой из них соответствует определенная архитектура КИС.
Если ошибки в ИТ-проектах уже не первый десяток лет повторяются с завидной регулярностью, то это значит, что они имеют объективные причины. То есть за провалами стоят не столько субъективные проблемы участников работ, сколько объективные закономерности естественного отбора ИТ-решений. Бизнес отторгает информационные системы либо еще на этапе их внедрения, либо в ходе эксплуатации. Вот несколько признаков надвигающегося отторжения:
· стабильно низкая надежность системы в целом;
· небольшие изменения функциональности одной системы сопровождаются лавиной доработок в решениях, связанных с нею;
· текущая работа пользователей требует постоянного участия программиста;
· поддержка ИС в режиме эксплуатации превращается в бесконечный проект, пожирающий рабочее время сотрудников и материальные средства компании.
Большинству разработчиков информационных систем хорошо известно, что это признаки самых трудноразрешимых проблем - архитектурных, неизбежно порождающих неуправляемый рост затрат и отрицательный бизнес-эффект.
Согласно [8] архитектура системы — это «...фундаментальная организационная структура, воплощенная в компонентах системы, их взаимоотношениях между собой и с окружением, и принципы, управляющие ее построением и эволюцией». Когда бизнес отторгает ИС, он отторгает не просто какой-то её компонент, а всю логику построения системы, то есть архитектуру. Если же бизнес принимает архитектуру ИС, то она быстро становится необходимой его частью. В этом случае ИС эффективно функционирует и легко адаптируется к изменениям бизнеса даже в отсутствие разработчика.
Существует множество методологий проектирования и внедрения ИС, которые устанавливают стандарт и технологию формирования бизнес-требований, а также способы их реализации в рамках бизнес-приложений. Эти методологии показывают, как правильно проектировать и внедрять, но ничего не говорят о реально получаемых результатах. Ни одна из них не объясняет, почему при огромном разнообразии бизнес-требований и реализующих их бизнес-приложений разнообразие устойчивых архитектур оказывается слишком малo.
Для того, чтобы подойти к разрешению этих проблем, необходимо преодолеть один методический барьер. Если мы смотрим на провал ИТ-проекта глазами его участников - пользователя, подрядчика или производителя, то наш анализ неизбежно пойдет по проторенной колее с выяснением, «кто виноват и что делать». Каждая сторона обязательно найдет частное решение, что нужно делать с «сырой» системой производителя, с «кривыми руками» подрядчика или с «необузданными требованиями» пользователей заказчика. Но чтобы понять, почему в разных проектах эти частные решения участников оказываются удивительно похожими друг на друга, нам надо выйти за границы этих участников и посмотреть на ИТ-проект со стороны. Только тогда мы сможем увидеть, что результат в большей степени зависел от некоторых объективных законов отбора ИТ-решений и в меньшей — от личных качеств исполнителей. Однако сменить здесь точку зрения так же сложно, как в живой природе хищнику или жертве взглянуть на себя глазами беспристрастного биолога.
Поменяв позицию с участника на внешнего наблюдателя, мы неизбежно переходим от субъективных оценочных понятий «успех/провал» к понятию, основанному на фактах, - «устойчивости» решения. Решение будем считать устойчивым, если в долгосрочном периоде небольшие изменения бизнеса не приводят к отторжению этого решения.
Долгосрочная устойчивость архитектуры обеспечивается не только надежностью бизнес-приложений и зрелостью заложенных в них технологий, но и стабильностью определенных бизнес-условий. В работе [9] описаны такие ключевые условия:
· уровень централизации принятия решений и делегирования полномочий;
· уровень предметной квалификации конечных пользователей и руководителей;
· степень упорядоченности и изменчивости операционных технологий бизнеса;
· масштабы использования данных при принятии решений.
Перечисленные условия складываются независимо от участников ИТ-проекта, и их изменение может объективно привести архитектуру всей или части КИС в неустойчивое состояние.
