Комментарии 19
Для начала необходимо получить высшее образование в области информационных технологий, компьютерных наук или в смежной сфере.
Это не так.
Ловлю себя на мысли, что не могу понять логику сообщества. Поясню, что я имею в виду.
Я обратил внимание на вашу статью, потому, что обычно под таким заголовком следует текст, класса «архитектор предприятия – тот, кто строит бизнес, а по выходным подрабатывает кодингом». Будучи (в основной ипостаси) бизнес-архитектором вы можете представить обычную мою реакцию. 🙂
Более того, на практике взаимодействие бизнес-архитектора и архитектора предприятия – сложнейшая задача. Мне редко удавалось находить понимание с этими коллегами, потому, что они считали, что лучше бизнес-архитектора знают, что такое бизнес-процессы, что такое органзационные структуры, что такое корпоративное управление и прочее, прочее, прочее. Более того, сколько копий сломано на поле того, а какую задачу мы вместе должны решать. И моя позиция, что архитектура ИТ хороша лишь тогда, когда мы добиваемся увеличения производительности труда, так и оставалась не принятой ими.
У вас же я увидел совершенно корректный взгляд на роль архитектора предприятия, с четкой логикой его работы.
Вернусь к тому, с чего начал. Почему я пишу эти строки. Потому, что увидел, как рьяно отминусовали вашу работу те, кто мог просто пройти мимо. Я, наверное, сам сейчас рискую попасть под всевидящее око «ветеранов броуновского движения», которые сочтут мой комментарий подозрительной активностью, как это обычно бывает, но все же, я хочу поддержать вас. Спасибо за цельный, корректный и лаконичный (на сколько позволяет эта тема) взгляд. Хоть это здесь и не принято.
🙂
Спасибо большое, за ваш позитивный комментарий, к сожалению это сейчас редкость, в современных реалиях видимо проще кинуть камень, чем поддержать или развить тему! Буду стараться для всех кто считает мой труд не напрасным! 🫶
Лично я впервые слышу о роли "бизнес архитектора" в контексте ИТ. Не понимаю, при чем тут ИТ? Системный архитектор - да, ибо это по сути специалист, способный в одиночку разработать сложную ИТ систему, требующую глубокого понимания.
Например, сис архитектор в принципе может сказать, реализуемо ли какое-то требование (на самом деле любое требование реализуемо за бесконечное время) в разумных пределах. Вроде, например, горизонтально масштабируемого решения с определенным временем отклика. Или, например, вы хотите робота, который будет сам учится готовить разные блюда из интернета. Как сис архитектор я могу сказать - да, это возможно. И даже реально создать такое решение. И даже могу разработать его.
Но, как правило, человека с такими навыками берут не для того, чтобы он все сам делал, а как управляющего процессом, вроде шеф повара на кухне. И не в виде менеджера, а именно как планировщика всей архитектуры и контроллера исполнения. Т.е. у бизнеса возникает запрос - сис арх говорит, как этот запрос реализовать и может поэтапно расписать - что, кому и как нужно делать. Причем - досконально и чётко, а не как это принято у менеджмента "чтоб красиво параллельные линии под 90⁰ одна прозрачная, остальные круглые, и чтоб еще вчера". А у вас по описанию - это чел который ui рисует.
А у вас какие то бизнес архитекторы. Это вообще чисто менеджмент и бизнес процессы, к ИТ это сбоку припеку. Обычно, эту позицию называют "технический директор". А вы все в одну кучу смешали, потому что слово "архитектор". Может, и ошибаюсь, менеджмент - не моя сфера.
А рассылки, crm и вывод отчетов в табличках и графиках - это не про ИТ. Это просто необходимость в текущих реалиях современного бизнеса. Так что навык работы в excel не превращает никого в ИТ специалиста. ИТ - это не про компьютеры, я об этом писал.
Прежде всего отмечу что каждый имеет право на свою точку зрения и мнение, и это очень ценно, что вы делитесь им в конструктивном подходе. Благодаря этому я могу взглянуть на вопрос с другого ракурса. Но я также хотел бы уточнить свою позицию:
1 В некоторых крупных корпорациях выделяют отдельно бизнес архитекторов. Коллега в комментариях выше ⬆️ написал о том что выполняет эту роль
2 Соглашусь с вами, цель архитектора это координация работы команды, стратегическое видение и помощь бизнесу в принятии решений.
3 В статье не сказано что системный архитектор рисует ui, интерфейсы это не обязательно ui. Интерфейс это компонент системы или программы необходимый для взаимодействия с ней, например в java это определенный класс который реализует логику вызова программы. Потребителей может быть несколько и все могут по разному использовать программу.
4 Цель статьи не рассказать в деталях о каждой роли архитекторов. В первую очередь хотел показать разнообразие ролей архитекторов и принцип их появления. В действительности можно по каждой роли в деталях и нюансах указать про специфику и задачи, но тогда статья получится раздутой и не каждый осилит ее прочтение. Лучше подготовить отдельную, возможно Вы сможете это сделать лучше т.к. обладаете реальным опытом системного архитектора и можете рассказать об этой роли всё.
5 архитектура это направление которое сформировалось в строительной сфере еще в древней Греции, и в ИТ это понятие переняли. Главное здесь это понять принципы, которыми руководствуется архитектор, и область применения его знаний может быть различной и бизнес не исключение. Роль архитектора стоит на пересечении многих навыков и качеств, и в зависимости от их соотношения определяется конкретная роль. Менеджмент и коммуникации также важны как и технические навыки.
Я статью лично скорее положительно оцениваю, ибо что-то новое. Но я так и не понял, почему бизнес архиеткотры - это что-то про ИТ? Ибо я так понимаю, это уровень около топ-менеджмента, который принимает решение о внедрении и исполнении именно БИЗНЕС процессов и занимается менеджментом. А то так можно сказать, что тетя Клава на рынке тоже ИТ, потому что на калькуляторе считает. Я об этом.
А интерфейс в любом ПО - это необходимость. Все равно что писать, что гончары дырки в вазах делают.
«Не понимаю, при чем тут ИТ? » — Отличный вопрос! К сожалению, не вы один не понимаете это (без обид, пожалуйста; просто констатация факта). Постараюсь объяснить.
Зайдем издалека — так будет понятнее. Смотрите, что делает основатель? Он генерирует бизнес‑идею. Что это? Это просто, то это ответ на вопрос, на чём мы можем заработать?. Ок, определили, что теперь? Теперь нужно ответить на вопрос, а как на этом заработать? На этот вопрос отвечает бизнес‑модель. Большинство предпринимателей делают это сами, просто копируя чью‑то работающую бизнес‑модель. Напротив лавка (модель «купил, выставил, продал»), ок, копируем, и тоже покупаем, выставляем, продаем.
Примерно 1–2% предпринимателей проявляют природную гениальность — они создают свою бизнес‑модель. Раньше продавали, теперь — сдаем в аренду. Раньше продавали все сразу — теперь по подписке открываем нужные функции. И тому подобное.
Другая часть уже на этом этапе ищут бизнес‑архитектора, с чьей помощью можно создать уникальную бизнес‑модель (называется инновационная) или более детально проработать существующую бизнес‑модель, чтобы избежать ошибок.
Опустим подробности про бизнес‑модели — сейчас разговор не об этом. Теперь встает вопрос, а как эту бизнес‑модель реализовать? И вот на этот вопрос профессионально может ответить только бизнес‑архитектор. Скажу кратко и просто: всё, что вам не нравится в вашей компании на 80% является следствием того, что бизнес‑архитектурой системно не занимался никто. Все вот эти «исторически сложилось». Но и это требует отдельного разговора.
Что делает бизнес‑архитектор? Он проектирует (конечно же своей командой и руками внешних подрядчиков - в одно рыло, простите, эту задачу можно решать веками):
модель процессов — ответ на вопрос, что нужно делать?
организационную модель — ответ на вопрос, кто это будет делать, и как мы будем тех, кто это делает группировать с целью управления?
корпоративную модель — как это все будет выглядеть с точки зрения хозяйственного права, юрисдикций, собственности?
модель социальной ответственности и партнёрства — как мы вписываемся в социум, строим отношения с персоналом и местным сообществом;
другие модели, по мере необходимости;
информационную модель — как всё, перечисленное выше создает данные, как эти данные консолидируются в информацию, как на основе этой информации создаются знания, как эти знания превращаются либо в конкурентные преимущества, либо в инновационные бизнес‑модели или продукты?
Стоп! Информационную модель?! Это же ИТ!!! Ишь на что замахнулся?!
И вот здесь я, как правило, спрашиваю, мои не далекие («не» раздельно, в смысле «близкие») коллеги из соседнего цеха, вы действительно готовы мыслить в категориях «символ‑слово‑данные‑информация‑знания‑приемущества», и не останавливаться на 4-м пункте? У вас точно для этого есть знания, навыки, умения и опыт?
Безусловно, в ответ ты получишь встречный вопрос: а что ты, хрен с горы, знаешь о семантике данных, о хранении информации и ее безопасности, особенностях ее передачи через спутниковые каналы, распределенных вычислениях и векторном хранении и кучу иных «традиционных» в этом контексте вопросов?
Лично мне всегда было просто — мой ответ: «всё». Но не всем моим коллегам (из моего цеха) посчастливилось закончить институт связи. И на этом месте разгорается конфликт. Как правило он постепенно уходит от дискуса о том как правильно в сторону простоты и компромиссов.
Вот здесь и возникает у бизнес‑архитекта (выступающего постановщиком задач) необходимость иметь «подрядчика» (того, кто выполнит эту задачу исходя из системных, не ИТ, а управленческих требований). И это ни кто иной, как архитектор предприятия.
Что будет если такой связки нет? Приведу пример из практики. В 2006 году я был одним из тех, кто инициировал прекращение внедрения SAP R/3 в одной крупной горно‑металлургической компании. Почему? Причин много, и коррупция, и сложность и ресурсоемкость. Но главное — это приводило к снижению производительности труда, а стоимость владения была такова, что с этой точки зрения проект не имел шансов на окупаемость когда либо. Опс!
Вот при чем здесь ИТ. Бизнес‑архитектор — постановщик задач и контролер, архитектор предприятия — исполнитель. Это рабочая связка, позволяющая сэкономить огромные ресурсы и дать компании реальную отдачу.
Примерно так... То есть бизнес‑архитектор — это точно не тетя Клава с калькулятором.
Хорошо изложено про бизнес архитектора, многое я не знал) хотел бы поддержать комментарий, но мне карму заминусили…
Так о том и речь. Планировка бизнес процессов - это не ИТ. Если широко трактовать - то вообще всё является ИТ, от слов до цветовосприятия и вообще, все что связанно с мышлением, ибо даже логика - это информационная технология. Но мухи - отдельно, котлеты - отдельно. Управление ресурсами - это управление ресурсами. То, что ресурсом является калькулятор не превращает менеджмент в ИТ направление. Ибо если вообще возникают задачи менеджмента (тот самый "бизнес"), или стратегиечское управление ресурсами - это НЕ ИТ. ИТ - это технологии работы с информацией. А не сам процесс обработки информации.
Вы похоже не улавливаете месседж. Менеджер - остается менеджером, даже если он умеет в BPWIN и СППР. Пусть даже если это менеджер с глубокими техническими знаниями - роль другая. А технолог остается технологом, ибо эта роль вообще абстрагированна от межличностного взаимодействия.
Кароче, если так понятнее: ИТ - мед, межличностное взаимодействие, финансы, управление ресурсами и т.д. - ложка дёгтя. То же самое, например, с медициной, биохимией и т.д. Когда примешивается политика - деятельность уже нельзя относить исключительно к одной специфике. Поэтому "бизнес архитектор" - это про менеджмент, а не про ИТ. Ибо меняем продажу калькуляторов на пластик - ничего не меняется, роль та же.
Довольно комплексно рассмотрена классификация, добавлю от себя что сейчас архитектор если это не большая организация все больше роль чем позиция и это кстати один из вариантов как туда можно прийти. Начать выполнять роль и задачи, наполняя портфолио.
Главный плюс: ни за что не отвечаешь, можешь говорить что все сделали неправильно
Отличная статья, спасибо!
Иду в бизнес-архитекторы из бизнес-аналитика, и знаю, что этот путь не простой. Требует опыта анализа и оптимизации бизнес-процессов, экономики компании, и конечно, понимания, как это всё переложить на it.
Благодарю, жду следующих статей.
Взять Тогаф и сказать, что отныне существуют архитекторы, соответвующие каждому уровню абстракции АП, это, на мой взгляд, не очень адекватно - мы опять получим кваканья из каждого этого отдельного царства и придем к проблеме процессного управления уже внутри проектирования и развития АП.
Также не увидел в требованиях к архитектору (может, просмотрел) ответственность. Если как разраб или аналитик после окончания работы я слышу типа "придется переделать, мы ("я", вдруг меняется на "мы") тут кое-что не учли, а то, что ты сделал, отложи / выброси в корзину)", то спасает только удаленка (первый раз простил бы, второй предупредил бы, на третий уже бил бы ногами в курилке или туалете).
Кто такие ИТ-архитекторы и какие задачи они решают