Понятие архитектуры системы

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

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

· стабильно низкая надежность системы в целом;

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

· текущая работа пользователей требует постоянного участия программиста;

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

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

Согласно [8] архитектура системы — это «...фундаментальная организационная структура, воплощенная в компонентах системы, их взаимоотношениях между собой и с окружением, и принципы, управляющие ее построением и эволюцией». Когда бизнес отторгает ИС, он отторгает не просто какой-то её компонент, а всю логику построения системы, то есть архитектуру. Если же бизнес принимает архитектуру ИС, то она быстро становится необходимой его частью. В этом случае ИС эффективно функционирует и легко адаптируется к изменениям бизнеса даже в отсутствие разработчика.

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

Для того, чтобы подойти к разрешению этих проблем, необходимо преодолеть один методический барьер. Если мы смотрим на провал ИТ-проекта глазами его участников - пользователя, подрядчика или производителя, то наш анализ неизбежно пойдет по проторенной колее с выяснением, «кто виноват и что делать». Каждая сторона обязательно найдет частное решение, что нужно делать с «сырой» системой производителя, с «кривыми руками» подрядчика или с «необузданными требованиями» пользователей заказчика. Но чтобы понять, почему в разных проектах эти частные решения участников оказываются удивительно похожими друг на друга, нам надо выйти за границы этих участников и посмотреть на ИТ-проект со стороны. Только тогда мы сможем увидеть, что результат в большей степени зависел от некоторых объективных законов отбора ИТ-решений и в меньшей — от личных качеств исполнителей. Однако сменить здесь точку зрения так же сложно, как в живой природе хищнику или жертве взглянуть на себя глазами беспристрастного биолога.

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

Долгосрочная устойчивость архитектуры обеспечивается не только надежностью бизнес-приложений и зрелостью заложенных в них технологий, но и стабильностью определенных бизнес-условий. В работе [9] описаны такие ключевые условия:

· уровень централизации принятия решений и делегирования полномочий;

· уровень предметной квалификации конечных пользователей и руководителей;

· степень упорядоченности и изменчивости операционных технологий бизнеса;

· масштабы использования данных при принятии решений.

Перечисленные условия складываются независимо от участников ИТ-проекта, и их изменение может объективно привести архитектуру всей или части КИС в неустойчивое состояние.

Дата добавления: 2014-11-06; просмотров: 278; Нарушение авторских прав

Мы поможем в написании ваших работ!