Архитекторы из архитектурных бюро с вами несогласны ;)
Да, непосредственно сами расчеты балок архитектор может и не делает, но точно контролирует, и точно отвечает за общий результат.
И в этом «строительный» архитектор ничем не отличается от ит-архитектора. Второй может не считает конкретные мегабайты конкретного оборудования, но тоже контролирует и тоже отвечает за общий результат.
зы
не путать с плохими архитекторами и плохими примерами. таковые присутствуют по всех отраслях.
Это в общем справедливо. Но есть и обратная сторона, стоимость такого подхода и масштабируемость. Очевидно, найти пару десятков супер-работников (разработчики-архитекторы в ИТ, строители-архитекторы на стройке, солдаты-маршалы на войне, продавцы-ceo в бизнесе и т.д.) задача как сложная, так и в какой-то мере бессмысленная.
Но идею, что любой, кто пишет код, должен очень хорошо дружить с головой, целиком и полностью разделяю. Увы и ах, реальность — она про другое.
IDE — хорошо, а как запустить инспекции в безлюдном режиме (в рамках CI) и получить отчет о найденных ошибках/предупреждениях? a la standalone static code analyzer
Уважаемые читатели этой статьи.
Здесь выше уже высказались про это, дам более развернутый ответ.
Если у вас бизнес, и сайт вам нужен для развития бизнеса, то есть только одна рекомендация: любые идеи проверяйте, измеряйте эффект, единственный критерий успешности идеи, это положительный эффект. Все остальное — это гипотезы, которые могут работать, а могут и не работать, по куче причин, большей часть которых от вас непосредственно не зависит.
И не важно, всплывающее у вас окно, или розовая кнопочка. Если бы вы продавали товар сами себе, то вам нужно было бы прислушиваться к своему личному мнению. И ставить во главу угла ваши личные предпочтения.
Крайне суровые аналитики, конечно, могут писать BDD-тесты, но ввиду их относительной редкости, BDD-тесты чаще пишут разработчики/тестировщики в зависимости от особенностей команды. А BDD-тесты выступают человеко-понятными acceptance criteria с одной стороны, и машино-читаемыми интерфейсами к внутренностям тестов с другой стороны. И тогда BDD-тесты могут закрыть вопроса: А как работает сейчас (работало вчера, будет работать завтра — относительно простым человеческим языком)? И если тест упал, то как происходит декомпозиция в непосредственно реализацию набора действий?
Нуу, тут никаких хитростей. Если все артефакты со всеми связями поместить на одну схему, будет большая паутина. Соответственно несколько схем (view), каждая со своим аспектом.
Мы же уже выяснили, что нерафинированных примеров EA (публичных) нет.
Поэтому и ссылок нет.
Как выглядят пересечения layers можно посмотреть archimate examples. Да, это рафинад.
Выясняется, что даже для упрощенного объекта (общежитие) для одной цели (увеличить доходности) нужно с десяток схем (view), чтобы описать важные артефакты и их связи между собой, включая, кто, что, где, зачем, в рамках каких мероприятий меняет/меняется. Причем views рисуются не потому что кому-то нравится рисовать views, или нравится сам факт задокументированности, а рисуется ровно то, что касается зафиксированной цели — увеличения доходности.
Вы уверены, что представленные две схемы и есть полное «описание Архитектуры предприятия»? (пусть и типа общежитие)
Не уверен. Но я это и не утверждал.
Мои вопросы были наводящими.
Зачем нужна конкретно та, представленная схема?
Зачем нужно в общем описание архитектуры какого-то объекта?
Вы собственно говоря уже ответили. Для принятие решений. В общем случае.
Но принятие решений опять же не самоцель. Будет ли достаточно для нашего счастья, что решения будут как-то сами без наших усилий приниматься правильно? Или нам для счастья нужно что-то другое?
Принятие решений для чего?
Ранее уже об этом упоминал. Для изменения объекта (общежития, предприятия, домохозяйства, города, etc). Если все обобщить, для принятия решений по изменению объекта и реализации этих решений.
Почему я задал вопрос по представленной схеме.
Потому что я не увидел в схеме важного, а важное определяется из «для чего эта схема».
Ниже идет обсуждение, что это бизнес-срез. Ок. Зачем нам этот бизнес-срез?
Начало схемs верное. Есть главный stakeholder. У него есть цели, правда она на схеме в виде драйвера. Увеличить доходность — это все-таки цель. А вот почему мы хотим увеличить доходность, это драйвер. Он может быть (и чаще всего таковым и является) внешним. (небольшое уточнение — увеличить доходность, это цель stakeholder'а, у описания архитектуры цель все та же, помогать менять организацию)
От чего зависит наша доходность?
Какое текущее состояние?
Какое желаемое?
Что нужно сделать чтобы из первого перейти во второе?
Кто в этом задействован? Где нужно менять? И т.д.
Да, это несколько срезов (views). И на срезах начинают пересекаться уровни (business layer, application layer, etc)
есть только один вопрос. из увиденного неясно, для чего создавали схему.
это краеугольный камень. зачем вообще создавать описание архитектуры, в данном случае архитектуры общежития?
Изучение нового похвально.
Но подход к оценке и сравнению решений — очень недальновиден. Основная ниша Ignite — обработка и хранение данных, которые физически лежат на большом количестве узлов. Это примерно как сравнивать git и google drive. И тот и другой можно в общем случае использовать для архивирования локальных файлов и истории изменений.
Описанный здесь подходит в простых проектах в редкими изменениями.
В сложных проектах с большим количеством изменений, не могу представить альтернатив nvie.com/posts/a-successful-git-branching-model.
Соотношение простых проектов к сложным? Думаю, большинство простые. С учетом парадигм devops, Conf-as-code, Infra-as-code репозитарии плодятся как кролики. Далеко не во всех нужно применять строгие санитарные правила.
Где-то, наверно, повторюсь. Имхо, если не ссылаться на академические источники, архитектура предприятия — это модель, описывающая разные срезы (реальные или воображаемые) предприятия. И это модель служит ровно для одного — помогать тому, кто управляет предприятием, изменять его (тут немного тавтология, т.к. чуть ранее выяснили понятийную близость управления и изменения).
Соответственно архитектура предприятия сама по себе не может быть статичной или подвижной. Архитектура изменяется с той скоростью, с какой меняется само предприятие.
На этапе строительства предприятия с нуля — возможность переиспользования архитектурных шаблонов — жирный плюс. Да и «строить» с нуля, вообще жирный плюс, любой ИТ-ник подтвердит. Но сколько предприятий «в масле» в год появляется? И сколько продолжает свою деятельность с прошлого года? Что делают вторые? Наверно у них тоже происходят изменения.
В целом потребность в наглядных примерах EA подтверждаю. Слишком много побочной информации. Условно UML for dummies есть, а Archimate for dummies нет, только стандарт.
Но уверенности, что простые объекты подойдут в качестве кандидатов для препарирования под лупой EA, нет.
С непониманием, в том смысле, что архнадзор — субъект, препятствующий изменениям?
Как бы там ни было, но города меняются. Потому что люди и окружающие условия меняются. Переселяются, меняются приоритеты и вкусы. Сколько сейчас авто? Сколько их было 20 лет назад? Сколько потребляет энергии домохозяйство? Сколько потребляло 20 лет назад? Сколько отходов генерирует домохозяйство? Сколько 20 лет назад? И т.д.
Что должен делать тот, кто управляет городом? Изменять его под новые условия.
Некоторое время назад должность Главного архитектора города предполагала не только ответственность за зодчество, но и прочие аспекты (togaf view) деятельности города. Что делал архитектор города — выявление перекосов между потребностями и возможностями города, текущими и будущими, и контроль планирования и реализации мероприятий (transformation).
Вот и еще одна параллель между городом и предприятием, архитектор предприятия делает на предприятии то же, что архитектор города в городе.
Архитектура зодчества, если я ее правильно понял, применительно к архитектуре здания или города, является лишь одним из срезов (view из приснопамятного togaf'а) общей архитектура здания/города. В общем случае, управляющему/владельцу здания/города интересны не только внешний облик и строительные особенности, но и другие срезы, коммерция, культура, экология, энергия, транспорт и т.д.
Т.е. архитектура зодчества хоть и наглядный пример, но имхо однобокий.
Условно, управляющему/владельцу здания недостаточно иметь только строительные чертежи и арх.эскизы для того же арх.надзора.
Тут были попытки определиться с целью архитектуры. Мое глубокое имхо, главная цель архитектуры, чтобы было проще (дешевле, быстрее, прочие эпитеты по вкусу) изменять/изменяться. Еще вариант, чтобы было проще управлять. Но тут надо определиться, а что такое управлять. Опять же, по моему мнение, лучшее определение управления — это контролируемый переход их одного состояние в другое. Т.е. опять же про изменения.
Если это верно, тогда архитектура предприятия — чтобы проще изменять предприятие.
Архитектура города — чтобы проще изменять город.
Архитектура булочной — чтобы проще изменять булочную.
Но есть и другие аспекты. Количество артефактов и скорость изменений.
У булочной артефактов не так много, скорее всего легко поместятся в голову администратора булочной. Он же наверно и единственный ответственный за изменения в булочной.
Насущная необходимость архитектуры булочной в формализованном виде отсутствует как-бы.
Город и предприятие — артефактов существенно больше, в одной голове уже не помещаются. Вроде бы формальное описание архитектуры должны быть полезно. Но, имхо, начинает играть роль скорость изменений. Если изменения по наитию выполняются в два (и больше) раза быстрее, чем изменения с помощью формальной модели, при этом риск ошибок в обоих случаях отличается на проценты, то управление с помощью формальной модели начинает проигрывать. Если объем изменений, и их скорость снижаются, то управление с помощью формальной модели начинает выигрывать.
Это все измышления в попытке объяснить, почему формальные модели (архитектура) для городов, зданий существуют. А архитектуры предприятий, как байки, вроде где-то кто-то видел/слышал.
off
Когда-то в молодости проникся идеями большой четверки, касательно UML.
Обсудил в коллегами, как же теорию перенести на практику. Решили, а давайте начнем с простого, и потом перейдем в описанию более сложных. Вроде бы все логично. Через пару дней делюсь своими моделями с коллегами. В ответ, вместо восторженных рукоплесканий, слышу: ну это же итак очевидно. Зачем нужна модель в разных срезах, тратить время на ее создание, если итак все просто и очевидно.
И хотя за эти два дня созданные модели мне стали близки, пришлось признать, пользы от них было мало. Пришлось с ними расстаться и забыть про них.
Когда польза UML проявилась в полный рост? Через несколько лет, тогда когда сложность проектов серьезно выросла, и стала такой, что в голове уже не помещались все важные артефакты и их связи. И вот здесь ни у кого из сопричастных не возникало вопроса, а зачем UML и зачем нужна актуализация.
Имхо, тут начали скатываться с частностям. Архитектура зодчества — лишь один из срезов общей архитектуры (пусть будет города, или района). Примерно как ИТ-архитектура для предприятия. Но нам же интересен не один срез, и их некоторое количество?
Ну мы же под архитектурой предприятия подразумеваем все, что важно для предприятия, а не только ИТ. Так и с архитектурой города, подразумеваем все, что важно для города, а не отдельно зодчество, отдельно экономика.
То что города разные, и их архитектура отличается — очевидно. Вопрос не в этом.
Вопрос, почему хоть какие-то архитектуры городов существуют. И не в единичных случаях. А вот с архитектурами предприятий не задалось.
Имхо, все-таки в среднем не стагнирующее предприятие (что коммерческое, что некоммерческое) меняется существенно быстрее не стагнирующих городов, опять же в среднем. Примеры с Нокией и т.д. приводил из посыла, что внешняя среда изменилась, предприятие измениться не успело. И все, нет больше предприятия.
Возникла мысль, почему города меняеются медленнее. Город — финансовая группа. Городу не нужно меняться быстро, т.к. его риски размазаны среди кучи участников (предприятий). У предприятия риски остаются, ему нужно быстро меняться, чтобы выжить.
Да, непосредственно сами расчеты балок архитектор может и не делает, но точно контролирует, и точно отвечает за общий результат.
И в этом «строительный» архитектор ничем не отличается от ит-архитектора. Второй может не считает конкретные мегабайты конкретного оборудования, но тоже контролирует и тоже отвечает за общий результат.
зы
не путать с плохими архитекторами и плохими примерами. таковые присутствуют по всех отраслях.
Но идею, что любой, кто пишет код, должен очень хорошо дружить с головой, целиком и полностью разделяю. Увы и ах, реальность — она про другое.
Здесь выше уже высказались про это, дам более развернутый ответ.
Если у вас бизнес, и сайт вам нужен для развития бизнеса, то есть только одна рекомендация: любые идеи проверяйте, измеряйте эффект, единственный критерий успешности идеи, это положительный эффект. Все остальное — это гипотезы, которые могут работать, а могут и не работать, по куче причин, большей часть которых от вас непосредственно не зависит.
И не важно, всплывающее у вас окно, или розовая кнопочка. Если бы вы продавали товар сами себе, то вам нужно было бы прислушиваться к своему личному мнению. И ставить во главу угла ваши личные предпочтения.
эластик, игнит, монго рассчитаны на большой объем данных, размазанных по куче нод.
в приведенном решении самих данных мало, они на одной ноде, но нужно очень быстро по ним выполнять обработку.
наверно, можно было бы сравнивать с тарантул, в случае нормализации данных. но как я понял автору важна денормализация и вложенные структуры.
Мы же уже выяснили, что нерафинированных примеров EA (публичных) нет.
Поэтому и ссылок нет.
Как выглядят пересечения layers можно посмотреть archimate examples. Да, это рафинад.
Выясняется, что даже для упрощенного объекта (общежитие) для одной цели (увеличить доходности) нужно с десяток схем (view), чтобы описать важные артефакты и их связи между собой, включая, кто, что, где, зачем, в рамках каких мероприятий меняет/меняется. Причем views рисуются не потому что кому-то нравится рисовать views, или нравится сам факт задокументированности, а рисуется ровно то, что касается зафиксированной цели — увеличения доходности.
Переведенный TOGAF/Archimate не встречал.
Не уверен. Но я это и не утверждал.
Мои вопросы были наводящими.
Зачем нужна конкретно та, представленная схема?
Зачем нужно в общем описание архитектуры какого-то объекта?
Вы собственно говоря уже ответили. Для принятие решений. В общем случае.
Но принятие решений опять же не самоцель. Будет ли достаточно для нашего счастья, что решения будут как-то сами без наших усилий приниматься правильно? Или нам для счастья нужно что-то другое?
Принятие решений для чего?
Ранее уже об этом упоминал. Для изменения объекта (общежития, предприятия, домохозяйства, города, etc). Если все обобщить, для принятия решений по изменению объекта и реализации этих решений.
Почему я задал вопрос по представленной схеме.
Потому что я не увидел в схеме важного, а важное определяется из «для чего эта схема».
Ниже идет обсуждение, что это бизнес-срез. Ок. Зачем нам этот бизнес-срез?
Начало схемs верное. Есть главный stakeholder. У него есть цели, правда она на схеме в виде драйвера. Увеличить доходность — это все-таки цель. А вот почему мы хотим увеличить доходность, это драйвер. Он может быть (и чаще всего таковым и является) внешним. (небольшое уточнение — увеличить доходность, это цель stakeholder'а, у описания архитектуры цель все та же, помогать менять организацию)
От чего зависит наша доходность?
Какое текущее состояние?
Какое желаемое?
Что нужно сделать чтобы из первого перейти во второе?
Кто в этом задействован? Где нужно менять? И т.д.
Да, это несколько срезов (views). И на срезах начинают пересекаться уровни (business layer, application layer, etc)
правда…
есть только один вопрос. из увиденного неясно, для чего создавали схему.
это краеугольный камень. зачем вообще создавать описание архитектуры, в данном случае архитектуры общежития?
зы
для bipiem,
pubs.opengroup.org/architecture/archimate3-doc
Но подход к оценке и сравнению решений — очень недальновиден. Основная ниша Ignite — обработка и хранение данных, которые физически лежат на большом количестве узлов. Это примерно как сравнивать git и google drive. И тот и другой можно в общем случае использовать для архивирования локальных файлов и истории изменений.
Описанный здесь подходит в простых проектах в редкими изменениями.
В сложных проектах с большим количеством изменений, не могу представить альтернатив nvie.com/posts/a-successful-git-branching-model.
Соотношение простых проектов к сложным? Думаю, большинство простые. С учетом парадигм devops, Conf-as-code, Infra-as-code репозитарии плодятся как кролики. Далеко не во всех нужно применять строгие санитарные правила.
Соответственно архитектура предприятия сама по себе не может быть статичной или подвижной. Архитектура изменяется с той скоростью, с какой меняется само предприятие.
На этапе строительства предприятия с нуля — возможность переиспользования архитектурных шаблонов — жирный плюс. Да и «строить» с нуля, вообще жирный плюс, любой ИТ-ник подтвердит. Но сколько предприятий «в масле» в год появляется? И сколько продолжает свою деятельность с прошлого года? Что делают вторые? Наверно у них тоже происходят изменения.
В целом потребность в наглядных примерах EA подтверждаю. Слишком много побочной информации. Условно UML for dummies есть, а Archimate for dummies нет, только стандарт.
Но уверенности, что простые объекты подойдут в качестве кандидатов для препарирования под лупой EA, нет.
Как бы там ни было, но города меняются. Потому что люди и окружающие условия меняются. Переселяются, меняются приоритеты и вкусы. Сколько сейчас авто? Сколько их было 20 лет назад? Сколько потребляет энергии домохозяйство? Сколько потребляло 20 лет назад? Сколько отходов генерирует домохозяйство? Сколько 20 лет назад? И т.д.
Что должен делать тот, кто управляет городом? Изменять его под новые условия.
Некоторое время назад должность Главного архитектора города предполагала не только ответственность за зодчество, но и прочие аспекты (togaf view) деятельности города. Что делал архитектор города — выявление перекосов между потребностями и возможностями города, текущими и будущими, и контроль планирования и реализации мероприятий (transformation).
Вот и еще одна параллель между городом и предприятием, архитектор предприятия делает на предприятии то же, что архитектор города в городе.
Т.е. архитектура зодчества хоть и наглядный пример, но имхо однобокий.
Условно, управляющему/владельцу здания недостаточно иметь только строительные чертежи и арх.эскизы для того же арх.надзора.
Если это верно, тогда архитектура предприятия — чтобы проще изменять предприятие.
Архитектура города — чтобы проще изменять город.
Архитектура булочной — чтобы проще изменять булочную.
Но есть и другие аспекты. Количество артефактов и скорость изменений.
У булочной артефактов не так много, скорее всего легко поместятся в голову администратора булочной. Он же наверно и единственный ответственный за изменения в булочной.
Насущная необходимость архитектуры булочной в формализованном виде отсутствует как-бы.
Город и предприятие — артефактов существенно больше, в одной голове уже не помещаются. Вроде бы формальное описание архитектуры должны быть полезно. Но, имхо, начинает играть роль скорость изменений. Если изменения по наитию выполняются в два (и больше) раза быстрее, чем изменения с помощью формальной модели, при этом риск ошибок в обоих случаях отличается на проценты, то управление с помощью формальной модели начинает проигрывать. Если объем изменений, и их скорость снижаются, то управление с помощью формальной модели начинает выигрывать.
Это все измышления в попытке объяснить, почему формальные модели (архитектура) для городов, зданий существуют. А архитектуры предприятий, как байки, вроде где-то кто-то видел/слышал.
off
Когда-то в молодости проникся идеями большой четверки, касательно UML.
Обсудил в коллегами, как же теорию перенести на практику. Решили, а давайте начнем с простого, и потом перейдем в описанию более сложных. Вроде бы все логично. Через пару дней делюсь своими моделями с коллегами. В ответ, вместо восторженных рукоплесканий, слышу: ну это же итак очевидно. Зачем нужна модель в разных срезах, тратить время на ее создание, если итак все просто и очевидно.
И хотя за эти два дня созданные модели мне стали близки, пришлось признать, пользы от них было мало. Пришлось с ними расстаться и забыть про них.
Когда польза UML проявилась в полный рост? Через несколько лет, тогда когда сложность проектов серьезно выросла, и стала такой, что в голове уже не помещались все важные артефакты и их связи. И вот здесь ни у кого из сопричастных не возникало вопроса, а зачем UML и зачем нужна актуализация.
Наверно с архитектурой предприятия аналогично.
То что города разные, и их архитектура отличается — очевидно. Вопрос не в этом.
Вопрос, почему хоть какие-то архитектуры городов существуют. И не в единичных случаях. А вот с архитектурами предприятий не задалось.
Имхо, все-таки в среднем не стагнирующее предприятие (что коммерческое, что некоммерческое) меняется существенно быстрее не стагнирующих городов, опять же в среднем. Примеры с Нокией и т.д. приводил из посыла, что внешняя среда изменилась, предприятие измениться не успело. И все, нет больше предприятия.
Возникла мысль, почему города меняеются медленнее. Город — финансовая группа. Городу не нужно меняться быстро, т.к. его риски размазаны среди кучи участников (предприятий). У предприятия риски остаются, ему нужно быстро меняться, чтобы выжить.