Достижимость стандартов

Оптимальный уровень детализации и распределения усилий в процессе создания Архитектуры предприятия

Как же на практике реализуется "самый нижний" уровень ИТ-архитектуры предприятия, связанный непосредственно с определением инфраструктуры ИТ? Принимая во внимание наличие детально разработанных стандартов открытых систем, их "привлекательность" и "обоснованность" со стороны многих международных, национальных и некоммерческих организаций по стандартизации, можно было бы ожидать, что за прошедшие с их появления примерно 10 лет большая часть окружающих нас информационных систем должна бы полностью соответствовать их принципам.

Увы, в действительности этого не наблюдается. Основные причины заключаются в том, что, с одной стороны, эти стандарты не являются необходимо полными, а с другой – производители программных и аппаратных средств реально далеко не всегда выпускают взаимозаменяемые продукты, даже когда они (частично) соответствуют одним и тем же стандартам. Дополнительным фактором может являться значительное время, которое требуется для согласования и утверждения стандартов. Поэтому многим предприятиям приходится выбирать ограниченное количество вендоров и в дальнейшем руководствоваться совместимостью с данными технологиями.

Следствием такого выбора становится тот факт, что принцип "единства архитектуры" перестает быть абсолютным. В ряде случаев оказывается, что определенное отклонение от установленных принципов может быть обосновано. Например, предприятие могло бы выбрать СУБД Oracle и UNIX-платформу для ведения основных производственных баз данных, требующих высокой производительности и надежности. Но для реализации решаемой в течение одного месяца задачи ввода данных из архивов вновь приобретенной компании вполне могут использоваться более простые и дешевые средства. Другим примером может служить применение готового, существующего на рынке, приложения для решения частной задачи одного из бизнес-подразделений. Даже если это приложение будет использовать другую СУБД, отличную от той, которая определена в стандарте предприятия, практически во всех случаях стандарт будет либо проигнорирован, либо пересмотрен. В любом случае, нужно также учитывать и факторы инвестиций и времени, необходимых для перехода к единой архитектуре в масштабе предприятия. При этом, как правило, чем более жесткие ограничения накладывает архитектура предприятия, тем менее она становится полезной на практике.

Означает ли это, что на самом деле все приводимые ранее аргументы в пользу наличия архитектуры бесполезны? Ни в коей мере. Потенциально преимущества всегда могут быть достигнуты, вопрос только в нахождении оптимального компромисса между преимуществами и усилиями, потраченными на определение и достижение целевой "идеальной" архитектуры.

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

Дата добавления: 2013-12-13