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

Редко можно встретить ИТ-подразделение, которое более-менее долго придерживалось бы одних и тех же принципиальных положений. Я не хочу сказать, что такие положения не требуют коррекции — она бывает просто необходима, — но всеми изменениями нужно управлять так же, как и любым другим процессом жизненного цикла, а не вносить их наобум или вовсе забывать о них.

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

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

Еще больше усложняет дело то, что разработчики испытывают самое настоящее раздвоение личности, когда речь идет об архитектуре. С одной стороны, они желают работать с самыми современными и наилучшими технологиями, а с другой, им не очень-то хочется отказываться от того, что уже освоено (или они думают, что освоено).

Иногда подобные антагонизмы сталкиваются в рамках одного и того же проекта, в результате чего на выходе мы получаем настоящую мешанину старых (порой даже не поддерживаемых) и новых (зачастую непроверенных) технологий. А такая работа проектировщиков отнюдь не добавляет счастья тем, кто обеспечивает оперативную поддержку систем.

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

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

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

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