Comments 62
ИТ-архитектор — это специалист, который решает, как в конечном итоге будет выглядеть информационная система организации в целом и в деталях. Основная цель ИТ-архитектора в компании заключается в том, чтобы обеспечить решение задач бизнеса при помощи информационных технологий.
Мне вот почему то всегда казалось что задача любого программиста как профессионала «Обеспечить решение задач бизнеса при помощи информационных технологий». И любой программист, если он профессионал должен быть архитектором.
Окончательно в этом я убедился, после того как посмотрел несколько выступлений Роберта («Uncle Bob») Мартина, принимая во внимание его опыт и авторитет, а так же то что IT отрасль в США опережает нашу на 10 лет.
Крайне рекомендую посмотреть его выступление «The Future of Programming», где он дает экскурс в историю и поясняет, как вообще развивалось программирование и как со временем терялась квалификация программистов, откуда взялись все эти отдельные специальности, такие как архитекторы, It-менеджеры, Agile-коучи, системные аналитики и прочие. Так же он раскрывает причины которые привели к появлению Waterfall модели и в чем истинная суть Agile. И еще много интересных моментов.
Мне вот почему то всегда казалось что задача любого программиста как профессионала «Обеспечить решение задач бизнеса при помощи информационных технологий».
Это цель (стратегия). Но конкретный программист реализующий конкретный кубик вполне может решать (тактическую) задачу "написать такой-то отчет".
И любой программист, если он профессионал должен быть архитектором.
Вы же отдаете себе отчет, что это невыполнимое требование?
Вы же отдаете себе отчет, что это невыполнимое требование?
Программисты старой гвардии почему то так не считают. И я так не думаю, хоть я и достаточно молод и начал свой путь всего лишь в начале 2000-ных. Для меня это требование всегда было выполнимым и обязательным. С самой первой своей программы которую я написал за деньги. Я был и исполнителем и архитектором и всеми вместе и решил человеку проблему. За 500 рублей. :) Но решил. От начала и до конца. От идеи и до программы.
Не выполнимо другое, написать код большой системы в одиночку. Но имея команду программистов каждый из которых понимает как решить проблему бизнеса вероятность прийти к успеху в этом деле стремится к 1, чего не скажешь о проекте в котором есть один архитектор и куча «исполнителей». Часто такие проекты в итоге терпят фиаско.
Даже в моей пока еще не длинной карьере был один такой проект. Пилили его 3 года но он так и умер не дойдя до MVP. А все потому, что проблемы бизнеса пытались понять от силы 2 программиста из команды в 20+ человек. Остальные считали что их работа — код писать.
Это цель (стратегия). Но конкретный программист реализующий конкретный кубик вполне может решать (тактическую) задачу «написать такой-то отчет»
На мой взгляд он вряд ли сможет реализовать его по человечески если не вникнет в бизнес и не поймет что это за отчет и зачем он нужен. Вплоть до каждой его составляющей.
Программисты старой гвардии почему то так не считают.
"Старая гвардия" — это какого года призыва?
С самой первой своей программы которую я написал за деньги. Я был и исполнителем и архитектором и всеми вместе и решил человеку проблему. За 500 рублей. :) Но решил. От начала и до конца. От идеи и до программы.
Как раз пока ты пишешь программу один от начала и до конца, архитектором быть легко. Сложно быть архитектором, когда ты не можешь реализовать систему от начала и до конца.
Но имея команду программистов каждый из которых понимает как решить проблему бизнеса вероятность прийти к успеху в этом деле стремится к 1
Ээээ… нет. Потому что нет никакой гарантии, что они понимают это одинаково, и поэтому можно получить в системе n несогласованных решений.
На мой взгляд он вряд ли сможет реализовать его по человечески если не вникнет в бизнес и не поймет что это за отчет и зачем он нужен. Вплоть до каждой его составляющей.
… но при этом ему совершенно не обязательно понимать все остальные отчеты (и части системы), не правда ли?
«Старая гвардия» — это какого года призыва?
70-ых годов в среднем.
Ээээ… нет. Потому что нет никакой гарантии, что они понимают это одинаково, и поэтому можно получить в системе n несогласованных решений.
Этой проблемы не было когда программисты выходили из бизнеса и из тех отраслей для которой они решали проблему. А сейчас чтобы решить эту проблему опытные люди придумали Agile (Который к слову разного рода менеджеры не имеющие отношения к IT извратили и превратили в индустрию по выкачиванию денег).
… но при этом ему совершенно не обязательно понимать все остальные отчеты (и части системы), не правда ли?
Если этот отчет, сферический конь в вакууме, не обязательно. Если этот отчет важен для бизнеса, он так или иначе отражает очень много бизнес-сущностей и бизнес процессов и да, их надо бы знать, чтобы понимать вообще как этот отчет сделать.
Как раз пока ты пишешь программу один от начала и до конца, архитектором быть легко. Сложно быть архитектором, когда ты не можешь реализовать систему от начала и до конца.
А как стать архитектором сложных систем, которые не можешь написать, если ни когда не решал архитектурные задачи для тех систем которые можно написать в одного? И не понимаешь что ты решаешь проблемы людей а не просто пишешь код?
Этой проблемы не было когда программисты выходили из бизнеса и из тех отраслей для которой они решали проблему.
Да ладно. Вы думаете, что в бизнесе разные люди не могут видеть разных способов решения одной и той же проблемы? Да легко.
Если этот отчет важен для бизнеса, он так или иначе отражает очень много бизнес-сущностей и бизнес процессов и да, их надо бы знать, чтобы понимать вообще как этот отчет сделать.
Зачем? Достаточно понимать ту конкретную задачу (плюс ее входы), которую решает этот отчет.
А как стать архитектором сложных систем, которые не можешь написать, если ни когда не решал архитектурные задачи для тех систем которые можно написать в одного?
А я где-то говорил такое? Я всего лишь говорю, что способность спроектировать маленькую систему не означает способности быть архитектором большой.
Я был и исполнителем и архитектором и всеми вместе и решил человеку проблему. За 500 рублей.
А почему Вы думаете, что в этом проекте нужен был (и был) архитектор??? Простого проектирования, в таких случаях вполне достаточно.И его действительно должен уметь производить программист, если он профессионал.
Где я сказал что там нужен был архитектор? Я вообще говорю о том что такой роли отдельной быть не должно. Понятное дело что огромные системы могут проектировать только очень опытные программисты. Но маленькие системы должны уметь проектировать даже джуны. Все он джунов до CTO должны понимать проблемы бизнеса и так или иначе уметь решать их с помощью кода.
Не буду с ходу отрицать вашу мысль. Попробую еще раз убедить.
1) приведу ассоциацию. Перефразируя Вас, можно предположить, что любой хороший строитель, должен быть архитектором. И соответственно уметь проектировать архитектуру зданий, микрорайонов, городов.
2) исходя из Вашего постулата:
3) аргумент «должен быть» очень абстрактный. По факту, ИТ сообщество, (в том числе ИТ сообщество США не исключение) на основании опыта работ в ИТ индустрии, внедрило стандарты разделяющие ИТ инженеров, на специализации. Вероятно, это вызвано огромным количеством разнообразных направлений работ в процессе производства программных продуктов, требующих очень разных навыков, умений, черт характера и т.п. В общем-то именно об этом статья. Чтобы еще убедительнее донести эту мысль, планирую написать статью «Процесс производства программных продуктов».
Я бы согласился с такой формулировкой: «Большинство программистов, если сильно захотят, могут стать архитекторами». Архитекторы и программисты выполняют разные функции в проектах. Можно ли совместить? В маленьких проектах можно.
1) приведу ассоциацию. Перефразируя Вас, можно предположить, что любой хороший строитель, должен быть архитектором. И соответственно уметь проектировать архитектуру зданий, микрорайонов, городов.
2) исходя из Вашего постулата:
любой программист, если он профессионал должен быть архитектором.следует утверждение: «Любой архитектор — должен быть программистом — профессионалом». Думаю найдется очень много ИТ архитекторов, которые на текущем отрезки свой жизни, уже давно не практикуют кодирование, а есть и те кто вовсе не занимался «высоким» кодированием.
3) аргумент «должен быть» очень абстрактный. По факту, ИТ сообщество, (в том числе ИТ сообщество США не исключение) на основании опыта работ в ИТ индустрии, внедрило стандарты разделяющие ИТ инженеров, на специализации. Вероятно, это вызвано огромным количеством разнообразных направлений работ в процессе производства программных продуктов, требующих очень разных навыков, умений, черт характера и т.п. В общем-то именно об этом статья. Чтобы еще убедительнее донести эту мысль, планирую написать статью «Процесс производства программных продуктов».
Я бы согласился с такой формулировкой: «Большинство программистов, если сильно захотят, могут стать архитекторами». Архитекторы и программисты выполняют разные функции в проектах. Можно ли совместить? В маленьких проектах можно.
Я все это вообще к тому что не по тому срезу мы делим. Т.е. не на архитекторов и кодеров надо делить а на Desktop разработчиков и Mobile разработчиков к примеру.
У программистов есть куча разных специализаций. Эти специализации как правило делят программистов по разнообразным стекам технологий. Для глубокого решения каких то конкретных проблем с использованием данных технологий. Но вот архитектура систем это тот общий базис который всех нас делает профессионалами.
А сейчас у нас в IT получается так:
Только профессиональный терапевт, глав.врач с большим опытом в хирургии и других областях понимает, как ставить диагноз, как лечить пациента и к кому его направлять. Но без него даже понять что с человеком не сможет ни кто
С другой стороны есть хирурги которые знают как резать. Но они не пытаются для начала отправить пациента на обследование и назначить анализы, они даже не знает об этом. Они готовы с ходу резать, остальное их не интересует в принципе.
Архитектура кварталов и городов это к Дизайнерам :). Давайте остановимся на зданиях. Что касается строителей, то да, любой хороший строитель должен быть архитектором в той или иной степени. Думаю вы согласитесь что он должен понимать как в целом строится здание, что оно начинается с фундамента и заканчивается крышей, что в нем есть куча разных систем. Так же любой строитель, если он хороший должен понимать, маяк он строит или колодец.
И это плохо, потому что какой же он архитектор если он понятия не имеет как потом это реализовывать? IT-менеджер, да, архитектор, нет. Если он вообще не программирует как он может создавать программные системы? Пусть идет занимается тем чем должен, решает проблемы программистов, думает над процессами, решает кадровые вопросы. Но как можно подпускать к системам человека который вообще ни строчки кода не пишет и уж тем более если он вообще ни когда его не писал и даже базовых принципов не понимает. Архитектура систем — она всегда 1 к 1 так или иначе превращается в код. Иначе это не архитектура а ни кому не нужные квадратики на которые спустя несколько месяцев разработки никто не смотрит.
И да, я не считаю вашу статью плохой. Вы описали существующее положение вещей. Я просто думаю что существующее положение и деление оно не совсем правильное.
У программистов есть куча разных специализаций. Эти специализации как правило делят программистов по разнообразным стекам технологий. Для глубокого решения каких то конкретных проблем с использованием данных технологий. Но вот архитектура систем это тот общий базис который всех нас делает профессионалами.
А сейчас у нас в IT получается так:
Только профессиональный терапевт, глав.врач с большим опытом в хирургии и других областях понимает, как ставить диагноз, как лечить пациента и к кому его направлять. Но без него даже понять что с человеком не сможет ни кто
С другой стороны есть хирурги которые знают как резать. Но они не пытаются для начала отправить пациента на обследование и назначить анализы, они даже не знает об этом. Они готовы с ходу резать, остальное их не интересует в принципе.
1) приведу ассоциацию. Перефразируя Вас, можно предположить, что любой хороший строитель, должен быть архитектором. И соответственно уметь проектировать архитектуру зданий, микрорайонов, городов.
Архитектура кварталов и городов это к Дизайнерам :). Давайте остановимся на зданиях. Что касается строителей, то да, любой хороший строитель должен быть архитектором в той или иной степени. Думаю вы согласитесь что он должен понимать как в целом строится здание, что оно начинается с фундамента и заканчивается крышей, что в нем есть куча разных систем. Так же любой строитель, если он хороший должен понимать, маяк он строит или колодец.
следует утверждение: «Любой архитектор — должен быть программистом — профессионалом». Думаю найдется очень много ИТ архитекторов, которые на текущем отрезки свой жизни, уже давно не практикуют кодирование, а есть и те кто вовсе не занимался «высоким» кодированием.
И это плохо, потому что какой же он архитектор если он понятия не имеет как потом это реализовывать? IT-менеджер, да, архитектор, нет. Если он вообще не программирует как он может создавать программные системы? Пусть идет занимается тем чем должен, решает проблемы программистов, думает над процессами, решает кадровые вопросы. Но как можно подпускать к системам человека который вообще ни строчки кода не пишет и уж тем более если он вообще ни когда его не писал и даже базовых принципов не понимает. Архитектура систем — она всегда 1 к 1 так или иначе превращается в код. Иначе это не архитектура а ни кому не нужные квадратики на которые спустя несколько месяцев разработки никто не смотрит.
И да, я не считаю вашу статью плохой. Вы описали существующее положение вещей. Я просто думаю что существующее положение и деление оно не совсем правильное.
Архитектура кварталов и городов это к Дизайнерам
Архитекторы (те, которые архитектурных ансамблей) смотрят на вас с непониманием.
Что касается строителей, то да, любой хороший строитель должен быть архитектором в той или иной степени.
Но зачем?
Думаю вы согласитесь что он должен понимать как в целом строится здание, что оно начинается с фундамента и заканчивается крышей, что в нем есть куча разных систем.
Понимать — да. Суметь самостоятельно рассчитать — нет. Понимать все системы — тоже нет.
Но зачем?
Чтобы вместо маяка не построить колодец, и наоборот.
Понимать все системы — тоже нет.
А потом и имеем в итоге, что монтажники положили высоковольтные кабеля на той же кабельной трассе что и низковольтные сигнальные. Ну а че **** с этой схемой, так же ближе и быстрее. Взял одним пучком и потянул. И пофигу что помехи от выскоковольтных кабелей полностью заглушат сигналы.
Чтобы вместо маяка не построить колодец, и наоборот.
Если он будет строить по выданному ему плану, он не построит колодец вместо маяка.
Анекдот есть как раз на эту тему. Достаточно просто перевернуть план вверх ногами и получится отличный колодец с фонарем на дне.
Анекдоты — это, конечно, круто, но если люди не умеют читать чертежи, им лучше не строить по чертежам.
Перефразирую: Если люди не понимают проблемы бизнеса, им лучше не пытаться писать программы решающие проблемы этого бизнеса.
И кстати чертежи как правило отражают результат 1 к 1. Большинство современных схем архитектур нарисованных т.н. архитекторами ПО вообще не соответствуют действительности и тому коду что получается на выходе.
На эту тему кстати тоже проведено куча исследований и работы. Посмотрите например «Simon Brown — Architecture vs Code». Человек много лет посвятил себя проблемам при описании архитектур программных систем. Одна из его моделей достаточно просто позволяет описывать архитектуры таким образом чтобы они отражали и бизнес и код.
И кстати чертежи как правило отражают результат 1 к 1. Большинство современных схем архитектур нарисованных т.н. архитекторами ПО вообще не соответствуют действительности и тому коду что получается на выходе.
На эту тему кстати тоже проведено куча исследований и работы. Посмотрите например «Simon Brown — Architecture vs Code». Человек много лет посвятил себя проблемам при описании архитектур программных систем. Одна из его моделей достаточно просто позволяет описывать архитектуры таким образом чтобы они отражали и бизнес и код.
Перефразирую: Если люди не понимают проблемы бизнеса, им лучше не пытаться писать программы решающие проблемы этого бизнеса.
Ну да, с этим никто и не пытается спорить. Вот только к архитектуре это отношения не имеет.
… до тех пор пока вы не решаете с помощью IT проблемы бизнеса. А как только начнете решать, с этого момента Архитектура так или иначе будет включать в себя бизнес-сущности, бизнес-правила и бизнес-процессы, а потом все это в том или ином виде так или иначе ляжет в код.
Архитектура, несомненно, будет включать в себя бизнес-сущности. Но это не значит, что каждый, кто решает задачу бизнеса, должен уметь эту архитектуру построить и обосновать.
Мы говорим не про каждого а про IT-специалистов, про программистов которые будут эти бизнес-сущности программировать. Про обоснование вообще не понимаю, перед кем обосновать?
Мы говорим не про каждого а про IT-специалистов, про программистов которые будут эти бизнес-сущности программировать
А какая разница? Вот программируешь ты бизнес-сущность "кредитная карта", зачем тебе знание того, что в компании есть enterprise service bus, на другом конце которого сидит система управления складами?
Про обоснование вообще не понимаю, перед кем обосновать?
Перед стейкхолдерами, конечно же.
… занятно, кстати. А почему вы не считаете, что каждый строитель должен понимать те проблемы, которые решает строимое им здание?
Должен, но мне если честно не нравится сравнение рядовых программистов с рядовыми штукатурами. Это неверная аналогия в принципе. Под строителями я бы предпочел понимать всех тех кто закончил строительный вуз. Их всех там учат к слову понимать эти все проблемы в том или ином виде.
Должен,
Ну то есть человек, красящий стены в порту, должен понимать, почему высота этой стены — 15 метро, а не 8?
но мне если честно не нравится сравнение рядовых программистов с рядовыми штукатурами. Это неверная аналогия в принципе.
Почему бы? И те, и другие просто выполняют работу, которая решает задачу бизнеса. Тот же дядюшка Боб об этом пишет.
Под строителями я бы предпочел понимать всех тех кто закончил строительный вуз.
То есть программисты должны выходить из бизнеса, а строители — заканчивать строительный ВУЗ? Наблюдается неравноправие.
Ну то есть человек, красящий стены в порту, должен понимать, почему высота этой стены — 15 метро, а не 8?
Он должен понимать что водоэмульсионка которую ему вручили как то не очень подходит для покраски стены в порту и надо бы наверное взять водоотталкивающую краску. К слову до этого архитектор при этом просто нарисовал красную стену…
Почему бы? И те, и другие просто выполняют работу, которая решает задачу бизнеса. Тот же дядюшка Боб об этом пишет.
А еще он пишет что все программисты должны понимать проблемы бизнеса. И рассказывает об этом с регулярным постоянством.
То есть программисты должны выходить из бизнеса, а строители — заканчивать строительный ВУЗ? Наблюдается неравноправие.
Не должны, а выходили на истоках индустрии
Он должен понимать что водоэмульсионка которую ему вручили как то не очень подходит для покраски стены в порту и надо бы наверное взять водоотталкивающую краску.
Вы не ответили на мой вопрос.
И да, предположим, он понимает, что водоэмульсионка подходит "не очень". Что дальше?
А еще он пишет что все программисты должны понимать проблемы бизнеса.
С этим, вроде бы, никто не спорил.
Вы не ответили на мой вопрос.
Должен. Но не почему она выше или ниже, он должен понимать ее назначение. Понимая его он будет понимать почему 15 а не 8 и еще много чего другого, как то какую краску выбрать, брать ли стремянку и т.д.
И да, предположим, он понимает, что водоэмульсионка подходит «не очень». Что дальше?
Работа коту под хвост будет. Краска облезет, модуль будет иметь кривой API, программа не будет решать задачи бизнеса.
Но не почему она выше или ниже, он должен понимать ее назначение. Понимая его он будет понимать почему 15 а не 8
То есть он должен знать как минимум основы карты ветров в регионе и статистику по высоте волн? Серьезно?
Работа коту под хвост будет. Краска облезет, модуль будет иметь кривой API, программа не будет решать задачи бизнеса.
Нет, делать-то ему что?
Как не смешно, но по вашему получается: «Не того человека назвали архитектором». Давайте еще раз по порядку:
Разработчики так или примерно так и делятся. А архитекторы делятся на свои виды (в статье про это написано).
Очень фривольное трактовка навыков и знаний архитекторов — строителей. Их гораздо больше чем просто представление о… Кстати кварталами и городами занимаются не дизайнеры, а как раз архитекторы. И во главе их, как правило, например, в каждом городе стоит главный архитектор города.
Опять непонимание. Читайте требования к ИТ архитекторам ( в том числе возьмите стандарты, разработанные в США). Это в первую очередь управленец, во вторую проектировщик. Проектировщик не должен реализовывать, он должен проектировать. Строить модели, алгоритмы и прочие проектные решения. А реализуют разработчики. Архитекторы больших систем, могут не знать на начальных стадиях: ни языков на которых будут кодировать (их может быть множество в одном проекте), ни платформ, ни систем хранения, ни систем безопасности и т.п. Их, как правило, выбирают на основании начальных этапов проектирования в больших проектах.
не на архитекторов и кодеров надо делить а на Desktop разработчиков и Mobile разработчиков к примеру.
Разработчики так или примерно так и делятся. А архитекторы делятся на свои виды (в статье про это написано).
Что касается строителей, то да, любой хороший строитель должен быть архитектором в той или иной степени… он должен понимать как в целом строится здание, что оно начинается с фундамента и заканчивается крышей, что в нем есть куча разных систем
Очень фривольное трактовка навыков и знаний архитекторов — строителей. Их гораздо больше чем просто представление о… Кстати кварталами и городами занимаются не дизайнеры, а как раз архитекторы. И во главе их, как правило, например, в каждом городе стоит главный архитектор города.
какой же он архитектор если он понятия не имеет как потом это реализовывать? IT-менеджер, да, архитектор, нет.
Опять непонимание. Читайте требования к ИТ архитекторам ( в том числе возьмите стандарты, разработанные в США). Это в первую очередь управленец, во вторую проектировщик. Проектировщик не должен реализовывать, он должен проектировать. Строить модели, алгоритмы и прочие проектные решения. А реализуют разработчики. Архитекторы больших систем, могут не знать на начальных стадиях: ни языков на которых будут кодировать (их может быть множество в одном проекте), ни платформ, ни систем хранения, ни систем безопасности и т.п. Их, как правило, выбирают на основании начальных этапов проектирования в больших проектах.
Те архитекторы о которых вы говорите вымерли в США еще 20 лет назад по итогу. И ни кому эти люди не нужны, со своим знанием UML и больше ни чего. А архитектурой крупных программных систем как правило там занимаются как раз таки те умудренные опытом люди вышедшие из программистов начинавшие карьеры в 70-ых годах и так или иначе пишущие переодически код до сих пор.
Я пытаюсь сказать, что Архитектор — это ДОЛЖНОСТЬ а не СПЕЦИАЛИЗАЦИЯ. И встать на эту должность может рано или поздно любой программист, если будет развиваться. А вот не программист стать архитектором не сможет НИКОГДА.
Я пытаюсь сказать, что Архитектор — это ДОЛЖНОСТЬ а не СПЕЦИАЛИЗАЦИЯ. И встать на эту должность может рано или поздно любой программист, если будет развиваться. А вот не программист стать архитектором не сможет НИКОГДА.
Те архитекторы о которых вы говорите вымерли в США еще 20 лет назад по итогу. И ни кому эти люди не нужны, со своим знанием UML
Откуда такая информация? Это что получается UML мертв? а BPMN еще жив или его тоже в топку? А как тогда проектировать? или сразу кодить, а потом по факту разберемся?
А вот не программист стать архитектором не сможет НИКОГДА.
ИТ Архитекторов не программистов, есть огромное множество. В частности среди Бизнес Архитекторов. Одна из их основных задач — проектирование бизнес процессов. Кодирования в его функциональных обязанностях вообще нет, хотя они могут использовать языки моделирования
Архитектор — это ДОЛЖНОСТЬ а не СПЕЦИАЛИЗАЦИЯ
Вот тут Вы сильно ошибаетесь. Я бы сформулировал это так:
Архитектор — это функциональная роль в процессе производства информационных систем, для которой в этом процессе определен набор выполняемых функций (обязанностей) и определена зона ответственности.
В определенных условиях (обычно это масштабы проекта и сложность), обязанности и ответственность этой функциональной роли могут быть распределены между другими участниками команды, без выделения отдельной персоны(он) на роль Архитектора.
Это в общем справедливо. Но есть и обратная сторона, стоимость такого подхода и масштабируемость. Очевидно, найти пару десятков супер-работников (разработчики-архитекторы в ИТ, строители-архитекторы на стройке, солдаты-маршалы на войне, продавцы-ceo в бизнесе и т.д.) задача как сложная, так и в какой-то мере бессмысленная.
Но идею, что любой, кто пишет код, должен очень хорошо дружить с головой, целиком и полностью разделяю. Увы и ах, реальность — она про другое.
Но идею, что любой, кто пишет код, должен очень хорошо дружить с головой, целиком и полностью разделяю. Увы и ах, реальность — она про другое.
1. Википедия. Архитектура программного обеспечения. [электронный ресурс] — Режим доступа: ru.wikipedia.org/wiki/Архитектура_программного_обеспечения, свободный. — Загл. с экрана.
2. Свободная энциклопедия Википедия. Архитектура системы. Режим доступа: ru.wikipedia.org/wiki/Архитектура_системы, свободный. — Загл. с экрана.
4. Рубенчик, Андрей. Моделирование архитектуры предприятия. Обзор языка ArchiMate. Корпоративный менеджмент. [электронный ресурс]. Режим доступа: www.cfin.ru/itm/standards/ArchiMate.shtml, свободный. — Загл. с экрана.
5. коллектив, Авторский. Квалификационные требования в области информационных технологий «СИСТЕМНЫЙ АРХИТЕКТОР». Режим доступа rosexpertpravo.ru/law/Index2/1/4293830/4293830557.htm, свободный. — Загл. с экрана.
Ни одна из етих ссылок со списка литературы ничено не содержыт (404 или пустая страница).
Что вы спорите?!
Архитектур всего лишь четыре
1) Однозвенная
2) Двузвенная
3) Трехзвенная
4) Микросервисная
Архитектор просто бросает четырехгранный кубик и выбирает, что взбредет в голову!
<:o)
Архитектур всего лишь четыре
1) Однозвенная
2) Двузвенная
3) Трехзвенная
4) Микросервисная
Архитектор просто бросает четырехгранный кубик и выбирает, что взбредет в голову!
<:o)
А архитектуру бизнес-процессов организации к какому из перечисленных делений можно причислить?
И как примерно выглядит четырехгранный кубик?
И как примерно выглядит четырехгранный кубик?
Не существует архитектуры бизнес процессов.
Есть просто бизнес-процессы.
Есть общие бизнес-процессы для всех предприятий, а есть уникальные для конкретного предприятия.
Шутка из русскоязычного DND.
В оригинале «кость» :-)
Есть просто бизнес-процессы.
Есть общие бизнес-процессы для всех предприятий, а есть уникальные для конкретного предприятия.
Шутка из русскоязычного DND.
В оригинале «кость» :-)
Не существует архитектуры бизнес процессов.Очень конструктивная позиция — То о чем не знаю — не существует.
Бизнес — архитектура предприятия (EBA-EnterpriseBusinessArchitecture) – это целевое построение организационной структуры предприятия, увязанное с его миссией, стратегией, бизнес — целями. В ходе построения бизнес — архитектуры определяются необходимые бизнес-процессы, информационные и материальные потоки, а также организационно-штатная структура
Бизнес-архитектура предприятия != архитектура бизнес-процессов
Бизнес процесс он либо есть, либо его нет.
Если он есть, то он работает by default.
Сложность только в его описании/моделировании.
Какая архитектура у бизнес-процесса выставления счета фактуры? :-)
Бизнес процесс он либо есть, либо его нет.
Если он есть, то он работает by default.
Сложность только в его описании/моделировании.
Какая архитектура у бизнес-процесса выставления счета фактуры? :-)
Какая архитектура у бизнес-процесса
Неточности пораждают ошибки и непонимание. Я писал об архитектуре бизнес-процессов (множественное число). То есть совокупность чего, в некой организационной среде, может складываться в разные архитектурные решения.
Встречный вопрос из той же разряда: какая архитектура из 4_ех перечисленных представляет реализацию в коде «бизнес-процесс выставления счета фактуры»?
Сложность только в его описании/моделировании.
Вот для борьбы с этой сложностью, а точнее со сложностью описания и моделирования совокупности процессов в различных моделях организации предприятия и т.д. и принято использование ИТ Архитекторов (в данном аспекте бизнес архитекторов)
Вот об этом и речь.
У бизнес-процессов нет архитектуры, есть «реализация».
С термином «архитектура предприятия» согласен.
Но по мне он спорный.
Насчет какая из четырех архитектур представляет бизнес-процесс — все.
Любая из мной перечисленных архитектур может реализовывать данный бизнес процесс.
Это все равно что спросить — в каком архитектурном стиле можно построить сарай для коров.
Ответ — в любом.
Барроко, Готика, Романский, Ампир т.д.
Зависит от личных предпочтений заказчика и архитектора. :-)
У бизнес-процессов нет архитектуры, есть «реализация».
С термином «архитектура предприятия» согласен.
Но по мне он спорный.
Насчет какая из четырех архитектур представляет бизнес-процесс — все.
Любая из мной перечисленных архитектур может реализовывать данный бизнес процесс.
Это все равно что спросить — в каком архитектурном стиле можно построить сарай для коров.
Ответ — в любом.
Барроко, Готика, Романский, Ампир т.д.
Зависит от личных предпочтений заказчика и архитектора. :-)
У бизнес-процессов нет архитектуры, есть «реализация».
читайте внимательно определения:
В ходе построения бизнес — архитектуры определяются необходимые бизнес-процессы
То есть бизнес процессы определены в соответствии с бизнес архитектурой. При этом у бизнес процессов — есть архитектура в соответствии с которой они определены? При этом у этих «необходимых бизнес-процессов» может никогда не быть реализации.
Бизнес процесс это конкретные действия.
Они уже реализованы.
Если они нигде не реализованы в живую — то их нет.
Что значит «При этом у бизнес процессов — есть архитектура в соответствии с которой они определены»
Бизнес процесс либо есть, либо нет.
Если он есть, то какую бы архитектуру бы не выбрали, он должен быть.
Т.е. бизнес-процессы не должны определять архитектуру.
Грубо говоря нам не важно в каком архитектурном стиле построен сарай.
Главное, чтобы коровам там было сухо, тепло и комфортно.
Они уже реализованы.
Если они нигде не реализованы в живую — то их нет.
Что значит «При этом у бизнес процессов — есть архитектура в соответствии с которой они определены»
Бизнес процесс либо есть, либо нет.
Если он есть, то какую бы архитектуру бы не выбрали, он должен быть.
Т.е. бизнес-процессы не должны определять архитектуру.
Грубо говоря нам не важно в каком архитектурном стиле построен сарай.
Главное, чтобы коровам там было сухо, тепло и комфортно.
Бизнес процесс это конкретные действия.
А алгоритм, это конкретные действия? А если он не реализован, его нет?
Грубо говоря нам не важно в каком архитектурном стиле построен сарай.
Главное, чтобы коровам там было сухо, тепло и комфортно
Опять вопрос вывернут наизнанку. Вопрос чтобы архитектурное решение было выбрано и спроектировано. Иначе сарай мало того что не будет сухой и теплы, он вообще скорее всего рухнет
Бизнес процесс либо есть, либо нет.
Если он есть, то какую бы архитектуру бы не выбрали, он должен быть.
Опять все вывернуто на изнанку. Бизнес процесс не просто должен быть, он должен быть реализован именно в контексте выбранной архитектуры.
У бизнес-процессов есть архитектура ;)
И запросто может быть архитектура несуществующих процессов. Точно также, как может быть архитектура несуществующих зданий или несуществующих информационных систем. ;)
И запросто может быть архитектура несуществующих процессов. Точно также, как может быть архитектура несуществующих зданий или несуществующих информационных систем. ;)
и
Врач может похоронить свою ошибку,
архитектор – разве что обсадить стены плющом.
Фрэнк Ллойд Райт.
В который раз я вижу, как путают понятия архитектор зданий и ИТ-архитектор.
Архитектор зданий выполняет архитектурное проектирование (планировочные и интерьерные решения), которое не предполагает инженерного проектирования (расчет балок и нагрузки и т.д.).
А указанный Вами афоризм «архитектор – разве что обсадить стены плющом» говорит только о том, что «плохой вид спасут декорации». Это никоим образом не относится к ИТ-архитекторам.
Грубо говоря, аналог «строительного архитектора» в ИТ это: ½ бизнес-аналитика + ½ дизайнера.
В связи с широчайшим кругом функциональных обязанностей, ИТ архитекторы делятся по специализациям. Каждая специализация охватывает конкретный круг вопросов, требующих владения определенными компетенциями, навыками и знаниями.
Нет, термин «специализации» тут не применим, в тексте статьи Вы «притянули за уши» специализацию к видам архитекторов. Задача архитектора – проектирование архитектуры в виде комплексного решения. Этот комплекс ограничивается контекстом: информационная система, предприятие, безопасность (как комплексное решение) и т.д. Соответственно есть архитекторы информационных систем, архитекторы предприятия и т.д.
Ко всему тексту статьи у меня есть замечания, но приводить их смысла нет, по тем же причинам, что и для статьи «Архитектура ИТ решений. Часть 1. Архитектура предприятия».
Архитекторы из архитектурных бюро с вами несогласны ;)
Да, непосредственно сами расчеты балок архитектор может и не делает, но точно контролирует, и точно отвечает за общий результат.
И в этом «строительный» архитектор ничем не отличается от ит-архитектора. Второй может не считает конкретные мегабайты конкретного оборудования, но тоже контролирует и тоже отвечает за общий результат.
зы
не путать с плохими архитекторами и плохими примерами. таковые присутствуют по всех отраслях.
Да, непосредственно сами расчеты балок архитектор может и не делает, но точно контролирует, и точно отвечает за общий результат.
И в этом «строительный» архитектор ничем не отличается от ит-архитектора. Второй может не считает конкретные мегабайты конкретного оборудования, но тоже контролирует и тоже отвечает за общий результат.
зы
не путать с плохими архитекторами и плохими примерами. таковые присутствуют по всех отраслях.
Ответ случайно добавил как новую цепочку комментариев.
… но точно контролирует, и точно отвечает за общий результат.
И в этом «строительный» архитектор ничем не отличается от ит-архитектора.
Контролирует он только соответствие своим представлениям, и вообще не он главный и не основной.
И дело его: экстерьер, интерьер и расчет освещенности. Вот и всё. Основная ответственность на инженере-конструкторе (обучается "Промышленному и гражданскому строительству").
А архитектор учится "Архитектурному проектированию".
Еще бываю инженеры-архитекторы (иногда так называются) (обучаются "Проектированию зданий"), но они в первую инженеры, только потом архитекторы.
Если хотите, можете сходить в свое архитектурное бюро, они Вам подтвердят. :)
Планировка еще у архитектора, но я в предыдущем комментарии сказал, а тут забыл.
Еще для понимания.
Говорить, что работа ИТ-архитектор похожа на работу Архитектор зданий, это уподобиться автору этой статьи «Основы бизнес процессов — тезисы вебинара», который без понимания технологий строительства в самом начале статьи разместил картинку, где рабочий укладывает керамические блоки на цементный раствор. Если Вы не разбираетесь в строительстве, то для Вас это, может быть, смотрится нормально. А то, кто понимает, посмотрит и скажет «нехорошее слово», которое, если смягчить, будет переводиться как «некомпетентность». Поэтому, рекомендую, если у Вас нет архитектурно-строительного образования, то не надо впутывать архитектора зданий в свои рассуждения об ИТ. Иначе, это будут похоже на анекдот «Отдай мою собаку!».
Говорить, что работа ИТ-архитектор похожа на работу Архитектор зданий, это уподобиться автору этой статьи «Основы бизнес процессов — тезисы вебинара», который без понимания технологий строительства в самом начале статьи разместил картинку, где рабочий укладывает керамические блоки на цементный раствор. Если Вы не разбираетесь в строительстве, то для Вас это, может быть, смотрится нормально. А то, кто понимает, посмотрит и скажет «нехорошее слово», которое, если смягчить, будет переводиться как «некомпетентность». Поэтому, рекомендую, если у Вас нет архитектурно-строительного образования, то не надо впутывать архитектора зданий в свои рассуждения об ИТ. Иначе, это будут похоже на анекдот «Отдай мою собаку!».
На каких специальностях учат ИТ-Архитекторов?
Получается чувак, который спроектировал Бурж-Халифа (он еще много чего другого спроектировал), просто определил экстерьер, интерьер, планировку, освещенность рассчитал, потом получил бабло и отвалил насовсем? Дальше уже без него достраивали? И если бы что-то пошло не так, то он просто сказал, «ну ребята, я просто экстерьер, интерьер нарисовал, а что там с расчетом нагрузки я хз, идите с… разбирайтесь». и это всех бы устроило?
И архитектурный надзор — термин вымышленный, и ни кем не применяемый?
Получается чувак, который спроектировал Бурж-Халифа (он еще много чего другого спроектировал), просто определил экстерьер, интерьер, планировку, освещенность рассчитал, потом получил бабло и отвалил насовсем? Дальше уже без него достраивали? И если бы что-то пошло не так, то он просто сказал, «ну ребята, я просто экстерьер, интерьер нарисовал, а что там с расчетом нагрузки я хз, идите с… разбирайтесь». и это всех бы устроило?
И архитектурный надзор — термин вымышленный, и ни кем не применяемый?
Пример ЕА покажете?
…
Заключение
Проще «пареной репы»: простейший фреймворк и простейший объект исследования – домохозяйство, следовательно, должна получиться простейшая «household architecture» (НА). Информации как по табличке Захмана, так и внутренней механики домохозяйства – море, а «практика жизни» позволяет соотнести архитектору теоретические выкладки со своим собственным опытом (присутствие в мире домохозяйства).
…
Enterprise Architecture vs алхимия предприятия. Часть 2. Проще некуда: простой фреймворк и простое предприятие
…
Заключение
Проще «пареной репы»: простейший фреймворк и простейший объект исследования – домохозяйство, следовательно, должна получиться простейшая «household architecture» (НА). Информации как по табличке Захмана, так и внутренней механики домохозяйства – море, а «практика жизни» позволяет соотнести архитектору теоретические выкладки со своим собственным опытом (присутствие в мире домохозяйства).
…
Enterprise Architecture vs алхимия предприятия. Часть 2. Проще некуда: простой фреймворк и простое предприятие
Sign up to leave a comment.
Архитектура ИТ решений. Часть 2. Архитекторы