Comments 111
Архитектором становишься тогда, когда сил нет терпеть архитектуру существующего кода. Или не становишься.
«кода»
А если серьезно, имхо сдвиг начинается когда берешь другое решение (фреймворк, библиотеку, систему сборки, тп) и за пару дней делаешь то, что растягивается на недели на текущем проекте.
А если серьезно, имхо сдвиг начинается когда берешь другое решение (фреймворк, библиотеку, систему сборки, тп) и за пару дней делаешь то, что растягивается на недели на текущем проекте.
Зависит. Иногда и так бывает. Хорошая архитектура — это когда в неё вложено мозгов больше, чем в последующее написание кода, который пишется и отлаживается тривиально. Если смогли подобрать правильную готовую архитектуру — то Вам просто повезло. Что случается далеко не всегда.
UFO just landed and posted this here
Какие-то у вас принимающие решения — слишком идеальные.
Больнее бывает когда после длительного процесса разработки незадолго до релиза тот самый разработчик что принес новый стек самых крутых и современных технологий — уходит, в команде никто кроме него этого фреймворка не знает, и внезапно оказывается что платформа несколько сыровата и специалисты в ее экосистеме тоже в основном сыроватые, а те кто достаточно серьезные — стоят космических денег и им все равно вникать перед релизом в чужой код — слишком долго…
Больнее бывает когда после длительного процесса разработки незадолго до релиза тот самый разработчик что принес новый стек самых крутых и современных технологий — уходит, в команде никто кроме него этого фреймворка не знает, и внезапно оказывается что платформа несколько сыровата и специалисты в ее экосистеме тоже в основном сыроватые, а те кто достаточно серьезные — стоят космических денег и им все равно вникать перед релизом в чужой код — слишком долго…
Я стал Архитектором в тот момент, когда понял что Могу и Хочу больше, чем делал. И да, главное — склад ума, знания и возможность мыслить, находить «истину», даже с вредом для печени.
А потом, после того как стал архитектором, приходят инженеры и показывают тебе где у тебя не порядок. Ровно так же, как это делал до этого ты :)
На мой взгляд, чисто архитектором быть не очень здорово, надо сочетать проектирование и поддержку.
На мой взгляд, чисто архитектором быть не очень здорово, надо сочетать проектирование и поддержку.
Граждане интересующиеся!
Понятие «системный архитектор» происходит, как это логично предположить, не от слова «система» (таких много, но это лишь частный случай), а от понятия «системный подход». Поэтому следует дифференцировать кто и что именно доносит до вас соответствующую информацию по этому поводу.
В частности, системным архитектором очень часто называют архитектора программного обеспечения, что, конечно, верно и весьма важно среди программистов. Но задолго до того, как к проекту приступят программисты, системные архитекторы более высокого порядка должны выстроить архитектуру всего проектного решения, разложив его на квадратики с пониманием того, какие технические проблемы будут решены в каждом из них и какие будут между ними связи (и по какой части). Для этого совсем недостаточно быть просто инженером, а уж тем более — руководителем проекта. Первому для начала надо приобрести большой опыт в самых разных областях проектного бытия, а вот из второго, увы, никакого системного архитектора не получится в принципе (он «заточен» на решение совсем других задач).
Как неплохо написал некто на одном из форумов, системный архитектор это человек, обладающий множеством «скилов» в разных областях и у которого большой опыт реализации разных проектов (но не с точки зрения руководства ими, а именно разносторонней технической реализации). Именно опираясь на свой опыт, знания, предыдущие ошибки, он может спроектировать что-то стоящее…
Ничуть не пытаясь хоть как-то принизить значение и достижения множества «молодых дарований», «редкая птица» из «настоящих системных архитекторов» бывает моложе 30 лет.
Но обижаться не стоит.
А надо учиться, учиться и еще раз учиться!
Понятие «системный архитектор» происходит, как это логично предположить, не от слова «система» (таких много, но это лишь частный случай), а от понятия «системный подход». Поэтому следует дифференцировать кто и что именно доносит до вас соответствующую информацию по этому поводу.
В частности, системным архитектором очень часто называют архитектора программного обеспечения, что, конечно, верно и весьма важно среди программистов. Но задолго до того, как к проекту приступят программисты, системные архитекторы более высокого порядка должны выстроить архитектуру всего проектного решения, разложив его на квадратики с пониманием того, какие технические проблемы будут решены в каждом из них и какие будут между ними связи (и по какой части). Для этого совсем недостаточно быть просто инженером, а уж тем более — руководителем проекта. Первому для начала надо приобрести большой опыт в самых разных областях проектного бытия, а вот из второго, увы, никакого системного архитектора не получится в принципе (он «заточен» на решение совсем других задач).
Как неплохо написал некто на одном из форумов, системный архитектор это человек, обладающий множеством «скилов» в разных областях и у которого большой опыт реализации разных проектов (но не с точки зрения руководства ими, а именно разносторонней технической реализации). Именно опираясь на свой опыт, знания, предыдущие ошибки, он может спроектировать что-то стоящее…
Ничуть не пытаясь хоть как-то принизить значение и достижения множества «молодых дарований», «редкая птица» из «настоящих системных архитекторов» бывает моложе 30 лет.
Но обижаться не стоит.
А надо учиться, учиться и еще раз учиться!
Архитектором становишься, когда поработал обычным пресейлом, есть опыт менеджера проектов, инженером и некий опыт продавца(хотя бы аккаунт менеджер).
Главная проблема для компании от такого архитектора состоит в том, что если он достаточно грамотен, то все проблемы с кадрами в компании вылезают на верх.
Главная проблема для компании от такого архитектора состоит в том, что если он достаточно грамотен, то все проблемы с кадрами в компании вылезают на верх.
смешались в кучу кони, люди
1. архитектору в общем случае никак не пригодится опыт продавца. опыт управления проектом нужен на самом базовом уровне.
2. аккаунт обладает гораздо более точным пониманием инфраструктуры заказчики в целом и конкретных задач. не понятно почему хотя бы
1. архитектору в общем случае никак не пригодится опыт продавца. опыт управления проектом нужен на самом базовом уровне.
2. аккаунт обладает гораздо более точным пониманием инфраструктуры заказчики в целом и конкретных задач. не понятно почему хотя бы
Согласен с вами. Часто в компаниях разнятся составы обязанностей Ахитектора. Где-то это человек, который рисует архитектуру(и составляет смету) и ему всё равно кто будет её реализовывать и продавать заказчику, а где-то обязанности архитектора заканчиваются на стадии сдачи проекта в эксплуатацию.
Не знаю что имел ввиду ваш оппонент, но я вижу плюс от опыта «продаж» в том, что человек лучше понимает кашу из хотелок, и имеет более целеориентированное мышление.
Первый комментарий к статье начался с нелюбви к плохой архитектуре. А это «ой!».
Если архитектура из говна и палок решает задачи бизнеса и имеет оптимальные показатели, то это идеальная архитектура, что бы не думал тот кто напрямую с ней работает.
Жили были три крупных провайдера в одном городе.
Еще в девяностых.
И понадобился всем троим спутниковый аплинк. Один провайдер выложил условные 100 единиц денег за него.
Второй провайдер купил часть инфраструктуры, часть соорудили из подручных средств в своей лаборатории (которая была довольно серьезная) и обошлись 50 единиц денег.
Третий провайдер выкинул половину инфраструктуры, уложился в 20 единиц денег, правда раз в час у них на крышу выходил дежурный техник и подкручивал положение тарелки. Поскольку это был не единственный аплинк и дело было в девяностых, то SLA позволяло.
Я думаю понятно у кого был самый высокий ROI.
И да, в живых из них сейчас остался только тот у кого была своя лаборатория, но это уже другая история…
Так вот, я утверждаю что плевать как оценивает архитектуру техник которому приходится подкручивать тарелку. Умерли они по совсем другой причине. Продажник (пусть и слабый) лучше сможет понять хотелки бизнеса, лучше сможет донести до бизнеса скрытые риски и опасность технического долга который игнорируется бизнесом (на понятном бизнесу языке, а не так чтобы бизнес решил что чуваку просто лень крутить гайки на тарелке), и что еще важнее — продажник такая сволочь которая игнорирует кучу важных вещей в угоду тому чтобы продать. Для того чтобы видеть важное и второстепенное одного аналитического склада ума недостаточно. Технарь хочет сделать красивую технологичную структуру. Продажник хочет продать, и красота и технологичность важна лишь постольку поскольку помогает продавать.
Гигагерцы, дюймы и гигапиксели интересуют его лишь постольку поскольку. Для него они средство. Для инженера — цель.
Этому нельзя научиться в чисто технической среде.
И «продажи» в этом могут помочь. А могут и не помочь конечно…
Первый комментарий к статье начался с нелюбви к плохой архитектуре. А это «ой!».
Если архитектура из говна и палок решает задачи бизнеса и имеет оптимальные показатели, то это идеальная архитектура, что бы не думал тот кто напрямую с ней работает.
Жили были три крупных провайдера в одном городе.
Еще в девяностых.
И понадобился всем троим спутниковый аплинк. Один провайдер выложил условные 100 единиц денег за него.
Второй провайдер купил часть инфраструктуры, часть соорудили из подручных средств в своей лаборатории (которая была довольно серьезная) и обошлись 50 единиц денег.
Третий провайдер выкинул половину инфраструктуры, уложился в 20 единиц денег, правда раз в час у них на крышу выходил дежурный техник и подкручивал положение тарелки. Поскольку это был не единственный аплинк и дело было в девяностых, то SLA позволяло.
Я думаю понятно у кого был самый высокий ROI.
И да, в живых из них сейчас остался только тот у кого была своя лаборатория, но это уже другая история…
Так вот, я утверждаю что плевать как оценивает архитектуру техник которому приходится подкручивать тарелку. Умерли они по совсем другой причине. Продажник (пусть и слабый) лучше сможет понять хотелки бизнеса, лучше сможет донести до бизнеса скрытые риски и опасность технического долга который игнорируется бизнесом (на понятном бизнесу языке, а не так чтобы бизнес решил что чуваку просто лень крутить гайки на тарелке), и что еще важнее — продажник такая сволочь которая игнорирует кучу важных вещей в угоду тому чтобы продать. Для того чтобы видеть важное и второстепенное одного аналитического склада ума недостаточно. Технарь хочет сделать красивую технологичную структуру. Продажник хочет продать, и красота и технологичность важна лишь постольку поскольку помогает продавать.
Гигагерцы, дюймы и гигапиксели интересуют его лишь постольку поскольку. Для него они средство. Для инженера — цель.
Этому нельзя научиться в чисто технической среде.
И «продажи» в этом могут помочь. А могут и не помочь конечно…
месье знает толк в извращениях
Правда ли, что возможно расти до архитектора только в рамках одной компании, или можно быть инженером и перейти в другую компанию архитектором?
Системный архитектор — очень определённый образ мышления и определённый склад ума. А «системный», от «системный подход», а не от система.
И стать СА может и бывший тимлид, и сетевик, и даже DBA. Вообще кто угодно, кто дорос до того, чтобы решать бизнес-задачу заказчика, а не только задачу ИТ (как описано тут) или ИТ-директора. Хороший системный архитектор способен написать ФЦП по информартизации ведомства или план создания комплексной информационной системы решающей проблемы целой отрасли (разумеется возглавляя команду аналитиков и архитекторов прикладного и инфраструктурного уровня, а не в одиночку). Настоящий СА никогда не заходит в тупик и не говорит, «нам не хватает данных». Он всегда знает как пройти дальше и как подойти к задаче, которая кажется неразрешимой.
И стать СА может и бывший тимлид, и сетевик, и даже DBA. Вообще кто угодно, кто дорос до того, чтобы решать бизнес-задачу заказчика, а не только задачу ИТ (как описано тут) или ИТ-директора. Хороший системный архитектор способен написать ФЦП по информартизации ведомства или план создания комплексной информационной системы решающей проблемы целой отрасли (разумеется возглавляя команду аналитиков и архитекторов прикладного и инфраструктурного уровня, а не в одиночку). Настоящий СА никогда не заходит в тупик и не говорит, «нам не хватает данных». Он всегда знает как пройти дальше и как подойти к задаче, которая кажется неразрешимой.
Вот то, что описано в статье — это не обязанности архитектора. С клиентом должен общаться проект-менеджер: он должен заниматься всей этой «психологией». Совсем недавно была отличная статья на Хабре habrahabr.ru/company/technoserv/blog/342494 про роли в команде.
Общаться надо для уточнения задач на техническом уровне и для этого необходимо отличное понимание области, чего не будет у PM. Хотя PM на встречах также необходим, конечно же
И Аналитика не забудьте! ПМ, Аналитик, Архитектор — «святая троица». Один занимается «психологией» и растит печень, другой отделяет существенное от несущественного (собирает требования), третий знает что реализуемо, что нет и, если реализуемо, как.
И Аналитика не забудьте!
Хочется добавить: и Главного конструктора не забудьте!
Когда то было достаточно Главного конструктора изделия ххх и конструкторов его составных частей. Было достаточно 34.ххх и более серьезных РВ 15.ххх.
Страна создавала и использовала собственные Best Practice, покоряла космос, атом.
А теперь PM, западные методологии (PMBOK, CBOK, ITIL, TOGAF и еще десяток подобного), западные решения, западное всё.
Но это так, «к слову», просто о «забытом» Главном конструкторе навеяло.
Ну а разве главный конструктор на производстве не является прямым аналогом архитектора из мира ИТ?
UFO just landed and posted this here
Напомнило подход моих глобальных коллег из Штатов:
- давайте обсудим теперь миграцию AD — вот такой есть вопрос про DHCP
- э нееет, у нас на колле нет архитектора DHCP, у нас только архитектор DNS есть, надо переносить звонок..
Я правильно понимаю, что системный архитектор не занимается проектированием архитектуры приложения?
У нас занимается. Но на уровне целей, ФТ, HLD. За декомпозицией — к «прикладникам».
Тут просто несколько понятий смешны в одно. Архитекторы бывают разные. Может быть архитектор решения (иначе solution architect), системных архитектор, перфоманс архитектор и тд. Первый занимается больше бизнес вопросами, общением с кастомером, знает как и что с функциональной точки зрения работает и высокоуровневым функциональным анализом того, как новые изменения будут ложиться на текущее решение. Системный архитектор как раз занимается тем, что большинство привыкли принимать за архитектора в ит: знает кодовую базу приложения, как и что с чем работает, по каким протоколам, секьюрити вопросы, возможно как что декомпозировано в коде и так далее. Он как раз участвует в разработке системы и свысока смотрит чтобы все было более-менее так, как он задумывал и помогает в случае проблем при разработке. Перфоманс архитектор занимается непосредственно перфомансом и помогает при проектировании сделать так, чтобы все нефункциональные требования были удовлетворены и с запасом на будущее (у нормальных проектов обычно есть планы по расширению на ближайшие лет 5 минимум). Понятно, что идеальный софт архитектор в вакууме должен совмещать все эти три сферы, но таких людей очень мало, да и скорее всего в случае больших систем таких людей физически не существует, потому что просто не хватит времени на решение этих вопросов и накопления знаний. И в больших проектах в связи с этим архитекторов обычно и делят на данные три типа и каждый решают свою задачу. Тут наверное стоит нарисовать треугольник, как в КАП теореме, где вершинами будут бизнес, системная производительность и архитектура приложения и мапить на нее. Идеальный с моей точки зрения архитектор должен быть где-то в середине треугольника, а для критичных вопросов должна быть компетентная команда, которую архитектор и помог набрать. Как-то так
где вершинами будут бизнес, системная производительность и архитектура приложения и мапить на нее.
Идеальный с моей точки зрения архитектор должен быть где-то в середине треугольника, а для критичных вопросов должна быть компетентная команда, которую архитектор и помог набрать. Как-то так
Примерно так. Но с уточнением. В этом треугольнике только один угол — ИТ. И то при условии, что ИТ вообще есть в компании (развито).
Поэтому, «архитектор предприятия» — это тот, кто немного понимает в бизнесе предприятия, немного в технологическом процессе производства на предприятии (технолог) и немного в ИТ. Причем, в ИТ — в последнюю очередь.
Вот такой архитектор и стоит посредине этого треугольника. А то, что ИТ «тянут» одеяло на себя, называя ИТ-архитектора — просто архитектором предприятия — так это и есть «маркетинговый трюк». Такой подход справедлив для предприятий с 99% коэффициентом автоматизации. Но таких о-очень мало.
Не нужно путать «архитекторов предприятия» с ИТ-архитекторами предприятия. Это подмена понятий.
Похожая аналогия с главным инженером предприятия (или главным инженером проекта): он всего знает понемногу, но если возникает вопрос по канализации, он зовет соответствующего зама, если по пожарной сигнализации — то по ней. Но в целом знает обо всем, т.к. он «внутри треугольника».
Крутым архитекторам должно быть известно, что такое «Архитектура предприятия».
Дайте, пожалуйста, пару ссылок на подробное описание какой-либо такой архитектуры реального или вымышленного предприятия. Не общие подходы и не отсылки на всякие там ТОГАФы, а именно подробный конкретный пример.
Несколько лет ищу пример архитектуры, а попадаются только архитекторы.
Дайте, пожалуйста, пару ссылок на подробное описание какой-либо такой архитектуры реального или вымышленного предприятия. Не общие подходы и не отсылки на всякие там ТОГАФы, а именно подробный конкретный пример.
Несколько лет ищу пример архитектуры, а попадаются только архитекторы.
Спасибо за мысль! Если мы найдём такой отдельный и без NDA, сделаем отдельный пост и попробуем объяснить, что, откуда и почему взялось. Однако, кажется, далеко не любой бизнес-заказчик хотел бы это увидеть. Скорее, наоборот, слишком уж много данных на входе, которые мало кому снаружи надо знать.
Я ожидал услышать стандартный ответ: мы «системные архитекторы», а про «просто архитектуру» (предприятия, EA) спрашивайте у просто архитекторов.
Ваш ответ пока только «вселяет надежду».
Столько времени заниматься ЕА и нет ни одного примера, который не стыдно показать?
NDA — стандартная отговорка. При желании меняются названия, «пароли-явки», дается подпись «все совпадения случайны» и т.п.
Ваш ответ пока только «вселяет надежду».
Столько времени заниматься ЕА и нет ни одного примера, который не стыдно показать?
NDA — стандартная отговорка. При желании меняются названия, «пароли-явки», дается подпись «все совпадения случайны» и т.п.
это же IP. кто же будет задаром такое раздавать? если только на верхнем уровне совсем как часть success story
Посмотрим на этот IP — со стороны нас, обычных граждан — налогоплательщиков. Одна компания разработала EA для госкомпании 1. Мы (налогоплательщики) заплатили. Далее эта же или другая компания разработала для госкомпании 2 тоже EA. Причем точно такую же. Мы снова заплатили.
Далее снова для госкомпании 3 сделали такую же ЕА, и нас снова обобрали.
Какое к \ на … IP? Если за одно и то (одну и туже EA) мы платим свои же (бюджетные) деньги?
Тем самым не только народ обирают, но и ВВП накручивают (поставляя одного и тогож, но беря за разработку сполна «как положено»).
Я про унификацию, тиражирование, гласность, повторное использование (заимствование), эффективное применение ранее уплаченных бюджетных средств (т.е. моих и твоих), оптимизацию НАРОДНЫХ инвестиций.
Далее снова для госкомпании 3 сделали такую же ЕА, и нас снова обобрали.
Какое к \ на … IP? Если за одно и то (одну и туже EA) мы платим свои же (бюджетные) деньги?
Тем самым не только народ обирают, но и ВВП накручивают (поставляя одного и тогож, но беря за разработку сполна «как положено»).
Я про унификацию, тиражирование, гласность, повторное использование (заимствование), эффективное применение ранее уплаченных бюджетных средств (т.е. моих и твоих), оптимизацию НАРОДНЫХ инвестиций.
UFO just landed and posted this here
Песню, что каждое предприятие должно быть уникальным с уникальной ЕА (и СА кстати тоже) — поется как раз теми, кто продает «разные ЕА». Типизация и унификация явно не в их интересах. Чем ЕА у «Детская поликлиника №1» будет отличаться от ЕА у «Детская поликлиника №2»?
Но мой вопрос глубже: как можно вообще говорить об ЕА, если вообще нет примеров ЕА в открытом доступе?
Может EA нет и в природе? А может быть ЕА — это такой же «голый король»?
Но мой вопрос глубже: как можно вообще говорить об ЕА, если вообще нет примеров ЕА в открытом доступе?
Может EA нет и в природе? А может быть ЕА — это такой же «голый король»?
UFO just landed and posted this here
Откуда берутся деньги, как они тратятся, как это контролируется, как это будет развиваться,
Эээ, куда занесло. А как же бизнес-план, бизнес-стратегия, бизнес-модель и бизнес-«хх» и т.п. Это все и есть EA?
Это просто формализация бизнес процессов.
EA = формализация бизнес процессов? Снова не угадали.
Гуглите enterprise architecture examples.
Гуглил, и не один год. Исключительно одна реклама вендоров ПО и консалтеров и общие подходы типа ТОГАФ. Ни одного конкретного полного примера. Даже просил уважаемых специалистов привести пример тут (см. комментарии про бизнесясли):
Чем ЕА у «Детская поликлиника №1» будет отличаться от ЕА у «Детская поликлиника №2»?
Черт, спать пора, но уж очень болит мозоль на который вы наступили. Вроде и давно было, но…
Один орган государственной власти решил вдруг автоматизироваться.
Кинули клич и оказалось что в одной области есть отличная система. Все функции автоматизированы. Айда покупать эту систему и внедрять по всей стране. (С откатами конечно огромными, но не суть, откат могут и нормальные разработчики дать).
Не ну а чё? Если в одной области прокатило, то и у других прокатит.
Правда область где разрабатывалось была «внутренней» и не имела не то что портов, а даже автомобильных границ. У них всех инспекторов области можно было собрать в кабинете начальника… в крупнейшей области только руководителей подразделений в один актовый зал одновременно собрать было нельзя, собирали в трех, в разных районах области (руководителей, без рядовых инспекторов).
Но даже без таких явных перегибов.
Спустя пару лет в системе даже некоторая специфика портов отражена была.
В крупнейшей области (крупнейшей для данного органа власти) максимальная вместимость пароходов — 60тыс тон на судно. В другой области где есть порты — 5 тыс. тон. Соответственно выплывали очень специфичные моменты, например то что на одном судне могло быть десять отправителей (у каждого груз из разных областей) и десять получателей (причем у каждого получателя частично в разных портах разгрузка), причем все они грузятся равномерно во все шесть трюмов (сыпучий груз). У судов которые в десять раз меньше количество комбинаций экспоненциально меньше.
Ну и мой любимый простенький пример.
Наблюдал как проверяющая из области с маленькими портами (практик, не теоретик — много лет работала в подразделении обслуживающим порты) докапалась до инспектора из крупного порта. Мол почему такие-то документы (идущие с каждой машиной привезшей груз) не лежат в деле по судну. Я там случайно оказался, думал зайти к ним, но как увидел из двери, так понял что не зайду… уж больно сдержаться сложно было.
Мужик сказал «ща!», ушел. Взял дело которое она смотрела (папка сантиметров пятнадцать толщиной), положил рядом с ней, открыл шкаф, достал стопку тех документов что она просила, и положил прямо перед ней со словами «не влазят!». Стопка была сантиметров семьдесят толщиной.
Тетка не теоретик. Практик.
Много лет руководила подобным подразделением. И грузопоток у нее приличный был. Только суда помельче…
Вы скажете «Но поликлиники то больше похожи!» и будете не правы.
поликлиники тоже разные. А вот в чем разные — для этого куча работы по выяснению и анализу…
ПС: при этом разделяю позицию о том что примеры проектов, типовые планы и т.п. должны публиковаться. Да даже сделанные за бюджетные деньги разработки должны частично публиковаться. Я чисто про «отличаться». Не мог удержаться простите…
Я чисто про «отличаться». Не мог удержаться простите…
Снова путаем «мухи и котлеты» (см. одноименный цикл статей bipiem).
Да, поликлиники могут быть разными (одни лечат, другие калечат), но «Архитектура предприятия» у них может быть (и должна быть) — одинаковой.
Это принципиальный момент: предприятия должны " отличаться ", но их архитектуры — нет!
Во всяком случае, утверждение: «каждому предприятию — своя уникальная архитектура» — это не верно. Для того и придуман термин «архитектура».
Посмотрим на термин внимательнее.
Архитектура — это некий каркас (ребро, арка, колонна и т.п.), общие подходы к построению здания или предприятия. Зданий разных много, но именно архитектур — мало.
Посмотрим на «Архитектура ПК» или сразу наберем «архитектура х86». Все картинки примерно одинаковые: шина данных, шина адреса, шина управления и т.п.
Совершенно разные компьютеры (от embedded до high-end серверов) могут иметь одну и туже архитектуру (х86)! А почему предприятия так не могут?
С «архитектурными подходами» в зодчестве и компьютерной технике — все понятно. А вот с EA — нет, в нем в понятие «архитектура» — вкладывают иной смысл (маркетинговый). Зачем?
Так и архитектур предприятий должно быть не много. Мне бы хоть одну увидеть (пока только «100 раз услышал»). Кто видел ее хоть раз, своими глазами?
Айда покупать эту систему и внедрять по всей стране
типовая система и типовая архитектура — это разные вещи.
Архитектура — это некий каркас (ребро, арка, колонна и т.п.), общие подходы к построению здания или предприятия. Зданий разных много, но именно архитектур — мало.
Вы, простите, каким конкретно определением архитектуры предприятия пользуетесь?
Я использую классический термин Архитектура (из русского языка). Этот термин (повторюсь) обозначает некий скелет, референтную (эталонную) модель, концепт (концептуальную модель), механизм абстрагирования от конкретики (абстракция).
В части строительства: абстрагироваться от привычного восприятия зданий как конкретного строения, но указать общий стиль подобных сооружений. Для «х86» — это общая концепция организации вычислений, реализованная в конкретном семействе микропроцессоров.
Про определение «Архитектура предприятие».
Ну, хорошо, для «enterprise» ЕА это очень круто, дорого и секретно. А если взять простое небольшое предприятие и зарисовать его ЕА?
Еще лучше взять вообще неавтоматизированное предприятие, где вообще нет компьютеров (а у бухгалтеров — счеты).
Там что нет «Архитектуры предприятия»?
т.е. предприятие есть, но без архитектуры? Как можно решать сложные задачи, если на простые нет ответа?
Очевидно, что даже у предприятия, у которого нет компьютеров и калькуляторов — есть «Архитектура предприятия» и правильное определение «Архитектуры предприятия» — должно это учитывать.
ЕА — Это архитектурное представление предприятия в целом. Даже предприятия, в котором вообще нет ИТ. Поэтому говорить, что в состав EA обязательно входят «Системная архитектура», «Архитектура приложений» и т.п. — неверно.
В части строительства: абстрагироваться от привычного восприятия зданий как конкретного строения, но указать общий стиль подобных сооружений. Для «х86» — это общая концепция организации вычислений, реализованная в конкретном семействе микропроцессоров.
Про определение «Архитектура предприятие».
Ну, хорошо, для «enterprise» ЕА это очень круто, дорого и секретно. А если взять простое небольшое предприятие и зарисовать его ЕА?
Еще лучше взять вообще неавтоматизированное предприятие, где вообще нет компьютеров (а у бухгалтеров — счеты).
Там что нет «Архитектуры предприятия»?
т.е. предприятие есть, но без архитектуры? Как можно решать сложные задачи, если на простые нет ответа?
Очевидно, что даже у предприятия, у которого нет компьютеров и калькуляторов — есть «Архитектура предприятия» и правильное определение «Архитектуры предприятия» — должно это учитывать.
ЕА — Это архитектурное представление предприятия в целом. Даже предприятия, в котором вообще нет ИТ. Поэтому говорить, что в состав EA обязательно входят «Системная архитектура», «Архитектура приложений» и т.п. — неверно.
Я использую классический термин Архитектура (из русского языка).
В языке нет терминов, термины есть только в предметных областях. И одно и то же слово в разных предметных областях может иметь разные значения (а где-то и вовсе не быть термином).
Этот термин (повторюсь) обозначает
В русском языке это слово обычно обозначает дисциплину (вид деятельности), вид искусства (оба этих варианта покрываются словом "зодчество"), а еще "совокупность зданий и сооружений, создающих пространственную среду для жизни и деятельности человека" (все определения по википедии). Ничто из этого не совпадает с вашим "определением", кстати.
А если взять простое небольшое предприятие и зарисовать его ЕА?
Ну возьмите и зарисуйте.
Нее. Вообще не так.
Общая структура это слишком неконкретно.
Ну возьмите «типовое положение» для поликлиники (типовой устав для частников), в нем общее описание будет.
Типовое положение, iso9000, МСФО, типовое штатное расписание для общей структуры — вот и вся «общая архитектура на общих принципах».
Дальше уже только частности идут.
Нет, я не против того чтобы архитектуру (как техническую так и операционную) госпредприятий разрабатывали максимально универсально, чтобы заказывали что-то глобальное, но… универсальное решение на несколько порядков дороже единичного.
Общая структура это слишком неконкретно.
Ну возьмите «типовое положение» для поликлиники (типовой устав для частников), в нем общее описание будет.
Типовое положение, iso9000, МСФО, типовое штатное расписание для общей структуры — вот и вся «общая архитектура на общих принципах».
Дальше уже только частности идут.
Нет, я не против того чтобы архитектуру (как техническую так и операционную) госпредприятий разрабатывали максимально универсально, чтобы заказывали что-то глобальное, но… универсальное решение на несколько порядков дороже единичного.
Нее. Вообще не так.
Вы согласны, что термин «архитектура» — имеет одинаковое смысловое выражение в терминах «архитектура здания» (зодчество), «архитектура предприятия», «архитектура компьютера»?
Можно найти список всех популярных архитектур зодчества, компьютерных архитектур.
Понятно, что есть разные уровни (направления) классификации, например, RISC, CISC и др., или х86 и IBM System / 360, но они (списки, каталоги) конечные и публикуемые.
Почему «архитектура предприятия» не выдержана в том же ключе (подходе)?
Может это все же не «архитектура», если свойства непосредственно «архитектуры» (сущности термина) у «современной ЕА» (современном подходе к ЕА) отсутствуют?
Вы согласны, что термин «архитектура» — имеет одинаковое смысловое выражение в терминах «архитектура здания» (зодчество), «архитектура предприятия», «архитектура компьютера»?
Я вот не согласен.
Может это все же не «архитектура», если свойства непосредственно «архитектуры» (сущности термина) у «современной ЕА» (современном подходе к ЕА) отсутствуют?
Нет никакой "сущности термина", потому что термин существует только в конкретной прикладной области. У понятия enterprise architecture в рамках одноименной дисциплины есть определение. Если оно вам не нравится — вы его не используете эту дисциплину. Сколько угодно.
Если оно вам не нравится — вы его не используете эту дисциплину
Лишнее "его".
Нет никакой «сущности термина», потому что термин существует только в конкретной прикладной области. У понятия enterprise architecture в рамках одноименной дисциплины есть определение.
1) Если общепринятое понятие «архитектура» в словосочетании «Архитектура предприятия» имеет совсем иной смысл, то логичнее назвать НОВЫЙ вводимый термин ЕА иначе или хотя бы подчеркивать, что в ЕА используется иное понимание «архитектура» по сравнению со всеми остальными сочетаниями этого («архитектура») термина.
2) «есть определение» — есть куча определений ЕА, Вы сами спрашивали «какое имеется ввиду» (пользуетесь).
3) В том то и дело, что нет дисциплины (инженерной дисциплины). Есть область мифологии, алхимии в отношении ЕА, а настоящей дисциплины ЕА — пока, к сожалению, нет. Она появится как минимум тогда, когда примеры ЕА появятся в открытом доступе и можно будет однозначно сказать: у этого и этого предприятия архитектура х1024, а у тех трех архитектура х2048".
Когда можно будет сравнивать архитектуры между собой.
Пока нечего сравнивать. Пока можно только говорить о «тайных» архитектурах, не факт, что реально существующих.
ЕА — Парадокс: Архитекторов — много, а архитектур — нет.
Если общепринятое понятие «архитектура» в словосочетании «Архитектура предприятия» имеет совсем иной смысл, то логичнее назвать НОВЫЙ вводимый термин ЕА иначе или хотя бы подчеркивать, что в ЕА
Если. И, что важнее, логичнее было назвать. Этому словосочетанию никак не меньше 15 лет уже, и трогать устоявшееся словоупотребление бесполезно.
«есть определение» — есть куча определений ЕА,
Да, каждое в рамках своего направления практики.
В том то и дело, что нет дисциплины (инженерной дисциплины)
А кто вам сказал, что она должна быть инженерной дисциплиной?
Она появится как минимум тогда, когда примеры ЕА появятся в открытом доступе
Это ваш собственный критерий, и практике на него более-менее наплевать. Как и единорогам.
у этого и этого предприятия архитектура х1024, а у тех трех архитектура х2048".
Вы вот так любите сравнивать с зодчеством, а вот вы можете про здания это сказать?
Когда можно будет сравнивать архитектуры между собой.
А вы можете сравнить между собой "архитектуры" двух зданий? Как это выглядит?
А вы можете сравнить между собой «архитектуры» двух зданий? Как это выглядит?
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 — это алхимия (пока). Ну не научная же дисциплина?
Романский стиль. [...] Готика
Это архитектурные стили. Не архитектура.
Серийная (массовая) застройка также определяется «типом проекта».
… является ли "тип проекта" архитектурой? Не думаю.
Вернемся к вопросу: как вы собираетесь сравнивать "архитектуру" двух зданий? Не их типовые проекты. Не их архитектурные стили. Их "архитектуру"?
Никто. Поэтому я и говорю, что enterprise architecture — это алхимия (пока). Ну не научная же дисциплина?
А вы дисциплин кроме инженерных не признаете?
применительно к зодчеству: стиль и разновидность архитектуры – это синонимы:
древнегреческая архитектура, Архитектура Древнего Рима и т.п.
Архитектура Древнего Рима употребляется ровно также как и Архитектурный стиль Древнего Рима.
Еду по новой риги и вижу пирамиду, — говорю это сооружение имеет архитектуру пирамиды.
Признаю области изучения, которые поддаются анализу и опытной проверке. Оккультизм не признаю.
древнегреческая архитектура, Архитектура Древнего Рима и т.п.
Архитектура Древнего Рима употребляется ровно также как и Архитектурный стиль Древнего Рима.
Вернемся к вопросу: как вы собираетесь сравнивать «архитектуру» двух зданий? Не их типовые проекты.
Еду по новой риги и вижу пирамиду, — говорю это сооружение имеет архитектуру пирамиды.
А вы дисциплин кроме инженерных не признаете?
Признаю области изучения, которые поддаются анализу и опытной проверке. Оккультизм не признаю.
применительно к зодчеству: стиль и разновидность архитектуры – это синонимы.
… или нет. Без строго разделенных терминов получается та самая алхимия, которую вы не признаете.
Еду по новой риги и вижу пирамиду, — говорю это сооружение имеет архитектуру пирамиды.
Вот только нет такой вещи как "архитектура пирамиды". Пирамида — это только внешняя форма, а внутри там может быть что угодно, начиная от монолита и заканчивая рамочной конструкцией с натянутой тряпкой.
Но не суть. Нет ничего, что требовало бы возможность сравнения (или открытого доступа), чтобы какая-то практика стала дисциплиной. Зодчество существовало до того, как кто-то нарисовал первый архитектурный проект. Enterprise architecture начала свое существование в тот момент, когда кто-то сказал "есть такая активность, мы ведем ее так-то и называем ее так-то". Если вам не нравится эта активность — не пользуйтесь ей, никто не может вас заставить.
Признаю области изучения, которые поддаются анализу и опытной проверке.
Эм. Литературоведение? Искусствоведение вообще?
Архитектура процессоров есть в открытом доступе, но покажите мне их подробные схемы. Их нет.
Так же и по предприятиям — все на виду, пока нет конкретики.
Так же и по предприятиям — все на виду, пока нет конкретики.
«подробные схемы» по процессорам — при желании найти можно (не искал, но почему — то уверен). Но вот по ЕА — у меня не вышло.
Не нужно путать: подробная схема процессора (до транзистора) и схема его архитектуры — это две разные вещи (схемы).
В архитектурных схемах и не должно быть «все до патч-корда», там должно быть показано это «Возрождение» или «Модерн» (см. wiki выше).
т.е.
Обще-архитектурные подходы, которые использованы в любом здании (предприятии) данной архитектуры.
Не нужно путать: подробная схема процессора (до транзистора) и схема его архитектуры — это две разные вещи (схемы).
В архитектурных схемах и не должно быть «все до патч-корда», там должно быть показано это «Возрождение» или «Модерн» (см. wiki выше).
т.е.
Обще-архитектурные подходы, которые использованы в любом здании (предприятии) данной архитектуры.
В архитектурных схемах и не должно быть «все до патч-корда», там должно быть показано это «Возрождение» или «Модерн» (см. wiki выше).
Откуда вы берете это "должно"?
Обще-архитектурные подходы, которые использованы в любом здании (предприятии) данной архитектуры.
Вы хотите сказать, что здание, не использующее общепринятых архитектурных подходов, не может быть описано с помощью архитектуры?
Откуда вы берете это «должно»?
Я говорю именно то, что считаю правильным. Можно к «должно» добавлять «по версии bipiem».
Вы хотите сказать, что здание, не использующее общепринятых архитектурных подходов, не может быть описано с помощью архитектуры?
Если у здания или микропроцессора (МП) архитектура отличная от ранее известных, т.е. сослаться не на что, то говорят, что у него «особая» архитектура. Много мы знаем МП с особой (уникальной) архитектурой? Компьютеров – полно, но у всех фактически одна из небольшого выбора архитектур (микроархитектур).
Почему тогда у каждого предприятия архитектура должна быть особой?
Разные предприятия должны строиться по типовым (стандартным) EA. ЕА может быть несколько. У Архитектур могут быть микрархитектуры (для 0xd34df00d).
Вообще, если говорить про настоявшую ЕА (в словарном понимании термина «архитектура» и без подмены на ИТ-архитектура), то они и так у большинства предприятий типовые.
Только пока «архитекторы» не научились правильно эту самую ЕА показывать в виде рисунка.
А «оригинальная архитектура» (компьютера, предприятия) — конечно имеет право быть, но лишь как исключение.
Я говорю именно то, что считаю правильным.
… и существующая практика — в любой области — вас не интересует.
Много мы знаем МП с особой (уникальной) архитектурой?
Зато вот зданий много.
Почему тогда у каждого предприятия архитектура должна быть особой?
Потому что многие (не каждое, но многие) предприятия ведут бизнес особым образом.
Вообще, если говорить про настоявшую ЕА (в словарном понимании термина «архитектура» и без подмены на ИТ-архитектура), то они и так у большинства предприятий типовые.
Вот только словарное понимание (по какому словарю, кстати) слова "архитектура" вряд ли применимо к предприятию. Поэтому так не получится.
Только пока «архитекторы» не научились правильно эту самую ЕА показывать в виде рисунка.
"Правильно" — это опять "так, как вам нравится", да?
Еще раз. Четвертый кажется: Упрощенные и обобщенные структуры предприятий и так лежат на самом видном месте.
Возьмем для примера:
1) Высший орган управления (Учредители, Совет директоров, Министерство/ведомство и т.п.)
2) Администрация (включая канцелярию), бухгалтерия, отдел кадров
3) Административно-хозяйственное подразделение (завхоз, электрик и т.п.), Отдел АСУ (ИТ), безопасность (включая охрану), прочие подразделения для обеспечения собственной деятельности не связанные с основной деятельностью (например гараж)
4) Подразделения связанные с основной деятельностью
Ну очень крупноблочная структура. Ну очень. И даже тут я не могу даже связи прописать между ними. Слишком много специфики. Часть модулей отсутствует, часть добавляется. Часть в другое место попадает (у АТП гараж будет в производстве).
Собственно если я сделаю структуру чуть более специализированной (например поликлиника), то количество неоднозначностей только увеличится. Да структура будет уже не из четырех строчек а из тридцати, но половина текста будет «ветвлениями» (оговорками «если нужно» или «здесь или здесь» и т.п.).
При этом существует полно стандартов, рекомендаций, нормативных актов и шаблонных документов (типовые должностные инструкции и т.п.) из которых довольно просто собирается более подробная структура под более уточненный кейс. А уже допилить это напильником, чтобы учитывало специфику и было просто удобно и эффективно — работа архитектора. Ну или другого специалиста, за терминологию спорить не буду).
Возьмем для примера:
1) Высший орган управления (Учредители, Совет директоров, Министерство/ведомство и т.п.)
2) Администрация (включая канцелярию), бухгалтерия, отдел кадров
3) Административно-хозяйственное подразделение (завхоз, электрик и т.п.), Отдел АСУ (ИТ), безопасность (включая охрану), прочие подразделения для обеспечения собственной деятельности не связанные с основной деятельностью (например гараж)
4) Подразделения связанные с основной деятельностью
Ну очень крупноблочная структура. Ну очень. И даже тут я не могу даже связи прописать между ними. Слишком много специфики. Часть модулей отсутствует, часть добавляется. Часть в другое место попадает (у АТП гараж будет в производстве).
Собственно если я сделаю структуру чуть более специализированной (например поликлиника), то количество неоднозначностей только увеличится. Да структура будет уже не из четырех строчек а из тридцати, но половина текста будет «ветвлениями» (оговорками «если нужно» или «здесь или здесь» и т.п.).
При этом существует полно стандартов, рекомендаций, нормативных актов и шаблонных документов (типовые должностные инструкции и т.п.) из которых довольно просто собирается более подробная структура под более уточненный кейс. А уже допилить это напильником, чтобы учитывало специфику и было просто удобно и эффективно — работа архитектора. Ну или другого специалиста, за терминологию спорить не буду).
Еще раз. Четвертый кажется: Упрощенные и обобщенные структуры предприятий и так лежат на самом видном месте.
Вы привели не «обобщенные структуры предприятий», а лишь их орг-штатную структуру. Можно назвать это обобщенной моделью орг-штатки, но никак не типовой архитектурой Предприятия.
В настоящей архитектуре предприятия, орг-штатка – видимо будет показана одним квадратом «штат».
Важными элементами ЕА будут квадраты «Каталог продуктов (услуг) предприятия», «Каталог тарифов», другие объекты, типа «центральный офис и региональная сеть» и т.д.
Одним из квадратиков будет показан ИТ (и то не всегда, в компании и компьютера может не быть, а архитектура есть).
Целый ИТ – и всего один квадрат? айтишников охватил ужас?
Не нужно путать ЕА и «ИТ-архитектуру» предприятия (мухи и котлеты).
Это очень упрощенно, но показан подход к рассмотрению ЕА, как «архитектурной модели» объекта. Причем объектом может служить не только предприятие (разного масштаба), но и государство и домохозяйство (семья). Принципы подхода к описанию «архитектуры» (не ИТ-архитектуры) будут едины.
Можно детализировать далее, тогда появятся уже такие элементы: дивизионная или матричная модель управления (это тоже архитектурные компоненты).
В настоящей архитектуре предприятия
Настоящая архитектура настоящего предприятия?)
А настоящее это какое?
Большой у вас будет «каталог продуктов (услуг)» и «каталог товаров» у АТП на 200 автобусов работающих по одной цене (назначенной местными властями)? Сколько квадратиков?
А в Яндексе конечно ИТ-отдел это всего один квадратик, зачем им больше?
Да, а маркетинговый отдел у ПогранСлужбы вы в каждое подразделение добавите или только в головную службу?)
Вы повторяетесь и ходите по кругу.
То что я написал это не штат, а попытка набросать «универсальную» структуру подразделений. Дальше нужны связи между ними, процессы, метрики и т.п. Но даже крупноблочно построить универсальное невозможно ибо даже то что я написал выглядит как «нарисовать сову (четвертый пункт)».
Вы повторяетесь и ходите по кругу.
С этим согласен. Будут реальные ЕА в открытом доступе, — будет конкретика, сравнения, классификация и т.п. Не нужно будет «повторяться и кружиться». Но пока…
Вот Вы на орг-структуры упор делаете, а как быть на предприятии с 99% автоматизацией. Там ведь людей вообще не будет (почти), а архитектура будет (и не маленькая).
Вот Вы на орг-структуры упор делаете, а как быть на предприятии с 99% автоматизацией.
Кажется до вас начинает потихоньку доходить то что вам пытаются донести уже вторую неделю:
Но даже крупноблочно построить универсальное невозможно ибо даже то что я написал выглядит как «нарисовать сову (четвертый пункт)».
Меня «вторую неделю» (а точнее уже не один год) пытаются убедить, что: универсальных, типовых ЕА – не существует! Все ЕА исключительно индивидуальные и неповторимые!
Верно? Это пелось консалтерами изначально.
При этом:
а) нет ни одного подробного примера ЕА (король голый?) и
б) не показано примерами, чем ЕА отличается от «ИТ-архитектуры предприятия», «бизнес-архитектуры предприятия» и т.п.
По мотивам обсуждения пошел делать статью, «Мифы ЕА». Кто готов посодействовать – стучитесь в личку.
Верно? Это пелось консалтерами изначально.
При этом:
а) нет ни одного подробного примера ЕА (король голый?) и
б) не показано примерами, чем ЕА отличается от «ИТ-архитектуры предприятия», «бизнес-архитектуры предприятия» и т.п.
По мотивам обсуждения пошел делать статью, «Мифы ЕА». Кто готов посодействовать – стучитесь в личку.
… а что такое "бизнес-архитектура предприятия", и где вы взяли это понятие?
Я предполагаю что он хочет увидеть что-то вроде «типовая система менеджмента качества» (ISO:9000) которую можно форкнуть и за пару дней допилить под свои нужды.
В целом здесь простое когнитивное искажение:
1) вся эта архитектура плевое дело выдающая на выходе капитанские и неэффективные «архитектуры» (см. анекдот про консультанта и пастуха).
2) Чтобы доказать что это не так нужно показать каждому смертному готовую работу (выложить в паблик)
3) Когда они выложат в паблик (если), то я смогу быстренько это раскритиковать или перепилить под себя, ведь они же ерундой занимаются и все там будет очень просто (эффект Д-К)
Оффтоп: Вспомнилось. У меня валяется один ДСП-шный драфт замороженный на стадии после аналитики требований к одной ИС. Все умерло на стадии «урежь форель». Потрачен был олимпиард гривен на разработку проекта, но после оптимизаций перестали существовать и заказчики и исполнители (юрлица) и все руководители принимавшие решение рассеялись в неизвестном направлении. Проект на баланс правопреемника не переносили, да и правопреемник уже тоже ликвидирован. Так что вся оригинальная документация (не копии, копии у меня и так были) по дороге в бумагосжигающую машину была мною честно «прихватизирована». Так вот — скоро буду переезжать в другую страну. Проект этот иногда листаю, кое-что лично для меня актуально и сейчас. Документации там натурально 5 кг бумаги, а у нас и так по три сумки дополнительных. Жена ворчит что меня с вот этим вот в самолет не пустит, мол иди сканируй. Сканер то есть под рукой, но блин, мне лень. Мне лень сканировать для себя, я лучше буду тут ее листать когда буду прилетать в гости к родственникам. Не говорю уже про ДСП и т.п. И нет, в электронном виде не проще. Я как-то переделывал один сорокастраничный документ который сам же готовил, чтобы убрать всю конкретику, чтобы у себя в офисе, в распечатанном виде показывать сотрудникам, мол «делай точно такое же, только с перламутровыми пуговицами» — полдня убил. А это было всего сорок страниц.
В целом здесь простое когнитивное искажение:
1) вся эта архитектура плевое дело выдающая на выходе капитанские и неэффективные «архитектуры» (см. анекдот про консультанта и пастуха).
2) Чтобы доказать что это не так нужно показать каждому смертному готовую работу (выложить в паблик)
3) Когда они выложат в паблик (если), то я смогу быстренько это раскритиковать или перепилить под себя, ведь они же ерундой занимаются и все там будет очень просто (эффект Д-К)
Оффтоп: Вспомнилось. У меня валяется один ДСП-шный драфт замороженный на стадии после аналитики требований к одной ИС. Все умерло на стадии «урежь форель». Потрачен был олимпиард гривен на разработку проекта, но после оптимизаций перестали существовать и заказчики и исполнители (юрлица) и все руководители принимавшие решение рассеялись в неизвестном направлении. Проект на баланс правопреемника не переносили, да и правопреемник уже тоже ликвидирован. Так что вся оригинальная документация (не копии, копии у меня и так были) по дороге в бумагосжигающую машину была мною честно «прихватизирована». Так вот — скоро буду переезжать в другую страну. Проект этот иногда листаю, кое-что лично для меня актуально и сейчас. Документации там натурально 5 кг бумаги, а у нас и так по три сумки дополнительных. Жена ворчит что меня с вот этим вот в самолет не пустит, мол иди сканируй. Сканер то есть под рукой, но блин, мне лень. Мне лень сканировать для себя, я лучше буду тут ее листать когда буду прилетать в гости к родственникам. Не говорю уже про ДСП и т.п. И нет, в электронном виде не проще. Я как-то переделывал один сорокастраничный документ который сам же готовил, чтобы убрать всю конкретику, чтобы у себя в офисе, в распечатанном виде показывать сотрудникам, мол «делай точно такое же, только с перламутровыми пуговицами» — полдня убил. А это было всего сорок страниц.
раскритиковать
Вот именно! Только в споре рождается истина, но спор должен быть предметным, за отсутствием «фактуры» — наш с вами спор неэффективен.
Откуда такая уверенность, что в этих 5 кг действительно что-то ценное? Какие показатели?
Показатель – «по весу»? Макулатура точно также измеряется «весом».
Я встречал документацию на ОДНО изделие, которую перевозили целым грузовиком.
Показатель – «потрачено на макулатуру очень много денег»? Ха-Ха. Показали бы консалтеры на хабре свои проекты ЕА и сказали бы, сколько эти описания ЕА стоили заказчику: смеялись бы все, кроме консалтеров и заказчиков.
Только поэтому они «ДСП» и NDA.
Сам проект по ЕА и его стоимость – это огромная тайна, прежде всего, потому, что когда эти «труды» опубликуются, то всем сразу станет очевидно, что ЕА — это алхимия, и «король то голый».
Образуется «неловкая пуаза» — а зачем столько денег было «на это» затрачено? Хотелось бы ошибиться.
Так что, у обладателей ЕА есть шанс сделать шаг в этом направлении, опубликовав «хоть что-то» из «подобных 5 кг».
А говорю, что современные подходы к ЕА – пока алхимия, но ведь химия тоже начиналась с нее.
Но, видимо, я снова повторился.
Лучше обсудим это в моей будущей статье, как вариант под названием: «Алхимия предприятия».
Там пропишу, что то типа: Почему компании, так красиво описывающие ЕА по заказу, не могут опубликовать свою ЕА?
Или у компаний консалтеров нет ЕА? Каким NDA они тогда будут оправдываться?
Нужно ввести правило: хочешь описывать ЕА других, — опубликуй свою!
Это хоть что-то скажет как о самом предмете исследования (описание ЕА), так и компетенциях консалтера в этом предмете.
Т.е. описание ЕА стороннего предприятия – нужно лицензировать. Без лицензии можно делать описание ЕА только своего предприятия.
Кстати, кто по вашему пользователь ЕА? Кто должен уже имеющееся описание ЕА использовать в своей работе? Директор предприятия? Или кто?
потому, что когда эти «труды» опубликуются, то всем сразу станет очевидно, что ЕА — это алхимия
На основании чего вы делаете такие утверждения?
Почему компании, так красиво описывающие ЕА по заказу, не могут опубликовать свою ЕА?
Потому что это коммерческая тайна.
Нужно ввести правило: хочешь описывать ЕА других, — опубликуй свою!
Кому нужно?
Без лицензии можно делать описание ЕА только своего предприятия.
А что такое "свое предприятие"? Когда enterprise architect работает на предприятии по контракту, это его предприятие?
Потому что это коммерческая тайна.
Ну он все время говорит о каких-то «консультантах», и потом их же и критикует. В целом если бы я заказывал руководство по управлению качеством, штатное расписание, оргструктуру, ЕА, бизнес-план и прочие общеорганизационные документы то для меня было бы заметным плюсом посмотреть аналогичный документ самого предприятия, если бы я был подобным консультантом и масштаб бы позволял, то я бы не стеснялся такое публиковать, может без некоторых подробностей, но конкуренты и так все знают (если достойные конкуренты) а клиент форкнуть не сможет. Ну или если и будеть «хоть как-то» форкать то все равно бы он не заказал ничего, так что пусть хоть на имидж работает…
Впрочем я поддерживаю идею «покажи свое» не столько как пример качества работы сколько как подсказка клиенту зачем оно ему надо и надо ли оно ему в принципе. Многие не совсем понимают чего они хотят и хотят ли вообще, а тут пример :)
Я, кстати, сильно подозреваю, что когда люди приходят продавать свои услуги, они-таки показывают примеры. Просто не на паблик.
Впрочем я поддерживаю идею «покажи свое»
Отлично! Хоть в чем то наши взгляды совпали «Нужно публиковать!» и тем самым бороться с мифами. Только вряд ли кто-то из консалтеров тем самым «будет рубить сук, на котором сидит».
Ну он все время говорит о каких-то «консультантах», и потом их же и критикует.
Около стада овец приземляется вертолет. Из вертолета выходит человек в костюме от Kiton и предлагает пастуху сделку: …
Но это очень лестная притча про консультантов ЕА, в рус-реальности и применительно к ЕА все значительно печальнее: будут использованы не спутники НАСА, а лишь мантры ТОГАФА и т.п., т.е. вместо high tech в притчи, в обычном ЕА проекте будут упражнения магии и алхимии.
Кстати, мы точно не путаем под описанием ЕА рабочую документацию? Это то, что в советских гостах называлось «рабочая документация» на изделие («изделие» может быть болт, автомобиль, АСУ, предприятие, государство). Или под описанием ЕА – «технический проект»?
Почти один в один подход в конструировании применяется и в строительстве. Вот «рабочая документация» на систему — это самое что ни на есть детальное описание (детальнее некуда).
Остался без ответа: Кстати, кто по вашему пользователь ЕА?
Почти один в один подход в конструировании применяется и в строительстве.
С этого места, пожалуйста, поконкретнее. Что именно применяется в конструировании, что — в строительстве, и что из этого называется "архитектура"?
Всем Привет,
В статье по ссылке все подробности, также
приглашаю к участию в конкурсе «household architecture»
habrahabr.ru/post/345424
Enterprise Architecture vs алхимия предприятия. Ключевые мифы
В статье по ссылке все подробности, также
приглашаю к участию в конкурсе «household architecture»
habrahabr.ru/post/345424
Enterprise Architecture vs алхимия предприятия. Ключевые мифы
Что характерно, ответа на (простой) заданный вопрос там нет.
удалено
то такое «бизнес-архитектура предприятия»
Я взял? Вы издеваетесь? Наберите в гугл и увидите, что точно такая же «раскрученная алхимия», как и просто ЕА.
UFO just landed and posted this here
«х86» – чаще все же называют архитектурой. Я не против микроархитектур и в ЕА. Будут мега-архитектуры, а в них подвиды. Проблем не вижу.
Главное, чтобы это походило под термин «архитектура» (стиль, микроархитектура), применяемый как в зодчестве, так и в микроэлектроники, а еще в массе других отраслей.
Главное, чтобы это походило под термин «архитектура» (стиль, микроархитектура), применяемый как в зодчестве, так и в микроэлектроники, а еще в массе других отраслей.
По вашему примеру поликлиники не подходят :)
Скорее уж ЕА Роснефть, РЖД, Газпром… И да, ЕА у них разные. И разрабатывать каждую из них (и согласовывать) — весьма трудоемкая задача, не смотря на все существующие примеры и best practice.
Итоговые материалы очень объемны (это сотни страниц, не считая всяких презентаций) и все они — IP соответствующих компаний, поэтому в открытом доступе их нет.
Тот пример, что вы привели — скорее задача на разработку типовой ЕА для конкретных видов госучреждений или предприятий (типа школ, поликлиник и подобного). Даже не знаю, делал ли кто такую работу.
Скорее уж ЕА Роснефть, РЖД, Газпром… И да, ЕА у них разные. И разрабатывать каждую из них (и согласовывать) — весьма трудоемкая задача, не смотря на все существующие примеры и best practice.
Итоговые материалы очень объемны (это сотни страниц, не считая всяких презентаций) и все они — IP соответствующих компаний, поэтому в открытом доступе их нет.
Тот пример, что вы привели — скорее задача на разработку типовой ЕА для конкретных видов госучреждений или предприятий (типа школ, поликлиник и подобного). Даже не знаю, делал ли кто такую работу.
как можно вообще говорить об ЕА, если вообще нет примеров ЕА в открытом доступеа почему нет? Далеко не все в мире есть в открытом доступе. К примеру, тех же детальных моделей процессов.
А надо было просто выставлять контракт на разработку унифицированной архитектуры для госкомпаний определенного типа, и было бы все как вам хочется.
(только потом каждая госкомпания будет плакать, натягивая эту архитектуру на свою жизнь, но кого ж это волнует?)
будет плакать, натягивая эту архитектуру на свою жизнь
Было бы что «натягивать». Я уже сомневаюсь, что ЕА вообще есть в природе (видимо только в воображении).
Попытки «Посмотреть на конкретный пример ЕА» все как один (два): или «купи проект по ЕА» или (самый дешевый) «пройдите наш платный курс, мы вам ТАМ покажем (и то «по секрету»)».
На улице ко мне также подходят, «кастрюльки впаривать» и рассказывают примерно также грамотно (фактически готовые ЕА — консультанты) и такие же истории, как и с ЕА: «смотри — блестит, это очень круто, купи только» плюс «у вас же специфика! Вам подойдет только эксклюзив»
Не хотел никого обидеть, но «с моей кочки зрения» выглядит именно так.
А касательно навыков алгоритмизации о которых шла речь, какой уровень вы подразумевается? Ну т.е. явно ведь не список разворачивать, а что-то абстрактнее и обобщение)
UFO just landed and posted this here
Странно, что таких системных архитекторов не учат на курсах МВА.
Пора бы заняться.
Пора бы заняться.
Чем отличается системный аналитик
от системного архитектора?
Это тот, кто обоснованно и в письменном виде материт предыдущего системного архитектора.
У нас системный аналитик анализирует входящие ТЗ от заказчика и переводит их в вид, понятный для профильных функциональных подразделений, обозначает риски при реализации. Архитектор фактически еще и сам реализует техническую составляющую — выставляет верхнеуровневые задачи на реализацию на эти самые подразделения. Разница хорошо заметна на конвейере задач. Аналитик в день анализирует 2-3 ТЗ, архитектор реализует проект от 3-х месяцев до года.
1
целей, ФТ, HLD
Это все хрень и тренды вида HLD, а дальше по подразделениям.
Последние 3-5 лет пошла тенденция — все инженеры, которым наскучило на месте и решили соскочить, повышают в архитекторы лишь бы не разбежались. По сути это что и был главный ИНЖЕНЕР проекта, так он и остался, назови его хоть инженером, ведущим инженером, старшим инженером или новомодным архитектором. Посмотрите статистику сколько сейчас на рынке архитекторов. Каждый третий-четвертый.
UFO just landed and posted this here
Удобна профессия и никакой ответственности.
Еще технический эксперт по готовому ТЗ 2х летней давности возьмет все и сделает и пофиг что там кому нужно и как…
А потом системный интегратор запустит ночных инженеров чтобы те исправили ошибки предыдущих. И так по кругу… а люди будут стоять в живой очереди потому что в автомат выдачи талонов сломался, а обслуживать его некому так как инженеры спят, а системные артефакторы на это не способны.
Еще технический эксперт по готовому ТЗ 2х летней давности возьмет все и сделает и пофиг что там кому нужно и как…
А потом системный интегратор запустит ночных инженеров чтобы те исправили ошибки предыдущих. И так по кругу… а люди будут стоять в живой очереди потому что в автомат выдачи талонов сломался, а обслуживать его некому так как инженеры спят, а системные артефакторы на это не способны.
Свет в этой профессии/должности временами действительно есть, и очень даже яркий бывает — это когда новый архитектор сжигает всё что сделал предыдущий :)
Посоветуйте навскидку парочку книг по сабжу. Спасибо!
Из книжек последнее, что стоит прочитать — «Mastering Non-Functional Requirements» (правда, как говорит Александр, в той версии, что он читал, редактор проспал зарплату, и было грустно:)). Также рекомендуем курсы Coursera: «Making Architecture», IEBusiness School; «Planning, Auditing and Maintaining Enterprise Systems», Colorado University.
Гм… Странно, что никто ни слова не сказал о документации.
ИМХО, первый шаг на пути к архитектору — осознание того, что документация первична.
Второй шаг — это когда приходит осознание, что в основе всего лежит технология, а не решение конкретного вендора.
…
А на пике возможностей архитектор становится ещё и оракулом и видит как система будет развиваться в будущем, понимает как она будет масштабироваться в любую сторону и делает это не потому, что это написали или не написали в ТЗ, а просто потому, что не может осознанно сделать плохо. А потому даже из г… на и палок может сделать конфетку.
ИМХО, первый шаг на пути к архитектору — осознание того, что документация первична.
Второй шаг — это когда приходит осознание, что в основе всего лежит технология, а не решение конкретного вендора.
…
А на пике возможностей архитектор становится ещё и оракулом и видит как система будет развиваться в будущем, понимает как она будет масштабироваться в любую сторону и делает это не потому, что это написали или не написали в ТЗ, а просто потому, что не может осознанно сделать плохо. А потому даже из г… на и палок может сделать конфетку.
«Мы только что сдали проект после пары недель ночных переработок, чтобы уложиться в дедлайн.» Надеюсь премии хватило на отдых на бали)))
Вообще, людям, которые так себя не уважают, что бы перерабатывать по 20 часов ночами, нельзя идти в архитекторы и проект менеджеры. При таком отношении к делу они и себе и всей команде устроят «сладкую» жизнь.
Вообще, людям, которые так себя не уважают, что бы перерабатывать по 20 часов ночами, нельзя идти в архитекторы и проект менеджеры. При таком отношении к делу они и себе и всей команде устроят «сладкую» жизнь.
Раз примеров «просто архитектуры предприятия» нет, то где посмотреть конкретный пример «системной архитектуры предприятия». Если есть «системные архитекторы», то вроде и такая архитектура должна быть.
Как она связана с другими элементами ЕА?
Системное проектирование (Systems Engineering) и «Системная архитектура» как соотносятся?
Как она связана с другими элементами ЕА?
Системное проектирование (Systems Engineering) и «Системная архитектура» как соотносятся?
В общем, архитектор — это тот, кто принимает главные решения на проекте.А зачем тогда руководитель проекта?
Есть 3 вида/уровня архитекторов:
Enterprise (EA)
Solution (SA)
Infrastructure (IA)
Отсюда и 3 уровня самой Архитектуры.
Сейчас чаще используется классификация именно Enterprise и Solution, а не Системная
Enterprise (EA)
Solution (SA)
Infrastructure (IA)
Отсюда и 3 уровня самой Архитектуры.
Сейчас чаще используется классификация именно Enterprise и Solution, а не Системная
Тут больше исходя из потребностей конкретной организации деление происходит. Если абстрагироваться от метамодели архитектуры предприятия стандарта TOGAF (в каждом из уровней которой живет по виду архитектора), то вот например: 
Можно заменить на «директор»: получится «ИТ-директор» (CIO), «Технический директор» (СТО) и т.д. В чем тогда разница? Типа один руководит (директор), а другой работает (архитектор)?
А если схему продолжить вниз, то появятся «Архитектор по backup», «Архитектор по картриджам» и т.д.?
А если схему продолжить вниз, то появятся «Архитектор по backup», «Архитектор по картриджам» и т.д.?
Если посмотреть в перспективе, то можно наверное описать все это следующим образом:
для крупных организаций решивших управлять и развивать корпоративную архитектуру — есть EA архитекторы работающие в целом: корпоративный архитектор, бизнес архитектор и т.д.
на уровне проекта работает архитектор решений — он реализует конкретное бизнес решение которому посвящен проект (декомпозирует процесс по системам, возможно вводит новые функциональные компоненты и модули и т.д.), и на основе его дизайна уже происходит декомпозиция работ, которую уже в дальнейшем трэчит руководитель проекта
на уровне системной архитектуры — живут уже остальные архитекторы из картинки выше, являясь специалистами в конкретной системе, предметной области (облачные решения, big data etc) и т.д.
для крупных организаций решивших управлять и развивать корпоративную архитектуру — есть EA архитекторы работающие в целом: корпоративный архитектор, бизнес архитектор и т.д.
на уровне проекта работает архитектор решений — он реализует конкретное бизнес решение которому посвящен проект (декомпозирует процесс по системам, возможно вводит новые функциональные компоненты и модули и т.д.), и на основе его дизайна уже происходит декомпозиция работ, которую уже в дальнейшем трэчит руководитель проекта
на уровне системной архитектуры — живут уже остальные архитекторы из картинки выше, являясь специалистами в конкретной системе, предметной области (облачные решения, big data etc) и т.д.
Видели мы эти картинки все. Всё реально зависит от масштабов.
зы: сам Архитектор, знаю :)
зы: сам Архитектор, знаю :)
Product Managerа на вас архитекторов-стартаперов нет )))
UFO just landed and posted this here
Передайте Саше Шубину что я пока читал из под стола — смахивал скупую мужскую слезу.
мимоархитекторвбанке
мимоархитекторвбанке
Sign up to leave a comment.
«Хочешь быть системным архитектором? Там только свет и чистота…»