Много лет назад я от усталости облокотился на стену техкоридора и начал по ней медленно сползать. Мы только что сдали проект после пары недель ночных переработок, чтобы уложиться в дедлайн. Мимо шёл мой руководитель, я простонал:
— Рома, я задолбался быть инженером. Всё, ухожу!
Он ласково улыбнулся и сказал:
— Хорошо. Будешь системным архитектором. Там только свет и чистота. Выспись и приходи, расскажу, что будешь делать.
Я был молодым и наивным. Выспался и пришёл. Тогда начал постепенно становиться архитектором (сейчас стал), и могу смело сказать: света и чистоты тут столько же, сколько в буднях инженера. А вот ответственности больше. Поэтому — нет, не надо быть архитектором, если вы не понимаете, на что идёте.
Но! Если понимаете — это будет очень увлекательное приключение.
Как это выглядит?
Вообще, мне казалось, что будет интересно общаться с заказчиками, выявлять самому, что им на самом деле нужно, узнавать, что у них в головах, в инфраструктуре, а потом делать большие проекты — и чтобы всё было красиво.
Разрыв с реальностью в том, что то, что у них в головах, не всегда соотносится с тем, что у них в инфраструктуре.
И сначала ты работаешь психологом, потом доносишь правду, потом на тебя обижаются (иногда), потом ты опять работаешь психологом, потом задаёшь сто вопросов, потом проверяешь факты (и не все они такие, как представлены) — и только после этого складывается мнение, как проектировать систему. Потом ты объясняешь это всем людям, которые в ней заинтересованы: почему так, зачем, сколько будет стоить, как правильно для такой-то ситуации и для такой-то, почему может оказаться, что «чтобы быстрее заработало» и «надо на 10 лет вперёд» может быть на одной и той же технологией, а может и не быть. И как выбрать. А потом, когда твоя печень вырастает большая-пребольшая, остаётся только нарисовать сову — собственно, спроектировать систему в деталях.
Самое большое удовольствие в профессии — это сначала закончить проектирование и понять, что всё именно так, как нужно по задаче. А потом, спустя пару лет, увидеть, как это воплощается командой (или многими командами, до сотен людей), и порадоваться, что ты это увидел и показал, как делать.
В общем, архитектор — это тот, кто принимает главные решения на проекте. Наверное, это больше всего и «подсаживает» на профессию.
Что вообще делает архитектор?
Сейчас я занимаюсь клиентскими проектами и нашим облаком Техносерв Cloud. Развлечение выглядит так: прилетает какой-нибудь крупный проект. Например, спроектировать дата-центр.
Кто-то ЦОД рисует. Кто-то хорошо разбирается в базах данных. Кто-то в сети. И во всём этом нужен такой человек, который понимает верхнеуровневые требования заказчика к проекту в целом. У заказчика нет желания построить ЦОД или внедрить какую-то систему. У него задача — «хочу переместить всю свою нагрузку из одного места в другое» или «организовать отказоустойчивую площадку, которая позволила бы всем моим системам пережить дизастер». Нужен тот, кто поймёт все эти требования. Причём они ещё даже не требования, они просто хотелки. «Мы хотим увеличить продажи в 2 раза и при этом число инцидентов сократить в 3 раза» — надо прийти поговорить с нужными людьми, понять, откуда у них столько инцидентов, что с этим можно сделать.
То есть сначала собираются хотелки. Потом составляется и согласуется ТЗ, потом по нему делается решение, которое включает и физику, и прикладную часть, — для всех этих задач нужен архитектор.
Не обязательно архитектор делает весь проект по всем подсистемам — на крупных вещах система совета или зон ответственности под руководством главного специалиста. Например, сетевой архитектор привлекается тогда, когда необходимо спроектировать и построить ВКС (СКС) для проекта. Архитектор-прикладник же привлекается, когда нужно разработать какие-то информационные системы. И так далее.
Проще всего объяснить на примере облака. Я делаю начальное проектирование всего того, что компания продаёт из облака. Я планирую и проектирую (и ещё потом контролирую) построение собственной инфраструктуры, потом сдаю её команде эксплуатации. Со мной работают три человека на подзадачах: отвечают за OpenStack, за VMware, за сеть хранения.
Где тогда геморрой?
Где-то в 85% случаев бизнес считает, что половина того, что он хочет, и мы ему рассказываем, у него уже есть — и проблем никаких нет. Но штука в том, что когда спускаешься на уровень департамента, отдела и т. д., оказывается, что всё не так прикольно: процессы прорисованы у бизнеса («Мы полностью исполняем ITIL в процессах, заявки проходят согласование чисто только в системах, всё проскакивает моментально»), а у админов СУБД выясняется, что безопасники всё равно просят принести бумажную копию, подписанную у всех руководителей компании. Анализируют эту бумажку много месяцев и только потом дают добро на развёртывание какой-то тестовой среды.
Подстава в том, что если прийти на проекте к бизнесу с формулировкой, что у вас всё работает не так, то молись, чтобы тебя не взяли в этот проект.
Потому что те, кого ты этим «спалил», тебе работать не дадут.
Особенно, знаете, изредка встречаются такие древние особисты, у которых всегда должна быть бумажка, чтобы прикрыться.
И да, мне нравится придумывать, как всё это можно изменить.
Оценить проект можно только вместе с бизнесом, и то через пару лет. Но на самом представлении бывает субъективная составляющая: ну, самолёт должен летать и быть красивым. А ещё такой результат должен стать шаблоном в идеале, чтобы можно было внедрять во всех похожих случаях.
Как выгорают
Рынок маленький, все про всех знают. Бывает, люди просто уходят куда-то с должности из-за накопившейся усталости и ответственности. Бывает, людей терпят. Например, знаю одного очень сильного технического эксперта. Он приходит и всех благим матом кроет.
Говорит: «Как вас земля носит, идиотов таких!» И доказывает, разбирая код. Но его любят за профессионализм. Он никогда не хотел быть архитектором, говорит: «Я не хочу переводить оттенки смыслов и эманации, что они там чувствуют». И остаётся инженером и по сей день. «Есть ТЗ. Я взял, пошёл и сделал. Я не хочу даже знать, нужно ли ему это было или нет».
Ещё один коллега возглавлял техслужбу, потом архитектурное подразделение, а сейчас он занимается удалённым администрированием с какого-то тропического острова, кажется. Счастлив.
Так что, если думаете, что архитектор — это ветка развития разработчика, которая сразу после тимлида, — не уверен. Геморроя, как видите, тут очень много, но и радости от того, что ты разобрался и решил сложную задачу, очень много. Но только проекты все большие, поэтому радость приходит пару раз в год.
«А если я буду делать неправильно»?
ИТ-директор телекома как-то спросил: «Если я буду делать неправильно, вы меня поправите?»
«Да, — говорю, — мы будем разговаривать».
Он: «А как вы будете меня убеждать?»
Я говорю: «Никак. Пистолет у вас. Я могу только сказать, что если вы будете себе стрелять в ногу, вероятно, вам будет больно».
Но я всегда предупрежу, что пистолет направлен в ногу.
Или вот пример. Есть виртуализованные приложения, нагрузка скачет от случая к случаю. Клиент из розницы, и у него перед 8 марта начинается шквал. Бэкэнд успевает, а сайты ложатся на 404. Тут всё просто: надо просто приложение разнести на параллельные процессы, продумать, чтобы узких мест не было. А писалось оно в 90-х и с тех пор обрастало ракушками — надо много чего переворошить. Потом сменились люди в бизнесе, говорят: «Давайте закупим лишних серверов и будем жить от концепции, чтобы мощностей хватало под пик». Докупили пару стоек, вхолостую гоняют их 320 из 365 дней в году. Через два года эти дядьки ушли, пришли новые. Смотрят на стойки, говорят: «Чего воздух греют, давайте продадим». Продают. Весна наступает неожиданно, пик. Снова начинается первая итерация. В итоге они идут в облако, и мои коллеги начинают помогать им правильно делать инсталляцию. Не все даже понимают, что такое балансировщик, но тут лучше в деталях эксплуатация расскажет, у них накипело.
Часто надо быстро запустить проект любой ценой за 2 месяца, а на деле, когда зоопарк разбираешь, понимаешь, что строить должны на 10 лет. Иногда удаётся донести. Иногда нет — заказчик мыслит годовым планом, и это его деньги и его бизнес. Он прав, он знает, что делать стратегически в бизнесе. Моя задача — показать ему варианты и, условно говоря, плюсы-минусы каждого в максимально понятных ему числах или определениях.
А ещё нас иногда дразнят стартапщиками — всё чаще запускаем прототипы, а потом их начинаем переделывать в постоянные штуки.
Кто может «потянуть»?
Не знаю, как становятся архитекторами. Могу сказать, что я 4 года работал инженером, потом в другой компании (уже с опытом) — как проектировщик, а потом как архитектор. В «Техносерве» два с половиной года. Но «на той стороне» я всё равно работал с инженерами «Техносерва», как с людьми подрядчика — делали один большой проект.
Большинство архитекторов, конечно, вырастают из продвинутых разработчиков и инженеров. Но есть единичные исключения, всё зависит от навыков системного мышления, которые в целом приобретаются не обязательно в ИТ-специальностях.
Многие в архитектуру идут за новыми технологиями. Общие подходы к проектированию и построению систем остаются неизменными. Что внедрять и что планировать — вопрос подготовки. За достаточно ограниченное время можно в своё портфолио включить решения какого-нибудь вендора. Например, есть мониторинг БД, приложений, сети, пользовательских транзакций, ЦОДов — в принципе подходы одни и те же. Решает опыт (много опыта) и системное мышление.
Если бы мне пришлось собеседовать нового архитектора в команду, я предпочёл бы проиграть ситуацию с заказчиком и исполнителем: ставлю задачу, а точнее, озвучиваю хотелки, как заказчики часто делают, а потом смотрю, какие вопросы задаёт мне соискатель, как выясняет задачу, какие модели предлагает.
В разработке знания технологий устаревают быстро, а культура и навыки алгоритмизации остаются навсегда. А в архитектуре почти ничего из знаний не устаревает — изучая что-то, можно быть уверенным, что многое пригодится и через год, и через пять, и через десять.
Как понять, что стоит идти в архитекторы?
Не знаю. Наверное, когда вы захотите острых ощущений от общения с людьми и решения сложных задач со множеством факторов. Или когда вы всё равно выступаете архитектором на проектах, просто эта роль входит во что-то, называющееся по-другому.
В общем, приходите. У нас тут, говорят, только свет и чистота.
Это материал нашего архитектора Александра Шубина.
Комментарии (93)
pogorzhelskiy
28.11.2017 10:44+2Архитектором становишься, когда поработал обычным пресейлом, есть опыт менеджера проектов, инженером и некий опыт продавца(хотя бы аккаунт менеджер).
Главная проблема для компании от такого архитектора состоит в том, что если он достаточно грамотен, то все проблемы с кадрами в компании вылезают на верх.
carebellum
28.11.2017 12:29+2смешались в кучу кони, люди
1. архитектору в общем случае никак не пригодится опыт продавца. опыт управления проектом нужен на самом базовом уровне.
2. аккаунт обладает гораздо более точным пониманием инфраструктуры заказчики в целом и конкретных задач. не понятно почему хотя быpogorzhelskiy
28.11.2017 13:03Согласен с вами. Часто в компаниях разнятся составы обязанностей Ахитектора. Где-то это человек, который рисует архитектуру(и составляет смету) и ему всё равно кто будет её реализовывать и продавать заказчику, а где-то обязанности архитектора заканчиваются на стадии сдачи проекта в эксплуатацию.
Mendel
29.11.2017 00:06Не знаю что имел ввиду ваш оппонент, но я вижу плюс от опыта «продаж» в том, что человек лучше понимает кашу из хотелок, и имеет более целеориентированное мышление.
Первый комментарий к статье начался с нелюбви к плохой архитектуре. А это «ой!».
Если архитектура из говна и палок решает задачи бизнеса и имеет оптимальные показатели, то это идеальная архитектура, что бы не думал тот кто напрямую с ней работает.
Жили были три крупных провайдера в одном городе.
Еще в девяностых.
И понадобился всем троим спутниковый аплинк. Один провайдер выложил условные 100 единиц денег за него.
Второй провайдер купил часть инфраструктуры, часть соорудили из подручных средств в своей лаборатории (которая была довольно серьезная) и обошлись 50 единиц денег.
Третий провайдер выкинул половину инфраструктуры, уложился в 20 единиц денег, правда раз в час у них на крышу выходил дежурный техник и подкручивал положение тарелки. Поскольку это был не единственный аплинк и дело было в девяностых, то SLA позволяло.
Я думаю понятно у кого был самый высокий ROI.
И да, в живых из них сейчас остался только тот у кого была своя лаборатория, но это уже другая история…
Так вот, я утверждаю что плевать как оценивает архитектуру техник которому приходится подкручивать тарелку. Умерли они по совсем другой причине. Продажник (пусть и слабый) лучше сможет понять хотелки бизнеса, лучше сможет донести до бизнеса скрытые риски и опасность технического долга который игнорируется бизнесом (на понятном бизнесу языке, а не так чтобы бизнес решил что чуваку просто лень крутить гайки на тарелке), и что еще важнее — продажник такая сволочь которая игнорирует кучу важных вещей в угоду тому чтобы продать. Для того чтобы видеть важное и второстепенное одного аналитического склада ума недостаточно. Технарь хочет сделать красивую технологичную структуру. Продажник хочет продать, и красота и технологичность важна лишь постольку поскольку помогает продавать.
Гигагерцы, дюймы и гигапиксели интересуют его лишь постольку поскольку. Для него они средство. Для инженера — цель.
Этому нельзя научиться в чисто технической среде.
И «продажи» в этом могут помочь. А могут и не помочь конечно…
daedrayg
28.11.2017 12:19Правда ли, что возможно расти до архитектора только в рамках одной компании, или можно быть инженером и перейти в другую компанию архитектором?
TS_Cloud Автор
28.11.2017 14:05Как говорит Александр, ему было бы не очень комфортно переходить с изменением типа задач на другое место работы. Гораздо проще погружаться в новое в приятном и привычном коллективе. Но при этом считает, что тут все варианты возможны. Было бы желание
Gruxon
28.11.2017 12:21+2Системный архитектор — очень определённый образ мышления и определённый склад ума. А «системный», от «системный подход», а не от система.
И стать СА может и бывший тимлид, и сетевик, и даже DBA. Вообще кто угодно, кто дорос до того, чтобы решать бизнес-задачу заказчика, а не только задачу ИТ (как описано тут) или ИТ-директора. Хороший системный архитектор способен написать ФЦП по информартизации ведомства или план создания комплексной информационной системы решающей проблемы целой отрасли (разумеется возглавляя команду аналитиков и архитекторов прикладного и инфраструктурного уровня, а не в одиночку). Настоящий СА никогда не заходит в тупик и не говорит, «нам не хватает данных». Он всегда знает как пройти дальше и как подойти к задаче, которая кажется неразрешимой.dadwin
30.11.2017 10:02А «системный», от «системный подход», а не от система.
а «системный подход» не от слова «система»?
RomanVPro
28.11.2017 12:31Вот то, что описано в статье — это не обязанности архитектора. С клиентом должен общаться проект-менеджер: он должен заниматься всей этой «психологией». Совсем недавно была отличная статья на Хабре habrahabr.ru/company/technoserv/blog/342494 про роли в команде.
carebellum
28.11.2017 13:03Общаться надо для уточнения задач на техническом уровне и для этого необходимо отличное понимание области, чего не будет у PM. Хотя PM на встречах также необходим, конечно же
hudson
28.11.2017 13:09И Аналитика не забудьте! ПМ, Аналитик, Архитектор — «святая троица». Один занимается «психологией» и растит печень, другой отделяет существенное от несущественного (собирает требования), третий знает что реализуемо, что нет и, если реализуемо, как.
bipiem
28.11.2017 15:11И Аналитика не забудьте!
Хочется добавить: и Главного конструктора не забудьте!
Когда то было достаточно Главного конструктора изделия ххх и конструкторов его составных частей. Было достаточно 34.ххх и более серьезных РВ 15.ххх.
Страна создавала и использовала собственные Best Practice, покоряла космос, атом.
А теперь PM, западные методологии (PMBOK, CBOK, ITIL, TOGAF и еще десяток подобного), западные решения, западное всё.
Но это так, «к слову», просто о «забытом» Главном конструкторе навеяло.hudson
28.11.2017 15:27Ну а разве главный конструктор на производстве не является прямым аналогом архитектора из мира ИТ?
balexa
28.11.2017 15:28Да ни о ком не забыли. Почитайте книгу «Системноинженерное мышление» Левенчука.
Там как раз говорится, о проблеме советских системных инженеров. У нас ГК выращивали методом «охоты и собирательства», случайным образом находя талантливых инженеров и изобретателей.
А эти ваши западные методологии позволяют готовить системных инженеров и главных конструкторов не поиском гениев из массы, а на потоке. Не методом тыка, а формализовав программу для обучения. Вот и все.
BigD
28.11.2017 21:10Напомнило подход моих глобальных коллег из Штатов:
- давайте обсудим теперь миграцию AD — вот такой есть вопрос про DHCP
- э нееет, у нас на колле нет архитектора DHCP, у нас только архитектор DNS есть, надо переносить звонок..
ikirin
28.11.2017 13:36Я правильно понимаю, что системный архитектор не занимается проектированием архитектуры приложения?
TS_Cloud Автор
28.11.2017 14:13У нас занимается. Но на уровне целей, ФТ, HLD. За декомпозицией — к «прикладникам».
stp008
28.11.2017 21:33Тут просто несколько понятий смешны в одно. Архитекторы бывают разные. Может быть архитектор решения (иначе solution architect), системных архитектор, перфоманс архитектор и тд. Первый занимается больше бизнес вопросами, общением с кастомером, знает как и что с функциональной точки зрения работает и высокоуровневым функциональным анализом того, как новые изменения будут ложиться на текущее решение. Системный архитектор как раз занимается тем, что большинство привыкли принимать за архитектора в ит: знает кодовую базу приложения, как и что с чем работает, по каким протоколам, секьюрити вопросы, возможно как что декомпозировано в коде и так далее. Он как раз участвует в разработке системы и свысока смотрит чтобы все было более-менее так, как он задумывал и помогает в случае проблем при разработке. Перфоманс архитектор занимается непосредственно перфомансом и помогает при проектировании сделать так, чтобы все нефункциональные требования были удовлетворены и с запасом на будущее (у нормальных проектов обычно есть планы по расширению на ближайшие лет 5 минимум). Понятно, что идеальный софт архитектор в вакууме должен совмещать все эти три сферы, но таких людей очень мало, да и скорее всего в случае больших систем таких людей физически не существует, потому что просто не хватит времени на решение этих вопросов и накопления знаний. И в больших проектах в связи с этим архитекторов обычно и делят на данные три типа и каждый решают свою задачу. Тут наверное стоит нарисовать треугольник, как в КАП теореме, где вершинами будут бизнес, системная производительность и архитектура приложения и мапить на нее. Идеальный с моей точки зрения архитектор должен быть где-то в середине треугольника, а для критичных вопросов должна быть компетентная команда, которую архитектор и помог набрать. Как-то так
bipiem
29.11.2017 16:56где вершинами будут бизнес, системная производительность и архитектура приложения и мапить на нее.
Идеальный с моей точки зрения архитектор должен быть где-то в середине треугольника, а для критичных вопросов должна быть компетентная команда, которую архитектор и помог набрать. Как-то так
Примерно так. Но с уточнением. В этом треугольнике только один угол — ИТ. И то при условии, что ИТ вообще есть в компании (развито).
Поэтому, «архитектор предприятия» — это тот, кто немного понимает в бизнесе предприятия, немного в технологическом процессе производства на предприятии (технолог) и немного в ИТ. Причем, в ИТ — в последнюю очередь.
Вот такой архитектор и стоит посредине этого треугольника. А то, что ИТ «тянут» одеяло на себя, называя ИТ-архитектора — просто архитектором предприятия — так это и есть «маркетинговый трюк». Такой подход справедлив для предприятий с 99% коэффициентом автоматизации. Но таких о-очень мало.
Не нужно путать «архитекторов предприятия» с ИТ-архитекторами предприятия. Это подмена понятий.
Похожая аналогия с главным инженером предприятия (или главным инженером проекта): он всего знает понемногу, но если возникает вопрос по канализации, он зовет соответствующего зама, если по пожарной сигнализации — то по ней. Но в целом знает обо всем, т.к. он «внутри треугольника».
bipiem
28.11.2017 14:04Крутым архитекторам должно быть известно, что такое «Архитектура предприятия».
Дайте, пожалуйста, пару ссылок на подробное описание какой-либо такой архитектуры реального или вымышленного предприятия. Не общие подходы и не отсылки на всякие там ТОГАФы, а именно подробный конкретный пример.
Несколько лет ищу пример архитектуры, а попадаются только архитекторы.TS_Cloud Автор
28.11.2017 14:41Спасибо за мысль! Если мы найдём такой отдельный и без NDA, сделаем отдельный пост и попробуем объяснить, что, откуда и почему взялось. Однако, кажется, далеко не любой бизнес-заказчик хотел бы это увидеть. Скорее, наоборот, слишком уж много данных на входе, которые мало кому снаружи надо знать.
bipiem
28.11.2017 14:58Я ожидал услышать стандартный ответ: мы «системные архитекторы», а про «просто архитектуру» (предприятия, EA) спрашивайте у просто архитекторов.
Ваш ответ пока только «вселяет надежду».
Столько времени заниматься ЕА и нет ни одного примера, который не стыдно показать?
NDA — стандартная отговорка. При желании меняются названия, «пароли-явки», дается подпись «все совпадения случайны» и т.п.carebellum
28.11.2017 15:08+1это же IP. кто же будет задаром такое раздавать? если только на верхнем уровне совсем как часть success story
bipiem
28.11.2017 15:22Посмотрим на этот IP — со стороны нас, обычных граждан — налогоплательщиков. Одна компания разработала EA для госкомпании 1. Мы (налогоплательщики) заплатили. Далее эта же или другая компания разработала для госкомпании 2 тоже EA. Причем точно такую же. Мы снова заплатили.
Далее снова для госкомпании 3 сделали такую же ЕА, и нас снова обобрали.
Какое к \ на … IP? Если за одно и то (одну и туже EA) мы платим свои же (бюджетные) деньги?
Тем самым не только народ обирают, но и ВВП накручивают (поставляя одного и тогож, но беря за разработку сполна «как положено»).
Я про унификацию, тиражирование, гласность, повторное использование (заимствование), эффективное применение ранее уплаченных бюджетных средств (т.е. моих и твоих), оптимизацию НАРОДНЫХ инвестиций.balexa
28.11.2017 15:34такую же ЕА
Да с чего это такую же? Если это другое предприятие, то у него цели и задачи другие.bipiem
28.11.2017 17:57+1Песню, что каждое предприятие должно быть уникальным с уникальной ЕА (и СА кстати тоже) — поется как раз теми, кто продает «разные ЕА». Типизация и унификация явно не в их интересах. Чем ЕА у «Детская поликлиника №1» будет отличаться от ЕА у «Детская поликлиника №2»?
Но мой вопрос глубже: как можно вообще говорить об ЕА, если вообще нет примеров ЕА в открытом доступе?
Может EA нет и в природе? А может быть ЕА — это такой же «голый король»?balexa
28.11.2017 21:53если вообще нет примеров ЕА в открытом доступе?
Да как это нет? Гуглите enterprise architecture examples.
Да, там будут общие вещи под общее предприятие. Конкретные вещи никто вам не выложит. По той же причине, по которой мосигра не выкладывает франчайз-буки. По той же причине, по которой макдональдс не отдает домой обучающие материалы.
ЕА, если это хорошее ЕА — это полное описание, как работает фирма. Откуда берутся деньги, как они тратятся, как это контролируется, как это будет развиваться, как контролируются риски и т.д.
Это секретная информация и никто вам ее не расскажет. Попросите у бизнесмена, который покупает-продает и никогда не слышал про архитектуру предприятия рассказать в деталях откуда он берет товар, как ищет покупателей, как договаривается с поставщиками, как управляет логистикой — он вас пошлет. И никаких примеров с конкретикой в открытом доступе вы никогда не найдете. Из этого следует что нет бизнес процессов что ли? Или что у них с конкурентом абсолютно одинаковые бизнес-процессы?
Может EA нет и в природе? А может быть ЕА — это такой же «голый король»?
Это просто формализация бизнес процессов. Формализация, даже неполная, как правило намного лучше хаоса и интуиции.
Чем ЕА у «Детская поликлиника №1» будет отличаться от ЕА у «Детская поликлиника №2»?
Вообще для некоммерческих контор мне кажется все немного иначе.
Ну а в целом — у детской поликлиники — может и не будет. В теории. А может и будет. В деталях и мелочах, где как известно дьявол. Архитектуру предприятия должны закупать в таком случае городские/региональные/федеральные власти, чем они и занимаются. Другое дело, что каждая поликлиника потом будет натягивать сову на глобус.bipiem
28.11.2017 23:19Откуда берутся деньги, как они тратятся, как это контролируется, как это будет развиваться,
Эээ, куда занесло. А как же бизнес-план, бизнес-стратегия, бизнес-модель и бизнес-«хх» и т.п. Это все и есть EA?
Это просто формализация бизнес процессов.
EA = формализация бизнес процессов? Снова не угадали.
Гуглите enterprise architecture examples.
Гуглил, и не один год. Исключительно одна реклама вендоров ПО и консалтеров и общие подходы типа ТОГАФ. Ни одного конкретного полного примера. Даже просил уважаемых специалистов привести пример тут (см. комментарии про бизнесясли):
Mendel
29.11.2017 00:32Чем ЕА у «Детская поликлиника №1» будет отличаться от ЕА у «Детская поликлиника №2»?
Черт, спать пора, но уж очень болит мозоль на который вы наступили. Вроде и давно было, но…
Один орган государственной власти решил вдруг автоматизироваться.
Кинули клич и оказалось что в одной области есть отличная система. Все функции автоматизированы. Айда покупать эту систему и внедрять по всей стране. (С откатами конечно огромными, но не суть, откат могут и нормальные разработчики дать).
Не ну а чё? Если в одной области прокатило, то и у других прокатит.
Правда область где разрабатывалось была «внутренней» и не имела не то что портов, а даже автомобильных границ. У них всех инспекторов области можно было собрать в кабинете начальника… в крупнейшей области только руководителей подразделений в один актовый зал одновременно собрать было нельзя, собирали в трех, в разных районах области (руководителей, без рядовых инспекторов).
Но даже без таких явных перегибов.
Спустя пару лет в системе даже некоторая специфика портов отражена была.
В крупнейшей области (крупнейшей для данного органа власти) максимальная вместимость пароходов — 60тыс тон на судно. В другой области где есть порты — 5 тыс. тон. Соответственно выплывали очень специфичные моменты, например то что на одном судне могло быть десять отправителей (у каждого груз из разных областей) и десять получателей (причем у каждого получателя частично в разных портах разгрузка), причем все они грузятся равномерно во все шесть трюмов (сыпучий груз). У судов которые в десять раз меньше количество комбинаций экспоненциально меньше.
Ну и мой любимый простенький пример.
Наблюдал как проверяющая из области с маленькими портами (практик, не теоретик — много лет работала в подразделении обслуживающим порты) докапалась до инспектора из крупного порта. Мол почему такие-то документы (идущие с каждой машиной привезшей груз) не лежат в деле по судну. Я там случайно оказался, думал зайти к ним, но как увидел из двери, так понял что не зайду… уж больно сдержаться сложно было.
Мужик сказал «ща!», ушел. Взял дело которое она смотрела (папка сантиметров пятнадцать толщиной), положил рядом с ней, открыл шкаф, достал стопку тех документов что она просила, и положил прямо перед ней со словами «не влазят!». Стопка была сантиметров семьдесят толщиной.
Тетка не теоретик. Практик.
Много лет руководила подобным подразделением. И грузопоток у нее приличный был. Только суда помельче…
Вы скажете «Но поликлиники то больше похожи!» и будете не правы.
поликлиники тоже разные. А вот в чем разные — для этого куча работы по выяснению и анализу…
ПС: при этом разделяю позицию о том что примеры проектов, типовые планы и т.п. должны публиковаться. Да даже сделанные за бюджетные деньги разработки должны частично публиковаться. Я чисто про «отличаться». Не мог удержаться простите…bipiem
29.11.2017 11:19Я чисто про «отличаться». Не мог удержаться простите…
Снова путаем «мухи и котлеты» (см. одноименный цикл статей bipiem).
Да, поликлиники могут быть разными (одни лечат, другие калечат), но «Архитектура предприятия» у них может быть (и должна быть) — одинаковой.
Это принципиальный момент: предприятия должны " отличаться ", но их архитектуры — нет!
Во всяком случае, утверждение: «каждому предприятию — своя уникальная архитектура» — это не верно. Для того и придуман термин «архитектура».
Посмотрим на термин внимательнее.
Архитектура — это некий каркас (ребро, арка, колонна и т.п.), общие подходы к построению здания или предприятия. Зданий разных много, но именно архитектур — мало.
Посмотрим на «Архитектура ПК» или сразу наберем «архитектура х86». Все картинки примерно одинаковые: шина данных, шина адреса, шина управления и т.п.
Совершенно разные компьютеры (от embedded до high-end серверов) могут иметь одну и туже архитектуру (х86)! А почему предприятия так не могут?
С «архитектурными подходами» в зодчестве и компьютерной технике — все понятно. А вот с EA — нет, в нем в понятие «архитектура» — вкладывают иной смысл (маркетинговый). Зачем?
Так и архитектур предприятий должно быть не много. Мне бы хоть одну увидеть (пока только «100 раз услышал»). Кто видел ее хоть раз, своими глазами?
Айда покупать эту систему и внедрять по всей стране
типовая система и типовая архитектура — это разные вещи.
lair
29.11.2017 11:24Архитектура — это некий каркас (ребро, арка, колонна и т.п.), общие подходы к построению здания или предприятия. Зданий разных много, но именно архитектур — мало.
Вы, простите, каким конкретно определением архитектуры предприятия пользуетесь?
bipiem
29.11.2017 16:37-1Я использую классический термин Архитектура (из русского языка). Этот термин (повторюсь) обозначает некий скелет, референтную (эталонную) модель, концепт (концептуальную модель), механизм абстрагирования от конкретики (абстракция).
В части строительства: абстрагироваться от привычного восприятия зданий как конкретного строения, но указать общий стиль подобных сооружений. Для «х86» — это общая концепция организации вычислений, реализованная в конкретном семействе микропроцессоров.
Про определение «Архитектура предприятие».
Ну, хорошо, для «enterprise» ЕА это очень круто, дорого и секретно. А если взять простое небольшое предприятие и зарисовать его ЕА?
Еще лучше взять вообще неавтоматизированное предприятие, где вообще нет компьютеров (а у бухгалтеров — счеты).
Там что нет «Архитектуры предприятия»?
т.е. предприятие есть, но без архитектуры? Как можно решать сложные задачи, если на простые нет ответа?
Очевидно, что даже у предприятия, у которого нет компьютеров и калькуляторов — есть «Архитектура предприятия» и правильное определение «Архитектуры предприятия» — должно это учитывать.
ЕА — Это архитектурное представление предприятия в целом. Даже предприятия, в котором вообще нет ИТ. Поэтому говорить, что в состав EA обязательно входят «Системная архитектура», «Архитектура приложений» и т.п. — неверно.lair
29.11.2017 16:58Я использую классический термин Архитектура (из русского языка).
В языке нет терминов, термины есть только в предметных областях. И одно и то же слово в разных предметных областях может иметь разные значения (а где-то и вовсе не быть термином).
Этот термин (повторюсь) обозначает
В русском языке это слово обычно обозначает дисциплину (вид деятельности), вид искусства (оба этих варианта покрываются словом "зодчество"), а еще "совокупность зданий и сооружений, создающих пространственную среду для жизни и деятельности человека" (все определения по википедии). Ничто из этого не совпадает с вашим "определением", кстати.
А если взять простое небольшое предприятие и зарисовать его ЕА?
Ну возьмите и зарисуйте.
Mendel
29.11.2017 16:50Нее. Вообще не так.
Общая структура это слишком неконкретно.
Ну возьмите «типовое положение» для поликлиники (типовой устав для частников), в нем общее описание будет.
Типовое положение, iso9000, МСФО, типовое штатное расписание для общей структуры — вот и вся «общая архитектура на общих принципах».
Дальше уже только частности идут.
Нет, я не против того чтобы архитектуру (как техническую так и операционную) госпредприятий разрабатывали максимально универсально, чтобы заказывали что-то глобальное, но… универсальное решение на несколько порядков дороже единичного.bipiem
29.11.2017 17:13Нее. Вообще не так.
Вы согласны, что термин «архитектура» — имеет одинаковое смысловое выражение в терминах «архитектура здания» (зодчество), «архитектура предприятия», «архитектура компьютера»?
Можно найти список всех популярных архитектур зодчества, компьютерных архитектур.
Понятно, что есть разные уровни (направления) классификации, например, RISC, CISC и др., или х86 и IBM System / 360, но они (списки, каталоги) конечные и публикуемые.
Почему «архитектура предприятия» не выдержана в том же ключе (подходе)?
Может это все же не «архитектура», если свойства непосредственно «архитектуры» (сущности термина) у «современной ЕА» (современном подходе к ЕА) отсутствуют?lair
29.11.2017 17:33Вы согласны, что термин «архитектура» — имеет одинаковое смысловое выражение в терминах «архитектура здания» (зодчество), «архитектура предприятия», «архитектура компьютера»?
Я вот не согласен.
Может это все же не «архитектура», если свойства непосредственно «архитектуры» (сущности термина) у «современной ЕА» (современном подходе к ЕА) отсутствуют?
Нет никакой "сущности термина", потому что термин существует только в конкретной прикладной области. У понятия enterprise architecture в рамках одноименной дисциплины есть определение. Если оно вам не нравится — вы его не используете эту дисциплину. Сколько угодно.
bipiem
29.11.2017 19:02Нет никакой «сущности термина», потому что термин существует только в конкретной прикладной области. У понятия enterprise architecture в рамках одноименной дисциплины есть определение.
1) Если общепринятое понятие «архитектура» в словосочетании «Архитектура предприятия» имеет совсем иной смысл, то логичнее назвать НОВЫЙ вводимый термин ЕА иначе или хотя бы подчеркивать, что в ЕА используется иное понимание «архитектура» по сравнению со всеми остальными сочетаниями этого («архитектура») термина.
2) «есть определение» — есть куча определений ЕА, Вы сами спрашивали «какое имеется ввиду» (пользуетесь).
3) В том то и дело, что нет дисциплины (инженерной дисциплины). Есть область мифологии, алхимии в отношении ЕА, а настоящей дисциплины ЕА — пока, к сожалению, нет. Она появится как минимум тогда, когда примеры ЕА появятся в открытом доступе и можно будет однозначно сказать: у этого и этого предприятия архитектура х1024, а у тех трех архитектура х2048".
Когда можно будет сравнивать архитектуры между собой.
Пока нечего сравнивать. Пока можно только говорить о «тайных» архитектурах, не факт, что реально существующих.
ЕА — Парадокс: Архитекторов — много, а архитектур — нет.lair
29.11.2017 21:29Если общепринятое понятие «архитектура» в словосочетании «Архитектура предприятия» имеет совсем иной смысл, то логичнее назвать НОВЫЙ вводимый термин ЕА иначе или хотя бы подчеркивать, что в ЕА
Если. И, что важнее, логичнее было назвать. Этому словосочетанию никак не меньше 15 лет уже, и трогать устоявшееся словоупотребление бесполезно.
«есть определение» — есть куча определений ЕА,
Да, каждое в рамках своего направления практики.
В том то и дело, что нет дисциплины (инженерной дисциплины)
А кто вам сказал, что она должна быть инженерной дисциплиной?
Она появится как минимум тогда, когда примеры ЕА появятся в открытом доступе
Это ваш собственный критерий, и практике на него более-менее наплевать. Как и единорогам.
у этого и этого предприятия архитектура х1024, а у тех трех архитектура х2048".
Вы вот так любите сравнивать с зодчеством, а вот вы можете про здания это сказать?
Когда можно будет сравнивать архитектуры между собой.
А вы можете сравнить между собой "архитектуры" двух зданий? Как это выглядит?
bipiem
29.11.2017 21:57А вы можете сравнить между собой «архитектуры» двух зданий? Как это выглядит?
wiki:
Архитектура Древнего мира: от первобытного общества до X века (в различных регионах даты различаются).
Романский стиль. X—XII века.
Готика. XII—XV века.
Возрождение. Начало XV — начало XVII века.
Барокко. Конец XVI — конец XVIII века.
Рококо. Начало XVIII — конец XVIII века.
Классицизм. Середина XVIII — XIX век.
Эклектика. 1830-е — 1890-е годы.
Модерн. 1890-е — 1910-е годы.
Модернизм. Начало 1900-х годов — 1980-е годы.
Конструктивизм. 1920-е годы — начало 1930-х годов.
Постмодернизм. С середины XX века.
Хай-тек. С конца 1970-х годов.
Деконструктивизм. С конца 1980-х годов.
Это глобально. В современной архитектуре тоже много течений («английский квартал» в центре Москвы и т.п.).
Серийная (массовая) застройка также определяется «типом проекта».
Что подобное мы можем сказать про ЕА?
А кто вам сказал, что она должна быть инженерной дисциплиной?
Никто. Поэтому я и говорю, что enterprise architecture — это алхимия (пока). Ну не научная же дисциплина?lair
29.11.2017 22:06Романский стиль. [...] Готика
Это архитектурные стили. Не архитектура.
Серийная (массовая) застройка также определяется «типом проекта».
… является ли "тип проекта" архитектурой? Не думаю.
Вернемся к вопросу: как вы собираетесь сравнивать "архитектуру" двух зданий? Не их типовые проекты. Не их архитектурные стили. Их "архитектуру"?
Никто. Поэтому я и говорю, что enterprise architecture — это алхимия (пока). Ну не научная же дисциплина?
А вы дисциплин кроме инженерных не признаете?
bipiem
29.11.2017 22:35применительно к зодчеству: стиль и разновидность архитектуры – это синонимы:
древнегреческая архитектура, Архитектура Древнего Рима и т.п.
Архитектура Древнего Рима употребляется ровно также как и Архитектурный стиль Древнего Рима.
Вернемся к вопросу: как вы собираетесь сравнивать «архитектуру» двух зданий? Не их типовые проекты.
Еду по новой риги и вижу пирамиду, — говорю это сооружение имеет архитектуру пирамиды.
А вы дисциплин кроме инженерных не признаете?
Признаю области изучения, которые поддаются анализу и опытной проверке. Оккультизм не признаю.lair
29.11.2017 22:47применительно к зодчеству: стиль и разновидность архитектуры – это синонимы.
… или нет. Без строго разделенных терминов получается та самая алхимия, которую вы не признаете.
Еду по новой риги и вижу пирамиду, — говорю это сооружение имеет архитектуру пирамиды.
Вот только нет такой вещи как "архитектура пирамиды". Пирамида — это только внешняя форма, а внутри там может быть что угодно, начиная от монолита и заканчивая рамочной конструкцией с натянутой тряпкой.
Но не суть. Нет ничего, что требовало бы возможность сравнения (или открытого доступа), чтобы какая-то практика стала дисциплиной. Зодчество существовало до того, как кто-то нарисовал первый архитектурный проект. Enterprise architecture начала свое существование в тот момент, когда кто-то сказал "есть такая активность, мы ведем ее так-то и называем ее так-то". Если вам не нравится эта активность — не пользуйтесь ей, никто не может вас заставить.
Признаю области изучения, которые поддаются анализу и опытной проверке.
Эм. Литературоведение? Искусствоведение вообще?
Mendel
29.11.2017 17:40Архитектура процессоров есть в открытом доступе, но покажите мне их подробные схемы. Их нет.
Так же и по предприятиям — все на виду, пока нет конкретики.bipiem
29.11.2017 22:07«подробные схемы» по процессорам — при желании найти можно (не искал, но почему — то уверен). Но вот по ЕА — у меня не вышло.
Не нужно путать: подробная схема процессора (до транзистора) и схема его архитектуры — это две разные вещи (схемы).
В архитектурных схемах и не должно быть «все до патч-корда», там должно быть показано это «Возрождение» или «Модерн» (см. wiki выше).
т.е.
Обще-архитектурные подходы, которые использованы в любом здании (предприятии) данной архитектуры.lair
29.11.2017 22:49В архитектурных схемах и не должно быть «все до патч-корда», там должно быть показано это «Возрождение» или «Модерн» (см. wiki выше).
Откуда вы берете это "должно"?
Обще-архитектурные подходы, которые использованы в любом здании (предприятии) данной архитектуры.
Вы хотите сказать, что здание, не использующее общепринятых архитектурных подходов, не может быть описано с помощью архитектуры?
bipiem
30.11.2017 21:55Откуда вы берете это «должно»?
Я говорю именно то, что считаю правильным. Можно к «должно» добавлять «по версии bipiem».
Вы хотите сказать, что здание, не использующее общепринятых архитектурных подходов, не может быть описано с помощью архитектуры?
Если у здания или микропроцессора (МП) архитектура отличная от ранее известных, т.е. сослаться не на что, то говорят, что у него «особая» архитектура. Много мы знаем МП с особой (уникальной) архитектурой? Компьютеров – полно, но у всех фактически одна из небольшого выбора архитектур (микроархитектур).
Почему тогда у каждого предприятия архитектура должна быть особой?
Разные предприятия должны строиться по типовым (стандартным) EA. ЕА может быть несколько. У Архитектур могут быть микрархитектуры (для 0xd34df00d).
Вообще, если говорить про настоявшую ЕА (в словарном понимании термина «архитектура» и без подмены на ИТ-архитектура), то они и так у большинства предприятий типовые.
Только пока «архитекторы» не научились правильно эту самую ЕА показывать в виде рисунка.
А «оригинальная архитектура» (компьютера, предприятия) — конечно имеет право быть, но лишь как исключение.lair
30.11.2017 22:03Я говорю именно то, что считаю правильным.
… и существующая практика — в любой области — вас не интересует.
Много мы знаем МП с особой (уникальной) архитектурой?
Зато вот зданий много.
Почему тогда у каждого предприятия архитектура должна быть особой?
Потому что многие (не каждое, но многие) предприятия ведут бизнес особым образом.
Вообще, если говорить про настоявшую ЕА (в словарном понимании термина «архитектура» и без подмены на ИТ-архитектура), то они и так у большинства предприятий типовые.
Вот только словарное понимание (по какому словарю, кстати) слова "архитектура" вряд ли применимо к предприятию. Поэтому так не получится.
Только пока «архитекторы» не научились правильно эту самую ЕА показывать в виде рисунка.
"Правильно" — это опять "так, как вам нравится", да?
Mendel
30.11.2017 10:25+1Еще раз. Четвертый кажется: Упрощенные и обобщенные структуры предприятий и так лежат на самом видном месте.
Возьмем для примера:
1) Высший орган управления (Учредители, Совет директоров, Министерство/ведомство и т.п.)
2) Администрация (включая канцелярию), бухгалтерия, отдел кадров
3) Административно-хозяйственное подразделение (завхоз, электрик и т.п.), Отдел АСУ (ИТ), безопасность (включая охрану), прочие подразделения для обеспечения собственной деятельности не связанные с основной деятельностью (например гараж)
4) Подразделения связанные с основной деятельностью
Ну очень крупноблочная структура. Ну очень. И даже тут я не могу даже связи прописать между ними. Слишком много специфики. Часть модулей отсутствует, часть добавляется. Часть в другое место попадает (у АТП гараж будет в производстве).
Собственно если я сделаю структуру чуть более специализированной (например поликлиника), то количество неоднозначностей только увеличится. Да структура будет уже не из четырех строчек а из тридцати, но половина текста будет «ветвлениями» (оговорками «если нужно» или «здесь или здесь» и т.п.).
При этом существует полно стандартов, рекомендаций, нормативных актов и шаблонных документов (типовые должностные инструкции и т.п.) из которых довольно просто собирается более подробная структура под более уточненный кейс. А уже допилить это напильником, чтобы учитывало специфику и было просто удобно и эффективно — работа архитектора. Ну или другого специалиста, за терминологию спорить не буду).bipiem
30.11.2017 21:10Еще раз. Четвертый кажется: Упрощенные и обобщенные структуры предприятий и так лежат на самом видном месте.
Вы привели не «обобщенные структуры предприятий», а лишь их орг-штатную структуру. Можно назвать это обобщенной моделью орг-штатки, но никак не типовой архитектурой Предприятия.
В настоящей архитектуре предприятия, орг-штатка – видимо будет показана одним квадратом «штат».
Важными элементами ЕА будут квадраты «Каталог продуктов (услуг) предприятия», «Каталог тарифов», другие объекты, типа «центральный офис и региональная сеть» и т.д.
Одним из квадратиков будет показан ИТ (и то не всегда, в компании и компьютера может не быть, а архитектура есть).
Целый ИТ – и всего один квадрат? айтишников охватил ужас?
Не нужно путать ЕА и «ИТ-архитектуру» предприятия (мухи и котлеты).
Это очень упрощенно, но показан подход к рассмотрению ЕА, как «архитектурной модели» объекта. Причем объектом может служить не только предприятие (разного масштаба), но и государство и домохозяйство (семья). Принципы подхода к описанию «архитектуры» (не ИТ-архитектуры) будут едины.
Можно детализировать далее, тогда появятся уже такие элементы: дивизионная или матричная модель управления (это тоже архитектурные компоненты).Mendel
01.12.2017 10:55+1В настоящей архитектуре предприятия
Настоящая архитектура настоящего предприятия?)
А настоящее это какое?
Большой у вас будет «каталог продуктов (услуг)» и «каталог товаров» у АТП на 200 автобусов работающих по одной цене (назначенной местными властями)? Сколько квадратиков?
А в Яндексе конечно ИТ-отдел это всего один квадратик, зачем им больше?
Да, а маркетинговый отдел у ПогранСлужбы вы в каждое подразделение добавите или только в головную службу?)
Вы повторяетесь и ходите по кругу.
То что я написал это не штат, а попытка набросать «универсальную» структуру подразделений. Дальше нужны связи между ними, процессы, метрики и т.п. Но даже крупноблочно построить универсальное невозможно ибо даже то что я написал выглядит как «нарисовать сову (четвертый пункт)».bipiem
01.12.2017 18:11-1Вы повторяетесь и ходите по кругу.
С этим согласен. Будут реальные ЕА в открытом доступе, — будет конкретика, сравнения, классификация и т.п. Не нужно будет «повторяться и кружиться». Но пока…
Вот Вы на орг-структуры упор делаете, а как быть на предприятии с 99% автоматизацией. Там ведь людей вообще не будет (почти), а архитектура будет (и не маленькая).Mendel
02.12.2017 14:47+1Вот Вы на орг-структуры упор делаете, а как быть на предприятии с 99% автоматизацией.
Кажется до вас начинает потихоньку доходить то что вам пытаются донести уже вторую неделю:
Но даже крупноблочно построить универсальное невозможно ибо даже то что я написал выглядит как «нарисовать сову (четвертый пункт)».
0xd34df00d
30.11.2017 01:02Совершенно разные компьютеры (от embedded до high-end серверов) могут иметь одну и туже архитектуру (х86)! А почему предприятия так не могут?
x86 — это в первую очередь набор команд.
Вы что-нибудь слышали о микроархитектурах? Ну там, микроархитектура Sandy Bridge, отличающаяся от неё микроархитектура Haswell, отличающаяся от них архитектура Xeon Phi, отличающаяся от них архитектура какого-нибудь Atom?bipiem
30.11.2017 20:53«х86» – чаще все же называют архитектурой. Я не против микроархитектур и в ЕА. Будут мега-архитектуры, а в них подвиды. Проблем не вижу.
Главное, чтобы это походило под термин «архитектура» (стиль, микроархитектура), применяемый как в зодчестве, так и в микроэлектроники, а еще в массе других отраслей.
Vsubb
29.11.2017 11:29По вашему примеру поликлиники не подходят :)
Скорее уж ЕА Роснефть, РЖД, Газпром… И да, ЕА у них разные. И разрабатывать каждую из них (и согласовывать) — весьма трудоемкая задача, не смотря на все существующие примеры и best practice.
Итоговые материалы очень объемны (это сотни страниц, не считая всяких презентаций) и все они — IP соответствующих компаний, поэтому в открытом доступе их нет.
Тот пример, что вы привели — скорее задача на разработку типовой ЕА для конкретных видов госучреждений или предприятий (типа школ, поликлиник и подобного). Даже не знаю, делал ли кто такую работу.
как можно вообще говорить об ЕА, если вообще нет примеров ЕА в открытом доступе
а почему нет? Далеко не все в мире есть в открытом доступе. К примеру, тех же детальных моделей процессов.
lair
28.11.2017 21:26А надо было просто выставлять контракт на разработку унифицированной архитектуры для госкомпаний определенного типа, и было бы все как вам хочется.
(только потом каждая госкомпания будет плакать, натягивая эту архитектуру на свою жизнь, но кого ж это волнует?)
bipiem
28.11.2017 23:33-1будет плакать, натягивая эту архитектуру на свою жизнь
Было бы что «натягивать». Я уже сомневаюсь, что ЕА вообще есть в природе (видимо только в воображении).
Попытки «Посмотреть на конкретный пример ЕА» все как один (два): или «купи проект по ЕА» или (самый дешевый) «пройдите наш платный курс, мы вам ТАМ покажем (и то «по секрету»)».
На улице ко мне также подходят, «кастрюльки впаривать» и рассказывают примерно также грамотно (фактически готовые ЕА — консультанты) и такие же истории, как и с ЕА: «смотри — блестит, это очень круто, купи только» плюс «у вас же специфика! Вам подойдет только эксклюзив»
Не хотел никого обидеть, но «с моей кочки зрения» выглядит именно так.
lair
28.11.2017 23:36Было бы что «натягивать».
На что госконтракт был, то и будет. Вы же говорите о том, что вы за что-то платите. Вот за что платите, то и будете натягивать.
Alpha_di
28.11.2017 15:18А касательно навыков алгоритмизации о которых шла речь, какой уровень вы подразумевается? Ну т.е. явно ведь не список разворачивать, а что-то абстрактнее и обобщение)
TS_Telecom
28.11.2017 16:05Странно, что таких системных архитекторов не учат на курсах МВА.
Пора бы заняться.
FyvaOldj
28.11.2017 17:44Чем отличается системный аналитик
от системного архитектора?a_shats
28.11.2017 17:57Это тот, кто обоснованно и в письменном виде материт предыдущего системного архитектора.
vvpoloskin
30.11.2017 23:28У нас системный аналитик анализирует входящие ТЗ от заказчика и переводит их в вид, понятный для профильных функциональных подразделений, обозначает риски при реализации. Архитектор фактически еще и сам реализует техническую составляющую — выставляет верхнеуровневые задачи на реализацию на эти самые подразделения. Разница хорошо заметна на конвейере задач. Аналитик в день анализирует 2-3 ТЗ, архитектор реализует проект от 3-х месяцев до года.
vdeneko
28.11.2017 20:23целей, ФТ, HLD
Это все хрень и тренды вида HLD, а дальше по подразделениям.
Последние 3-5 лет пошла тенденция — все инженеры, которым наскучило на месте и решили соскочить, повышают в архитекторы лишь бы не разбежались. По сути это что и был главный ИНЖЕНЕР проекта, так он и остался, назови его хоть инженером, ведущим инженером, старшим инженером или новомодным архитектором. Посмотрите статистику сколько сейчас на рынке архитекторов. Каждый третий-четвертый.
TriLka
28.11.2017 22:16-закончить проектирование
-спустя пару лет, увидеть, как это воплощается
В ИТ реализовывать проект двухлетней+ давности? Серьёзно?
kraso4niy
28.11.2017 22:52Удобна профессия и никакой ответственности.
Еще технический эксперт по готовому ТЗ 2х летней давности возьмет все и сделает и пофиг что там кому нужно и как…
А потом системный интегратор запустит ночных инженеров чтобы те исправили ошибки предыдущих. И так по кругу… а люди будут стоять в живой очереди потому что в автомат выдачи талонов сломался, а обслуживать его некому так как инженеры спят, а системные артефакторы на это не способны.
yleo
29.11.2017 03:00Свет в этой профессии/должности временами действительно есть, и очень даже яркий бывает — это когда новый архитектор сжигает всё что сделал предыдущий :)
alexunder
29.11.2017 05:06Посоветуйте навскидку парочку книг по сабжу. Спасибо!
TS_Cloud Автор
29.11.2017 11:31Из книжек последнее, что стоит прочитать — «Mastering Non-Functional Requirements» (правда, как говорит Александр, в той версии, что он читал, редактор проспал зарплату, и было грустно:)). Также рекомендуем курсы Coursera: «Making Architecture», IEBusiness School; «Planning, Auditing and Maintaining Enterprise Systems», Colorado University.
Landgraph
29.11.2017 10:11Гм… Странно, что никто ни слова не сказал о документации.
ИМХО, первый шаг на пути к архитектору — осознание того, что документация первична.
Второй шаг — это когда приходит осознание, что в основе всего лежит технология, а не решение конкретного вендора.
…
А на пике возможностей архитектор становится ещё и оракулом и видит как система будет развиваться в будущем, понимает как она будет масштабироваться в любую сторону и делает это не потому, что это написали или не написали в ТЗ, а просто потому, что не может осознанно сделать плохо. А потому даже из г… на и палок может сделать конфетку.
Jkero
29.11.2017 11:29«Мы только что сдали проект после пары недель ночных переработок, чтобы уложиться в дедлайн.» Надеюсь премии хватило на отдых на бали)))
Вообще, людям, которые так себя не уважают, что бы перерабатывать по 20 часов ночами, нельзя идти в архитекторы и проект менеджеры. При таком отношении к делу они и себе и всей команде устроят «сладкую» жизнь.
bipiem
29.11.2017 11:34Раз примеров «просто архитектуры предприятия» нет, то где посмотреть конкретный пример «системной архитектуры предприятия». Если есть «системные архитекторы», то вроде и такая архитектура должна быть.
Как она связана с другими элементами ЕА?
Системное проектирование (Systems Engineering) и «Системная архитектура» как соотносятся?
В общем, архитектор — это тот, кто принимает главные решения на проекте.
А зачем тогда руководитель проекта?
GLK9000
29.11.2017 14:37Есть 3 вида/уровня архитекторов:
Enterprise (EA)
Solution (SA)
Infrastructure (IA)
Отсюда и 3 уровня самой Архитектуры.
Сейчас чаще используется классификация именно Enterprise и Solution, а не Системнаяtw1light
29.11.2017 18:12Тут больше исходя из потребностей конкретной организации деление происходит. Если абстрагироваться от метамодели архитектуры предприятия стандарта TOGAF (в каждом из уровней которой живет по виду архитектора), то вот например:
bipiem
29.11.2017 18:44Можно заменить на «директор»: получится «ИТ-директор» (CIO), «Технический директор» (СТО) и т.д. В чем тогда разница? Типа один руководит (директор), а другой работает (архитектор)?
А если схему продолжить вниз, то появятся «Архитектор по backup», «Архитектор по картриджам» и т.д.?tw1light
30.11.2017 09:11Если посмотреть в перспективе, то можно наверное описать все это следующим образом:
для крупных организаций решивших управлять и развивать корпоративную архитектуру — есть EA архитекторы работающие в целом: корпоративный архитектор, бизнес архитектор и т.д.
на уровне проекта работает архитектор решений — он реализует конкретное бизнес решение которому посвящен проект (декомпозирует процесс по системам, возможно вводит новые функциональные компоненты и модули и т.д.), и на основе его дизайна уже происходит декомпозиция работ, которую уже в дальнейшем трэчит руководитель проекта
на уровне системной архитектуры — живут уже остальные архитекторы из картинки выше, являясь специалистами в конкретной системе, предметной области (облачные решения, big data etc) и т.д.
GLK9000
30.11.2017 08:26Видели мы эти картинки все. Всё реально зависит от масштабов.
зы: сам Архитектор, знаю :)
Sdima1357
Архитектором становишься тогда, когда сил нет терпеть архитектуру существующего кода. Или не становишься.
vdonich
«кода»
А если серьезно, имхо сдвиг начинается когда берешь другое решение (фреймворк, библиотеку, систему сборки, тп) и за пару дней делаешь то, что растягивается на недели на текущем проекте.
Sdima1357
Зависит. Иногда и так бывает. Хорошая архитектура — это когда в неё вложено мозгов больше, чем в последующее написание кода, который пишется и отлаживается тривиально. Если смогли подобрать правильную готовую архитектуру — то Вам просто повезло. Что случается далеко не всегда.
0xd34df00d
А потом тебе говорят «малаца, а теперь переписывай на том, что есть», потому что принимающие решения люди думают, что это другое решение ещё никто не знает, и брать его опасно. И снова всё на недели.
Mendel
Какие-то у вас принимающие решения — слишком идеальные.
Больнее бывает когда после длительного процесса разработки незадолго до релиза тот самый разработчик что принес новый стек самых крутых и современных технологий — уходит, в команде никто кроме него этого фреймворка не знает, и внезапно оказывается что платформа несколько сыровата и специалисты в ее экосистеме тоже в основном сыроватые, а те кто достаточно серьезные — стоят космических денег и им все равно вникать перед релизом в чужой код — слишком долго…
0xd34df00d
Конечно. Но это не совсем тот случай всё же. Не вчера появившийся очередной фреймворк для джаваскрипта или чего там появляется, да и в компании есть даже специалисты, пишущие с использованием другого решения фуллтайм.
GLK9000
Я стал Архитектором в тот момент, когда понял что Могу и Хочу больше, чем делал. И да, главное — склад ума, знания и возможность мыслить, находить «истину», даже с вредом для печени.
osipov_dv
А потом, после того как стал архитектором, приходят инженеры и показывают тебе где у тебя не порядок. Ровно так же, как это делал до этого ты :)
На мой взгляд, чисто архитектором быть не очень здорово, надо сочетать проектирование и поддержку.