Архитектура бизнеса и ИТ

Аннотация

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

Введение

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

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

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

Согласно ANSI/IEEE [1] Архитектура системы – это "фундаментальная организационная структура системы, воплощенная в ее компонентах, их взаимоотношениях между собой и с окружением, и принципы, управляющие ее построением и эволюцией". Когда бизнес отторгает ИС, отторгает он не просто какую-то компоненту ИС, а всю логику ее построения, то есть архитектуру. Если бизнес принимает архитектуру ИС, то она быстро становится необходимой частью бизнеса. В этом случае ИС эффективно функционирует и быстро адаптируется к изменениям бизнеса, даже в отсутствие своего автора.

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

В дальнейшем мы будем рассматривать не отдельные, пусть и крупные ИС, состоящие из множества бизнес приложений, а единую Корпоративную Информационную Систему (КИС) как комплекс всех ИС обеспечивающих поддержку бизнеса компании. КИС может включать бизнес приложения разного уровня сложности от MS Ecxel до полномасштабной ERP системы.

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

Естественность отбора

Для того, что бы решить эту задачу необходимо преодолеть один методический барьер. Если мы смотрим на провал ИТ проекта глазами его участников: пользователя, подрядчика или производителя, то наш анализ неизбежно пойдет по проторенной колее “Кто виноват и что делать”. Каждая из сторон обязательно найдет частное решение: что делать с “сырой” системой производителя, “кривыми руками” подрядчика или “необузданными” требованиями пользователей заказчика. Но для того, что бы понять почему в разных проектах эти частные решения участников оказываются удивительно похожи друг на друга, нам надо выйти за границы этих участников, и посмотреть на этот ИТ проект со стороны. Только тогда мы сможем увидеть, что результат зависел в большей степени от некоторых объективных законов отбора ИТ решений, и в меньшей – от личных качеств участников. Сменить точку зрения на провал проекта также сложно, как в живой природе хищнику или жертве взглянуть на себя глазами безпристрастного биолога.

Меняя точку зрения с участника на внешнего наблюдателя, мы неизбежно переходим от субъективных оценочных понятий “успех/провал” к понятию, основанному на фактах – “устойчивости” решения. Решение будем считать устойчивым, если в долгосрочном периоде небольшие изменения бизнеса не приводят к отторжению этого решения.

Долгосрочная устойчивость архитек�