×

Что нам делать с Enterprise-разработкой

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

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

Сложность

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

Сразу скажу, я не претендую на какие-либо академические познания. Я — обычный руководитель небольшой софтверной компании. Однако я в этом бизнесе давно (уже больше 20 лет) и информацию искать вроде бы умею. Более того — я вообще интересуюсь Computer Science. В любом случае так я вижу ситуацию. Если я ошибаюсь, можете меня поправить — я открыт к новой информации.

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

В бизнесе все еще хуже. Со сложностью здесь никто не борется. Ею даже в чем-то гордятся — у нас тут все так сложно! Более того, если вы придете к вашему руководству и начнете объяснять, что сложность — это плохо, с ней надо бороться, упрощая и стандартизируя все и вся, вам скорее всего скажут: «Ты что, НЕ ТЯНЕШЬ?!». Да, у нас сложно. Но мы СПРАВЛЯЕМСЯ.

Проблема усложняется тем, что Enterprise-приложения растут как трава при дороге — без единого плана и вообще без какого-либо видения общей картины. Нам потребовался вот такой функционал — мы его запилили прямо здесь и сейчас, не думая о том, что этот функционал понадобится еще в нескольких других местах и там его придется либо делать заново, либо банально копипастить. Вынесение чего-либо в общие части (shared services) в большинстве случаев затруднено, так как выходит за пределы компетенции руководителей отделов заказчика — такая часть уже непонятно кем должна сопровождаться. В смысле — была часть системы, относящаяся к компетенции одного отдела и часть, относящаяся к другому отделу. А к чьей компетенции должна относиться общая часть? Уже непонятно.

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

Итак, что же я предлагаю делать с этой проблемой:

  1. Взять цель на упрощение предметных областей, стандартизуя термины и их определения, отбрасывая дублирующие понятия и определяя все термины максимально жестко, без возможности многозначного трактования. Я понимаю, что компании привыкли работать в понятийном хаосе (не верите — почитайте документацию IBM, там ад виден прямо сразу), однако необходимость таких изменений даже не назрела, а перезрела.
  2. Выделение ответственных. Я, как человек, который более 20 лет занят в разработке и более 15 лет руководит программистами, могу сказать точно одно: если для какого-то дела не назначены ответственные, то это дело с места не сдвинется НИКОГДА. И вопрос не в том, что люди плохие. Вопрос в том, что у всех есть своя работа, за которую с них и спрашивают. А за работу по упрощению предметной области, стандартизации, обмену информации и т. д. — ни с кого не спрашивают. Значит никто ею и не занимается, потому что всегда есть более важная работа. Так вот. Надо наконец признать проблему и выделять отдельных специалистов (группы специалистов), отвечающих именно за систему в целом. Только в этом случае мы можем рассчитывать на позитивные изменения.
  3. Поддержание актуальности и полноты архитектурных документов. Если есть на свете что-то, что программисты любят меньше, чем писать юнит-тесты, — так это написание документации. Как часто шутят в Enterprise — программа отлично документирована на языке Java. Так вот, эта ситуация недопустима. Документирование системы должно стать важнейшей частью ее разработки. Архитектурные документы, особенно UML-диаграммы (с любой степенью детализации — от саб-систем до уровня кода) должны быть легко доступны любому разработчику и быть единственным источником информации по архитектуре приложения. Естественно, такой подход потребует разработки массы дополнительных правил и методик. И это дело не одной статьи. Однако начинать этим надо заниматься именно сейчас, а лучше — вчера. А не тогда, когда системы перестанут справляться с нагрузкой.
  4. Стандартизация — одно из самых простых и отлично зарекомендовавших себя средств для борьбы со сложностью и гетерогенностью. Каждый, я думаю, прекрасно помнит, как 10 лет назад, входя в офис, кричали: «А у кого зарядка от маленькой нокии? Нет, плоская не подходит». Ничего, как-то стандартизовались — живем. Всем вроде бы удобнее стало. Меня же, честно говоря, несколько обескураживает то, что в нашей сфере процесс идет в обратную сторону. Вот, например, история интеграции. Вместо стандартной до скрежета зубовного CORBA, пришли более мягкие, но все же стандарты SOAP, а на смену им — REST, про который единственное, что можно сказать: «Это не протокол и не стандарт, а архитектурный стиль». Стиль такой. В смысле «я художник, я так вижу». И если интеграция REST с JS мордой или мобильным приложением выглядит ок (преимущества JSON для этой интеграции очевидны), то участившиеся в последнее время случаи интеграции В2В приложений с помощью REST выглядят совершенно не лучшим вариантом. Ну в любом случае стандартизация — наше все.
  5. Обмен информацией — краеугольный камень решения самых тяжелых и неприятных проблем в разработке. Как показывает моя практика, разработчики крайне редко общаются на производственные темы с коллегами не из смежных проектов. Да и с коллегами из смежных — только по необходимости. Что я предлагаю сделать для исправления ситуации:
    • Кросс-командные митинги. Работа над любым проектом практически не бывает полностью ровной — чаще случается то густо, то пусто. Так вот, было бы хорошо тратить время, когда «пусто» на то, чтобы подготовить короткую презентацию архитектуры и основных технических решений для смежников. И обратиться к ним: «Хотите, мы вам расскажем про свой проект? Коротенько — на час-полтора, больше не надо». А потом попросить, чтобы вам презентовали свой проект. Слушатели будут заинтересованные — в конце концов, всем интересно, над чем работают коллеги из соседней комнаты, тем более если у вас еще есть и интеграция. Можно набраться каких-то знаний по типовым решениям, да плюс еще — блеснуть своими знаниями. Если проводить такие встречи достаточно часто, то обмен информацией внутри компании улучшится в разы.
    • Общие вики. В любой компании со временем накапливаются тонны информации по взаимодействию с легаси софтом заказчика, по правильному использованию сложившейся инфраструктуры с учетом ограничений секьюрити. Неприятно, что большинство этих мелких решений так и остаются в голове того, кто их нашел. Ну максимум — в своей команде. Естественно, такие знания надо аккумулировать и делать общедоступными (в рамках компании, конечно). Как по мне, самое удобное на этот момент решение — это движок вики. Насколько мне известно, во многих компаниях такие вики стоят, однако используются они крайне редко, и информация там бывает уже давно не актуальной. Как обычно, решение такой задачи упирается в отсутствие ответственных. Я бы предложил подчинить вики специалисту (или группе), отвечающему за общую архитектуру (я рассказывал об этом в пункте 1).
    • Обучение корпоративным стандартам. Никакая стандартизация невозможна, если непосредственные исполнители не знают о существовании стандарта. Вообще, я, как специалист по обучению, с грустью вынужден констатировать практически полное отсутствие работы в разработческих компаниях над образованием сотрудников. Обучение, которое проводится, часто делается для галочки, средствами собственных сотрудников и результат назвать, кроме как «из вторпродукта и палок», сложно. А если говорить о собственно обучении корпоративным стандартам... Ой, а они вообще в каждой компании существуют?

Монолитность

Монолитность в последние годы — любимый объект для борьбы (про страсть искать не там, где потерял, а там, где светло, я уже писал). Ну так вот. Тут место, где светло, точнее золотой молоток (прибегая к другой аналогии) нашелся. Это были... вы уже догадались? Да-да. Микросервисы, конечно.

А раз у программистов есть прекрасный золотой молоток — так монолитность тут же объявлена главным злом, и с ней борются, причем нельзя сказать, что безуспешно.

Однако и здесь есть несколько проблем, которые старательно игнорируются. Я бы обратил внимание на следующие из них:

  1. Возникает дополнительная гетерогенность. В большинстве своем на SOA/микросервисы переводят не все Enterprise-приложение, а только небольшую его часть, а чаще всего — только один модуль. В результате монолитность всего приложения никуда не девается (от монолита откусили только маленький кусочек), а вот гетерогенность всей системы увеличилась. Нельзя сказать, что это так уж хорошо. Ну и мы можем прогнозировать, что с появлением новых подходов части проекта, сделанные на SOA/микросервисах так и останутся жить памятниками своего времени, как и кучи наслоений, сделанных на золотых молотках своего времени.
  2. От введения дополнительной архитектуры в проект, сложность всего проекта явно не уменьшится. Более того, само приложение на микросервисах часто оказывается сложнее для понимания, чем монолитное.
  3. Последняя проблема микросервисов и при этом самая важная, на мой взгляд, — такая архитектура не решает проблему монолитности сама по себе. Если архитектура микросервисного приложения не продумана, то на самом деле все проблемы просто поднимаются на сетевой уровень и прячутся от взгляда разработчиков. То есть если раньше разработчики вынуждены были думать над архитектурой хотя бы своего модуля, то теперь, когда модуль распался на кучу микросервисов, над их общей архитектурой можно не задумываться — так как непонятно, кто за все это вообще отвечает. Да, в теории должен отвечать тимлид или архитектор, однако я видел полно команд, где архитектора не было, а тимлид этим не волновался. Ну и все, уже модуль начинает расти как трава под забором, принимая все проблемы, перечисленные в первой статье.

Есть еще несколько менее очевидных и менее важных проблем. Для примера приведу одну. Если вы разрабатываете монолитное приложение, то фактически уже сложился консенсус про совместное владение кодом, и рано или поздно другой программист влезет в кусок кода, который вы написали, и спросит: «А это что за фигня?». С микросервисной архитектурой большинство команд проваливается в кошмар персонального владения микросервисами: когда у каждого сервиса есть владелец, и только он его меняет. В принципе, понятно, к чему это приводит.

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

Мои предложения по борьбе с монолитностью:

  1. Официальное разделение частей бизнеса. Сложно добиться модульности Enterprise-приложения, если оно является полным отражением запутанного, как клубок ниток, бизнеса. В идеале необходимо добиться, чтобы интеграция между частями Enterprise-приложения, относящимися к ведению разных департаментов, происходила точно так же, с такой же глубиной документирования и стандартизацией, как интеграция с внешними системами.
  2. Стандартизация способов интеграции. Вы уже, наверное, заметили, что я предлагаю все стандартизовать. И это действительно так. Если нам необходимо бороться с монстром в виде запутанного клубка взаимодействий разнородных частей, то давайте хотя бы добьемся, чтобы части были относительно стандартные и взаимодействие их было однотипным. Я имею в виду, если у вас все части интегрируются по SOAP, например, то давайте и новую интеграцию сделаем на нем же. Даже если SOAP тут явно избыточен.
  3. Единый реестр микросервисов. Эту идею мне рассказал один слушатель во время выступления. Он сказал, что в их компании считается, что микросервис готов только тогда, когда автор завел его в общий реестр микросервисов компании. С полным описанием — что за сервис, какие у него интерфейсы, что он возвращает и что делает. Идея кажется мне просто гениальной. С одной стороны, сервис описывает сам автор, что предотвращает неверную трактовку (автор-то точно знает, что он написал... я надеюсь на это). Плюс к этому мы достаточно хорошо понижаем риск того, что готовая функциональность будет разрабатываться еще раз. Повышаем реюз готовых сервисов и еще много всякого хорошего. И все это ценой небольшого нытья программистов, что «неохота всю эту ерунду писать». Рекомендую делать также. Меня еще спрашивали: может, лучше сделать систему автоматического дискавера сервисов? Я считаю, что нет, не лучше. Как минимум вы потратите тонну времени на эту систему. Но программисты все равно напишут такой сервис, который будет дискавериться неверно. Плюс к этому — вы не получите комментариев от автора сервиса, а они часто — самое важное.
  4. Даже если вы не хотите вести общий реестр микросервисов, в любом случае необходимо на уровне организации утвердить список необходимой информации, которая должна быть в документации по каждому микросервису.

Гетерогенность

Как я уже писал в первой части статьи, гетерогенность в большинстве случаев игнорируется и часто даже приветствуется как фича, а не баг, а то и ставится в заслугу. У нас тут столько всяких технологий на проекте!

А вообще мы знаем, как программисты борются с проблемой гетерогенности: у нас есть новый золотой молоток (new shining thing, по меткому выражению Роберта Мартина), так давайте все сделаем этим новым золотым молотком. А поскольку сейчас у нас любимый золотой молоток — микросервисы, так давайте все сделаем на микросервисах. Но о проблемах этого решения я писал в прошлой главе, повторяться не буду.

Если проанализировать требования к Enterprise Java разработчикам по вакансиям, то мы увидим, что рынок уже свое слово сказал: ставка на сегодняшний момент сделана на стек фреймворков Spring. Я обычно приветствую любую стандартизацию. Но вот как раз к стеку спринга у меня есть несколько претензий:

  • Спринг навязывает стиль архитектуры. Сделать, например, rich domain model на спринге практически нереально (правда, как и на стеке Java EE). Эта проблема достойна отдельной статьи, если вам интересно, о чем я — напишите в комментариях, я тогда выдам свои мысли по поводу того, как современные Enterprise-стеки фреймворков издеваются над ООП.
  • Spring настойчиво пытается проникнуть во все части приложения. Имейте в виду, если у вас завелся один фреймворк из стека Spring, то скоро все у вас будет на спринге, иначе вы замучаетесь все это увязывать. С одной стороны, хорошо — стандартизация же. А с другой — выглядит, как весьма некрасивый способ конкурировать.
  • Spring становится все более монструозным. Изначально он делался как более простая и легкая альтернатива стеку Java EE. В результате получилось, что Java EE уже в разы проще.

Мои предложения по борьбе с гетерогенностью:

  • Стандартизация используемого софта (включая сервера и библиотеки) на уровне всей системы. Как минимум, если все сервера обновлять в одно и то же время, масса проблем гетерогенности будут решены. Если же стандартизовать еще и используемые фреймворки — станет совсем хорошо.
  • Фокусирование на этой проблеме внимания всего персонала, включая высшее руководство. Это задача, понятно, не для рядовых программистов, скорее — для той самой группы архитектурных решений, о которой я говорю с самого начала.

Интеграция

Проблемы интеграции сейчас рассматриваются как часть проблем гетерогенности, что в общем достаточно логично. Но есть несколько моментов, на которых я хотел бы остановиться отдельно в своих рекомендациях.

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

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

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

Объемы данных

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

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

Как у любого инструмента, у решений Big Data есть и свои проблемы:

  • Внося в большую Enterprise-систему еще и решения на Big Data, мы увеличиваем что? Естественно, гетерогенность. Мы же не можем всю систему переписать на Big Data и не можем стандартными средствами работать с большими данными. Значит в наш зоопарк завезли нового бегемотика.
  • И, естественно, добавляя новый массив решений, мы повышаем сложность всей системы.

Поймите меня правильно, я не против никаких решений. Тем более таких новых, красивых, блестящих, да еще и расширяющих наши возможности обработки данных, как Big Data. Я против бездумного использования чего бы то ни было. И я против того, чтобы в любом инструменте видеть Silver Bullet.

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

  • Как известно, любая база может обеспечить две из трех характеристик: скорость доступа, консистентность и распределенность. Так вот, если реляционные базы данных нам обеспечивают из коробки первые две (скорость доступа и консистентность), то нереляционные — первую и третью (скорость доступа и распределенность). И как вы понимаете, в определенных ситуациях (например, социальная сеть) выгоднее второе, а в Enterprise (где стоимость транзакции может быть и несколько миллионов долларов) — отсутствие консистентности из коробки — просто приговор. Так что каждый инструмент для своей задачи.
  • И как обычно, добавление еще одного зверя в наш зоопарк явно не делает его меньше. В смысле гетерогенность опять растет.

Мои предложения по использованию технологий Big Data:

  • Не каждая задача должна решаться на Big Data. Наоборот — на Big Data должны решаться только те задачи, которые ТОЛЬКО на ней и можно решить. Соответственно, на уровне системы должен быть определен список данных, с которыми мы будем работать инструментами Big Data. Эта часть должна быть четко инкапсулирована и защищена от всей остальной системы четко прописанным интерфейсом интеграции. Чтобы, не дай бог, другие части системы не лазали грязными руками в данные или вызывали не описанные в интерфейсе методы.
  • Нужно для любых данных определить принцип устаревания, чтобы не хранились уже совершенно потерявшие актуальность терабайты не пойми чего, которые можно было заменить просто консолидированными данными. Тут полезно, наверное, вспомнить историю о том, как мы писали систему анализа посещений WAP сайта (да, это было очень давно). Так вот, вся аналитика, которую мы показывали, строилась на основе raw-данных. И делалось это чудовищно медленно, да еще плюс к этому данные забивали нашу реляционную базу. Слава богу, что в тот момент еще не было технологий Big Data, а то мы бы их безусловно использовали. Но это было давно, и мы были вынуждены пойти путем логики, а не грубой силы. И стали в результате вместо грязных данных хранить в базе консолидированные. Мало того, что мы теперь не забивали базу тоннами ненужных грязных данных, так и вся система начала работать практически мгновенно и перестала зависеть от времени накопления данных. К чему я все это? К тому, что иногда надо еще и пытаться обдумать задачу. А не бросаться решать ее в лоб, методом грубой силы.

Общие рекомендации

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

Итак, это своеобразный манифест здравого смысла.

Коммуникации — важнее технологий

Весь мой опыт приучил меня, что если в разработке проблема, то крайне редко это технологическая проблема. Да, так, конечно, бывает, и это благословенный момент, когда программист может развернуться во всю мощь своих сил. Однако в большинстве случаев проблема лежит в плоскости передачи и обработки информации. И как мы знаем по правилу Парето — 20 % усилий дают 80 % результата. Сосредоточиться надо именно на этих проблемах, чтобы получить более существенное улучшение в целом. Если мы посмотрим на список основных причин провалов IT-проектов, то практически все они тем или иным способом относятся к коммуникации между людьми. Вот это и надо исправлять.

Архитектурные решения — важнее используемых средств

Честно говоря, принятие решения о используемом стеке технологий ДО того, как приняты хоть какие-нибудь архитектурные решения, бич современного Software Engineering. Самое неприятное, что, если мы возьмем список тем любой разработческой конференции, мы увидим темы «о новых возможностях фреймворка Х», «использование нового языка Y в ... системах» и «новое API библиотеки Z». Но никогда не увидим «сложные случаи декомпозиции предметной области» или «определение подходящей технологии под готовые архитектурные решения». И надо сказать, что ситуация эта возникла не на ровном месте. Если мы вспомним, например, сверхпопулярный сейчас стек технологий Spring, то увидим, что именно стек технологий диктует нам архитектуру, а не наоборот: мы сможем использовать его на уже построенной архитектуре. И это, по-моему, дорога в тупик.

Стандартизация — важнее идеального соответствия инструмента задаче

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

Напоследок небольшой дисклеймер: я ни в коей мере не претендую на универсальное знание. Тем более на то, что я знаю, как решить все проблемы. Эти статьи — просто описание того, что я лично вижу вокруг себя, и приглашение к разговору: давайте не замалчивать эти темы, а обсуждать их, а не «новые фичи фреймворка Х».

Удачи!

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному1
LinkedIn

Схожі статті




51 коментар

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Картина ентерпрайз-ада не полна без упоминания контейнеров, оркестраторов, тулзов для оркестрирования оркестраторов , и прочего

Картина ентерпрайз-ада не полна без упоминания контейнеров, оркестраторов, тулзов для оркестрирования оркестраторов , и прочего

Вот все что вы перечислили — это модные-стильные-молодежные тулы, которые должны были решить проблемы уныло-энтерпрайзной вебсферы,
но они не решили, а просто заменили вебсверу :)

Точнее — добавили своих проблем к существующим

(зевая) Хорошая статья о космических кораблях, бороздящих просторы Большого Театра.
ИМХО лучше фокусироваться на более конкретной проблеме и расписывать её решение, которое проверенно работает, чем писать абстрактные толмуды об уже известных универсальных решениях уже известных глобальных проблем.

Стаття ні про що. Автор ознайомтесь з такою дисципліною як Enterprise Architecture та відповідальностями Enterprise Architect і не видумуйте своїх велосипедів з квадратними колесами.
На LinkedIn є два десятка статтей від Matthew Kern по Enterprise Architecture для чайників.
Якщо вже хочете так сильно enterprise по методології то TOGAF в зуби і вперед.
Хоча вам достатньо SEI Documenting Software Architecture. Тому що швидше за все вище рівня Solution Architecture вас не пустять.
Дві статті ні про що, змішались коні, люди, в купу. Проблеми рівня бібліотек, мов програмування, технологічних платформ, архітектурних підходів.

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

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

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

Проблема которую вы озвучили — это инфантильность разработчиков (и не только). Эту проблему уже решили, решили способом который озвучил автор — зарегулировали все.
Теперь у нас другая проблема:
Ответственному думаещему специалисту не удобно работать в таких условиях. Поэтому таких людей очень мало в энтерпрайзе и удерживает их там в основном бабло. А бабло — это не лучший мотиватор для хорошего специалиста.

В энтерпрайзе надо как минимум пройти лигал (юристов) чтобы добавить либу.

Оце капець трафляло. Колись було в мене бажання інтегрувати спрінг а у відповідь сказали щось типу «воно по ліцензціям не проходить», довго не розбирались певне. В результаті я таки інтегрував, через пару років :)

Так автор вже відбатрачив на відповідних позиціях якраз в кривавому ентерпрайзі.

Так автор вже відбатрачив на відповідних позиціях якраз в кривавому ентерпрайзі.

И поэтому в двойне удивительно, то что он предлагает решение которому уже лет 20+ как нечто новое.

Чесно кажучи стаття називається «як хреначити enterprise і при цьому нічорта не зрозуміти». Автор в розумінні підходів до розробки залишився максимум на senior engineer з зачатками application architecture. І кількість років тут нічого не дає. Ти можеш продовжувати винаходити велосипед з квадратними колесами, а можеш взяти підходи які вже в 90-х досить добре пророблені.
Якщо взяти рівень нижче solution architecture візьміть наприклад SEI ADD(Attribute-Driven Design) resources.sei.cmu.edu/...​set-view.cfm?assetid=8147 і дитячих питань не виникатиме.
Такі проблеми виникають коли починають спочатку ліпити щось як виходить, людьми які в принципі хороші розробники, але архітектурного мислення і розуміння немає, а потім згадують що це треба якось супроводжувати, інтегрувати.
ADD — починаює з виділення і формалізації потреб бізнесу в IT рішенні, виділяють які атрибути якості ми хочемо досягнути, сценарії використання цих атрибутів, а потім шукають кандидатів на архітектуру. В TOGAF схоже. Про конкретні рішення, технологічний стек, мови, фреймворки, бібліотеки розмова починається лише після достатньої деталізація і розуміння чого з точки зору бізнесу та зовнішньо видимих характеристик системи ми хочемо досягти.
Автор навіть не підозріває про цілий розділ науки який покриває цей напрям мабуть десятком методів від легких до дуже ентерпрайзних і складних. Дуже хороша серія вступу в професію є від Oreilly www.oreilly.com/...​ideo-training-series.html
Про інтеграцію є ціла біблія Enterprise Integration Patterns ще з 2004-го року, де можна прочитати що shared database — це швидше антипатерн. Ну і платформа Java має зо два десятки платформ для інтеграції починаючи від Apache Camel закінчуючи IBM WebSphere.
Було згадано про конференції де не розповідають, так для цього не треба їздити по конференціям для розробників. Архітекторських конф є значно менше вони суттєво дорожчі. Наприклад conferences.oreilly.com/...​ftware-architecture/sa-ny
На InfoQ дуже багато матеріалів.
От наприклад одна з кращих доповідей Simple Made Easy www.infoq.com/...​ntations/Simple-Made-Easy по загальним архітектурним принципам. Порівняйте з кашою в голові і статті автора.
Про комунікацію рекомендую прочитати закон Конвея, це те що згадують у вступі до більшості архітекторських книжок.

Це може бути й не вина автора, в Україні змогли дорости до розуміння що треба виховувати архітекторів в себе і що самі вони не виростуть мабуть до десяти компаній. Ще менше вміють і можуть продавати послуги архітектора. Без цього ви завжди матимете справу з наслідками чиїхось рішень.
А ще те що це enterprise рішення і в нього вкладено надцять мільйонів зелених не значить що рішення будуватимуть з використанням якогось цілісного підходу. «Кускова» автоматизація — це хвороба великих компаній в яких основний бізнес не айті(та й в айті теж). Якщо їм повезло і мають хорошого CIO чи CTO який курує цей напрямок, то буде якийсь порядок, якщо ні, будуть віддавати на зовнішній підряд фіксовані фрагменти без врахування як це рішення буде грати з рештою існуючих рішень та майбутніми потребами. Коли вартість супроводу такого рішення стане зашкалювати наймуть чуваків по оптимізації бізнес-процесів в костюмах з BCG, McKinsey, Accenture які зроблять це по підручнику, або скажуть звільнити всіх нахрін і купити готове рішення зкастомізоване під індустрію. Ті хто пише «кривавий ентерпрайз» від центру прийняття таких рішень зазвичай на дві-три сходинки нижче.

Автор все ж більше веде мову про існуючі системи.
А ви про проектування згідно «рекомендаций лучших собаководов». Можете привести реальний приклад ентерпрайз системи, спроектованої з використанням «цілісного підходу» ?

І що заважає legacy-систему проеналізувати згідно методики і зрозуміти де ми знаходимось? Це якраз те що відрізняє лабухів який аби години відпрацювати від професіоналів. І дозволяє говорити з бізнесом однією мовою.
Більшість урядових систем в США, мінооборони розробляються згідно такого підходу. Я розробляв так і проблем не було.
Часто буває що вам више ролі простого виконавця не передбачено. Але це вже залежить від вашої здатності продавати себе і сейлів вашої компанії. Якщо ваш єдиний контакт лінійний менеджер останньої ланки то швидше за все ви мало що зміните.

"

Більшість урядових систем в США, мінооборони розробляються згідно такого підходу.

" це вони просто вам по вухах проїзжають:), і бюджетному комітету коли їх питають чому так дорого і стає ще дорожче.

це вони просто вам по вухах проїзжають:), і бюджетному комітету коли їх питають чому так дорого

Нет, это они так свои Ж прикрывают, от попадания на штрафы от гос регуляторов или попадания в тюрму.

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

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

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

Висновок швидше ви просто не вмієте його готувати.

Официальное разделение частей бизнеса

вот с этого момента настоящий Апокалипсис и начнется
но зато будет материал для следующей статьи «как не нужно было делать» :-)

В смысле — была часть системы, относящаяся к компетенции одного отдела и часть, относящаяся к другому отделу. А к чьей компетенции должна относиться общая часть? Уже непонятно.

Это так знакомо...

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

Хотелось бы, но получается и дружка кучи фреймворков + и куча бизнес-кода)

У нас пока что тоже, но количество готовых решений растет с каждым годом.

Количество готовых решений автоматически порождает сложность задач сверху)

alistair.cockburn.us/Hexagonal architecture
8thlight.com/...​e-clean-architecture.html

Щоб достягти такого підходу і ізолювати те що потрібне різним фреймворкам, а що вашому застосунку, колись кілька років тому мені дуже добре прочистив мізки підхід Mark Seesman по DI blog.ploeh.dk/2014/06/10/pure-di, хоча краще читати книжку. Коли ти чітко розмежовуєш сутності твоєї предметної області, сутності твого додатку і сутності фреймворку і через власний DI просто фізично не можеш використовувати те що дає DI фреймворку ти починаєш задумуватися як конструювати свій застосунок, що є твоєю предметною областю, а що є черговми фасадом до фрейморку щоб він просто працював.
До речі власне до Java цей підхід слабо дійшов, навіть google guice di занадто багато на себе бере. Spring DI — це взагалі просто набір антипатернів, він гарно виглядає лише в порівнянні з класичним Java EE.

Для работы со сложностью придумана системная инженерия. Так как она не про IT, то, как правило, подобное «непрофильное» знание пропускается мимо ушей (учить все — профи не стать). В итоге, тот кто начинает «подозревать» что со сложностью нужно как то работать, начинает «изобретать велосипед» (искать хорошие/частные рецепты для проблем) или опускает руки (сложность есть сложность, живем дальше как умеем). И лишь изредка доходит до понимания необходимости расширения знаний за пределы «узкой» области.

Власне те що згадує автор покривається базовим курсом по Software Architecture, наприклад SEI Software Architecture: Principles and Practices www.sei.cmu.edu/training/p35.cfm
А архітектура рішень є підгалузю системної інженерії www.linkedin.com/...​re-vs-systems-engineering

Время решает многие вопросы в разработке. Не возможно, как Леонардо Да Винчи, несколько лет возить с собой Джоконду и дописывать по свободе — сроки не позволят. А рациональные решения требуют именно времени: на анализ, на поиск решений, на отладку. Все это создает тот самый недостижимый горизонт, за которым должно быть счастье.

Когда я пытался что-то сказать о том, что проблема имеет решение — меня на смех поднять пытались! И как раз таки по архитектуре.

Когда-то много лет назад я стажировался как экономист на маленьком предприятии, где все летело к чертям. Была куча работы, которую надо было разгрести. Я предложил конкретизировать задачи, вынести их в корпоративный гуглдок и пусть люди сами разбирают и делают работу. Меня тоже на смех подняли. А сегодня у меня на работе такой формат основной, только вместо гуглдока JIRA. Всему свое время и свое общество :)

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

Ну, прямо так и нельзя. Разумеется, сложность в модели данных не уменьшится, но код, если не серьезно упростить, то сделать управляемым и контролируемым в гораздо большей степени — можно.

Ну, вы перекладываете сложности с кода на архитектуру. Это не решает проблемы сложности. Более того, этот код станет писать более сложно, так как он будет ориентирован на более сложную архитектуру.

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

Вещи, которые вы говорите, не особо относятся к сложности системы. Это вроде как «правильный» подход к работе со сложностью.

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

Ну и касательно спешки и лени можно вспомнить былину: bash.im/quote/420672

«разбился на туареге» — греет душу в этой истории! ))))))) Ну, собственно да. Абстрактный конь в вакууме — всем хорош. А реальный срет где попало и может понести. Ищи баланс сам! ))))

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

Документирование системы должно стать важнейшей частью ее разработки. Архитектурные документы, особенно UML-диаграммы

По вашему опыту — документирование системы как вы описываете — такое вообще бывает ?

По вашему опыту — документирование системы как вы описываете — такое вообще бывает ?

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

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

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

Такая «документация» попросту не пересекается с реализацией либо «обобщённо её напоминает».

ХМ

Как известно, любая база может обеспечить две из трех характеристик: скорость доступа, консистентность и распределенность

Если автор о CAP теоремы, то такая характеристика «скорость доступа» для распределнных систем не опредена в ней.
Возможно автор не понял суть термина «Availability» ?

availability — доступность. не скорость конечно

Архитектурные решения — важнее используемых средств
Стандартизация — важнее идеального соответствия инструмента задаче

Повторю свой коментарий к предыдущей статье:
Эти пункты как раз что что делает «кровавый энтерпрайз» «кровавым» :) То есть проблемы вы явно не решили.

Коммуникации — важнее технологий

Классное правило. Оно уже было в одном манифесте, лет 20 назад. От только есть проблемы:
1) В большой организации очень сложно построить коммуникацию. И ИТ тут наименее проблематичная часть.
2) Ваше же пункт про стандартизацию, усложняет комманикацию, он увеличивает количество правил, которые надо обработать. А пункт про архитектруру, добавляет архитекторов — дополнительное звено, которое должно быть вовлечено в коммуникацию.

Есть такая модная манса — Закон Конвея. Из него можно сделать вывод, что проблема этнерпрайза не техническая.

и приглашение к разговору: давайте не замалчивать эти темы, а обсуждать их, а не «новые фичи фреймворка Х».

Какие темы? Если цель была начать диалог, так привели бы понятный список, а не 2 статьи воды. Озвучьте их пожалуйста, возможно они и правду будут интереснее чем новые фичи какого-то фреймворка.

"

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

" — когда ты вовлекаешь архитектора, ты должен отключить от коммуникации 2-3-4-много( много на самом деле нельзя:) ) тимлидов команд, так что выигрыш есть

отключить от коммуникации 2-3-4-много( много на самом деле нельзя:) ) тимлидов команд, так что выигрыш есть

В теории, а на проктике вы сами сказали что «много нельзя». Так вот 3 — это уже много. Плюс уверяю что тимлиды начнут устраивать митинги с целью -понять- угадать «что хотел архитектор и что таки нужно сделать». Так что выигрыша не будет.

Что нам делать с Enterprise-разработкой

Категорично не зв’язуватися і не працювати в кривавому ентерпрайзі де як правило проекти:
— є не реальною необхідністю бізнесу, а результатом роботи сейлзів аутсорсингових і консалтингових компаній, метою яких продажа якомога більшої кілької дупо-годин і отримання маржі, а там хай потоп;
— часто є засобами в політичних іграх топ-менеджменту компанії куди це все вроваджується;
— часто розбиті проміж купи різноманітних компаній (кожна з яких звісно переслідує власні цілі та тягне одіяло на свій бік) що ще більше ускладнює делівері чогось робочого;
— архітектурні рішення спускаються зверху, часто є вендор-локом та не мають відношення до власне задач проекту (ми купили оркал тому тепер все пишемо на ораклі, ми консультанти сапу тому тепер у вас все на сапі і тд);
— можуть вмить завершитись тому що змінилися топи/переглянули бюджет/прийшов інший вендор;
— тягнуться роками без виходу в продакшн, переписуються кілька разів і у вас дуже маленькі шанси подивитися на результати роботи ваших рук, хіба що ви любите тепле комфортне болото (в якому час від часу з’являються чаплі та з’їдають особливо смачних жаб);
— нижче колеги думаю доповнять своїми цікавинками

Натомість шукати компанії які сфокусовані на розробці/продажі корисного продукту, стартапи, маленький аутсорс який працює на ті самі стартапи та продуктові компанії заходу, працювати на проектах з швидким та видимим вихлопом і для яких задча полягає в тому щоб зробити класне рішення, а не продати дупо-години.

Спасибо за отличную статью Сергей! Очень бы хотелось и третью часть про разногласия ООП и популярных enterprise-фреймворков

не читай, сходи на ютюбе

Дочитував кілька разів, але загалом стаття цікава.

Підписатись на коментарі