Правило 11. Осторожнее со стандартами и фреймворками

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

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

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

Речь не о промышленных стандартах типа TCP/IP, OAuth 2.0, SQL языке и так далее.

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

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

Для начала небольшой пример полезной стандартизации. Я получил классическое инженерное образование в авиационной отрасли и однажды столкнулся с такой интересной задачей, как стандартизация испытаний реактивных двигателей между Россией и Европейским союзом, назовём его “Гусиный тест”.

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

К счастью, на тот момент стрелять в двигатель замороженными тушами уже перестали, а проблема была в том, что туши гусей были разного веса. Я не помню точного веса, но допустим, мы использовали гусей весом 2.2 килограмма, а в Евросоюзе гуси были 2.7 килограмма. То есть гуси в Европе были жирнее наших гусей, ситуация казалась комичной, ну подумаешь, гуси жирнее на полкило, что в этом такого?

Те, кто помнит школьный курс физики, помнят, что сила вычисляется по формуле:

Сила = масса * ускорение

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

Совсем другая ситуация складывается со стандартом, когда вам говорят: “Рождённый ползать – летать не может”.

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

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

Наиболее известные фреймворки:

Святослав Котусев в своей книге “The Practice of Enterprise Architecture” (которую я упоминал в своём посте Навыки архитектора) провёл масштабное исследование компаний, которые якобы используют TOGAF, а некоторые даже имели соответствующие сертификаты.

По результатам исследований оказалось, что фреймворк используется только на бумаге, а реальная практика сильно отличается от описанного во фреймворке.

Первая опасность фреймворка реальная практика всегда расходится с реальной жизнью, вам придётся — подгонять практику под стандарт.

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

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

Соответствие фреймворку будет виртуальным, а вот куча потраченного ресурса и отставание по проектам — реальным.

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

Эти люди с лозунгом “deus vult” (это TOGAF, перевод автора) начинают беспощадно внедрять этот стандарт в организацию только с одной целью — как можно быстрее и дешевле проходить процесс регулярной аттестации. Их совершенно не волнует, что фреймворк не применим, что артефакты избыточны или что вы делаете по-другому и так эффективнее. Они будут заворачивать все ваши артефакты, ссылаясь на стандарт, жаловаться на вас руководству, включать эти требования вам в KPI и тормозить реализацию ИТ-решений.

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

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

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

А в один прекрасный день вышла новая версия фреймворка, в которой авторы “significantly improved framework”, переделав его весьма существенно, и наша работа накрылась крышкой гроба.

Последняя опасность кроет в себе появление инквизиторов — людей, которые наделяются полномочиями следить за соблюдением стандартов и наказывать за отхождение от таковых.

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

И вот приносишь ты этот чертёж, с указанием всех размеров, вырезов, выносок и так далее. А преподаватель даже толком не взглянув на чертёж, говорит тебе: «У вас рамка не по ГОСТу» — и перечёркивает чертёж ручкой. И часы твоей работы коту под хвост, а ведь и чертёж, и рамка сделаны карандашом, и исправить было вопросом пяти минут. Да и насколько рамка важна в свете самого инженерного решения, на которое ушли усилия инженера? Нам хотя бы не приходилось придумывать агрегаты, а рисовать готовые. Нам говорили, что так делают для того, чтобы мы научились хорошо проектировать. Но лично я ничему, кроме презрения к крючкотворцам, не извлёк.

Я столкнулся с такой ситуацией совсем недавно уже в ИТ-ванильном мире, где в коммерческой компании внедрена методология проектирования. Несоблюдение цвета рамочек, вложенности функций, несвоевременное прикладывание презентаций — и всё, получайте бан и не допуск на смотрины. Хотя, по моим наблюдениям, презентации никто не смотрит заранее, приложить их нужно за два дня до заседания. Но если их смотрят заранее, почему блокирующие вопросы/замечания не отправляются так же оффлайн автору? Почему нужно онлайн рассказать суть решения и получить замечание из серии: «У вас не тот уровень вложенности, эта способность должна быть поверх другой», после чего отправиться на доработку? А возможность выступить повторно у вас будет только через неделю, во время следующего заседания.

Вот так просто и без затей вы потеряли неделю времени в проекте, просто за несоблюдение нотации, которая может сводиться к личному мнению инквизиции.

И такие потери можно нести на разных уровнях, разных согласующих органов и комитетов.

Правила и стандарты нужны для борьбы с хаосом неопределённости, но, как говорил персонаж одной игры: «Правила не должны становиться клеткой для интеллекта».

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

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

Никогда не отдавайте выбор фреймворков и стандартов в руки теоретиков, иначе вы очень быстро получите отделение святой инквизиции в своей компании и будете «гореть на её кострах».