Comments 31
Хорошая архитектура – та, что соответствует своему назначению, т.е. позволяет решать поставленные перед ней задачи.
Можете рассказать как вы измеряете качество архитектуры?
Андрей, спасибо за вопрос!
Измерение качества архитектуры — не самая простая тема. И редко где удается увидеть действительно удачные модели оценки эффективности управления архитектурой. Хотя встречаются компании (например, насколько я знаю, «Связной банк» можно было отнести к их числу), где вводят подобные оценки — и это дает свой эффект.
Какие это могут быть показатели? Вот пример:
• длительность реализации сервиса для конечных потребителей (time-to-market);
• стоимость внесение изменений при реализации новых требований (cost per changes);
• среднее время недоступности сервиса для конечных потребителей (average duration of service interruption);
• уровень одобрения сервиса «внутренним клиентом» (customer satisfaction per service)
Понятно, что на них влияет не только архитектура, тут может быть много факторов. Но определенная их зависимость именно от архитектурных решений и процессов прослеживается.
Измерение качества архитектуры — не самая простая тема. И редко где удается увидеть действительно удачные модели оценки эффективности управления архитектурой. Хотя встречаются компании (например, насколько я знаю, «Связной банк» можно было отнести к их числу), где вводят подобные оценки — и это дает свой эффект.
Какие это могут быть показатели? Вот пример:
• длительность реализации сервиса для конечных потребителей (time-to-market);
• стоимость внесение изменений при реализации новых требований (cost per changes);
• среднее время недоступности сервиса для конечных потребителей (average duration of service interruption);
• уровень одобрения сервиса «внутренним клиентом» (customer satisfaction per service)
Понятно, что на них влияет не только архитектура, тут может быть много факторов. Но определенная их зависимость именно от архитектурных решений и процессов прослеживается.
Вы описали потенциальные оценки потребительских качеств продукта и издержек на его разработку, которые обеспечивает архитектура. Оценочными характеристиками качества самой архитектуры, скорее, будет что-то типа зацепления, связности, достаточности, полноты, примитивности, в зависимости от выбранного метода (я скопировал термины из Википедии, но, уверен, методологий оценки существует больше).
Коллега, спасибо за дополнение!
Возможно, такие оценочные характеристики действительно в каких-то случаях представляют интерес. Но к сожалению, мне на практике не приходилось сталкиваться, чтобы кто-то пытался измерять подобные показатели. И у меня нет представления — кем и для каких целей они могут быть востребованы.
Но раз эта тема для Вас столь интересна — то была бы благодарна, если бы Вы этот вопрос раскрыли подробнее (может быть даже в отдельной публикации).
Возможно, такие оценочные характеристики действительно в каких-то случаях представляют интерес. Но к сожалению, мне на практике не приходилось сталкиваться, чтобы кто-то пытался измерять подобные показатели. И у меня нет представления — кем и для каких целей они могут быть востребованы.
Но раз эта тема для Вас столь интересна — то была бы благодарна, если бы Вы этот вопрос раскрыли подробнее (может быть даже в отдельной публикации).
Архитектор при выборе архитектуры может руководствоваться связностью для того, чтобы оценить, например, степень её масштабируемости на имеющемся оборудовании (или помочь решить, что лучше — закупить новый супер-сервер или десяток мелких попроще). Или, например, узким местом процессов в проекте может оказаться взаимодействие бизнес-аналитиков и программистов, тогда в архитектуре будет выгодно заложить конфигурируемость соответствующих модулей (т.е., заархитектурить поддержку конфигураций на уровне интерфейсов, ролевой системы, системы перезагрузки модулей и т.п., чтобы бизнес-аналитики сами регулировали бизнес-правила, минимально контактируя с ИТ-отделом) Т.е., эти все характеристики, в общем-то, и есть то, с чем работает архитектор при создании и поддержке архитектуры. А перечисленные вами он использует только при согласовании проекта с финансовым директором или коммерческим отделом, наверное. (Впрочем, финансовые характеристики, конечно, не становятся от этого менее важными.)
Коллега, спасибо за подробное пояснение! Ваша мысль понятна.
Главное тут — еще и не «переархитектурить», а то «чугунный мост» получится.
На такие аспекты внимание стоит обращать. Но речь шла об измеримых показателей. Я не встречалась, чтобы где-то пытались измерить то, что Вы указали (за исключением нагрузочного тестирования и «сайзинга» оборудования).
Главное тут — еще и не «переархитектурить», а то «чугунный мост» получится.
На такие аспекты внимание стоит обращать. Но речь шла об измеримых показателей. Я не встречалась, чтобы где-то пытались измерить то, что Вы указали (за исключением нагрузочного тестирования и «сайзинга» оборудования).
Думаю, и количественные, и качественные оценки имеют актуальность так или иначе лишь на границах соприкосновения разных ролей и зон ответственности. Т.е., вы в комментарии акцентировали внимание на ценностях архитектуры, возникающих в диалоге архитектора с финансовым директором (ответ больше для аудитории мегамозга, как мне кажется). Я попытался указать на существование ценностей архитектуры, возникающих в диалоге архитектора с программистами и другими архитекторами (тема больше для аудитории хабра, как мне кажется). В вашей статье есть всё, я «прицепился» лишь к комментарию. Приношу свои извинения за занудство, действительно, переархитектурил, можно быть и попроще.
Такой вышколенный текст — Вам бы редактором журнала работать =)
Ясно чувствуется, что статью долго и очень усердно воплощали, временами, я бы сказал, дотошно, поэтому и добавить-то особенно нечего.
Но будьте осторожны с этим впредь, ведь как вы и упомянули, программистов пугает такая дотошность руководства, когда не остаётся места для творческого самовыражения…
А как раз-таки именно творческий подход, на мой взгляд, порой подсказывает в программировании самые неожиданные архитектурные решения, до которых заранее, ну, никак не дойдёшь, только в самом процессе и итеративно.
Спасибо за труд и литературность материала!
Ясно чувствуется, что статью долго и очень усердно воплощали, временами, я бы сказал, дотошно, поэтому и добавить-то особенно нечего.
Но будьте осторожны с этим впредь, ведь как вы и упомянули, программистов пугает такая дотошность руководства, когда не остаётся места для творческого самовыражения…
А как раз-таки именно творческий подход, на мой взгляд, порой подсказывает в программировании самые неожиданные архитектурные решения, до которых заранее, ну, никак не дойдёшь, только в самом процессе и итеративно.
Спасибо за труд и литературность материала!
Коллега, большое спасибо за такую оценку моего труда!
Действительно, хотелось сделать это хорошо и добротно. И как мне кажется, это получилось.
Я очень благодарна своим друзьям и коллегам, которые мне очень помогли — словом, советом, вдохновением, а также добровольным участием в качестве редакторов! Без них эта публикация не состоялась бы.
Вы абсолютно правы в том, что необходимо оставлять свободу для творческого самовыражения всем специалистам, работающим над проектом! И очень правильно подметили, что не все решения видны сразу — на этапе первичной проработки архитектуры. Какие-то нюансы, какие-то важные вещи выявляются лишь тогда, когда начинается непосредственная реализация — и надо что-то пересматривать «в процессе». Т.е. архитектура должна быть «живой».
Разные бывают ситуации. Иногда приходится проявлять жесткость. Но я не сторонник такого подхода — продавливания решений. Я стараюсь убедить человека и выслушать его аргументы, чтобы не пропустить рациональное зерно.
Мне очень нравится работать с опытными разработчиками, с которыми как правило, мы «на одной волне» — когда понимаем друг друга с полуслова. И когда человек не просто использует клише, к которым привык, а когда он открыт к новым решениям — воспринимает их и предлагает свои. Конечно, есть момент «притирки». И часто человек видит картину с какой-то одной стороны. Тогда мне важно не сколько предложить готовые ответы — сколько задать «правильные вопросы» («а что будет, если»).
Действительно, хотелось сделать это хорошо и добротно. И как мне кажется, это получилось.
Я очень благодарна своим друзьям и коллегам, которые мне очень помогли — словом, советом, вдохновением, а также добровольным участием в качестве редакторов! Без них эта публикация не состоялась бы.
Вы абсолютно правы в том, что необходимо оставлять свободу для творческого самовыражения всем специалистам, работающим над проектом! И очень правильно подметили, что не все решения видны сразу — на этапе первичной проработки архитектуры. Какие-то нюансы, какие-то важные вещи выявляются лишь тогда, когда начинается непосредственная реализация — и надо что-то пересматривать «в процессе». Т.е. архитектура должна быть «живой».
Разные бывают ситуации. Иногда приходится проявлять жесткость. Но я не сторонник такого подхода — продавливания решений. Я стараюсь убедить человека и выслушать его аргументы, чтобы не пропустить рациональное зерно.
Мне очень нравится работать с опытными разработчиками, с которыми как правило, мы «на одной волне» — когда понимаем друг друга с полуслова. И когда человек не просто использует клише, к которым привык, а когда он открыт к новым решениям — воспринимает их и предлагает свои. Конечно, есть момент «притирки». И часто человек видит картину с какой-то одной стороны. Тогда мне важно не сколько предложить готовые ответы — сколько задать «правильные вопросы» («а что будет, если»).
Правильно, что Архитектор ИТ должен уметь хорошо рисовать (где-то была даже книжечка по базовым основам бизнес-рисунка, скетчинг)
Есть одна из методик «Value Realization Framework», работает в случаях, когда есть доступ к телу самого BigBossa: Ему задаются наводящие вопросы, но главное, что беседа проходит возле флипчарта, и каждый раз BigBoss-у вкладывается в руку фломастер — «рисуй!». Чем больше он будет рисовать — тем больше будет сам расскрывать и понимать и творить и решать (а кто, кроме него знает лучше: куда организация должна двигаться") — в самом лучшем случае, после 40 минут задавания наводящих вопросов и многих рисунков от директора, чем меньше будешь говорить ты, и чем больше монолога будет от него, то в результате услышишь лестное: «вот настоящий специалист, который понимает в моем бизнесе!» (хотя большей частью, ты только поддакивал и кивал головой, но soft-skill — слушать с заинтересованностью! — дверца и откроется :-) )
Есть одна из методик «Value Realization Framework», работает в случаях, когда есть доступ к телу самого BigBossa: Ему задаются наводящие вопросы, но главное, что беседа проходит возле флипчарта, и каждый раз BigBoss-у вкладывается в руку фломастер — «рисуй!». Чем больше он будет рисовать — тем больше будет сам расскрывать и понимать и творить и решать (а кто, кроме него знает лучше: куда организация должна двигаться") — в самом лучшем случае, после 40 минут задавания наводящих вопросов и многих рисунков от директора, чем меньше будешь говорить ты, и чем больше монолога будет от него, то в результате услышишь лестное: «вот настоящий специалист, который понимает в моем бизнесе!» (хотя большей частью, ты только поддакивал и кивал головой, но soft-skill — слушать с заинтересованностью! — дверца и откроется :-) )
Большое спасибо! Очень ценный комментарий!
Согласна, что «активное слушание» — очень правильный и работающий подход. Вы очень образно это описали :)
Часто бывает так — начинаешь говорить сам — и как бы не оставляешь «пространства» для собеседника. Когда начинаешь больше слушать — ситуация кардинально меняется.
Согласна, что «активное слушание» — очень правильный и работающий подход. Вы очень образно это описали :)
Часто бывает так — начинаешь говорить сам — и как бы не оставляешь «пространства» для собеседника. Когда начинаешь больше слушать — ситуация кардинально меняется.
Ведь если подумать… СЕО — должен «видеть» куда бежит бизнес компании…
а СІО (Архитектор) — должен дать инструментально-аппаратную поддержку этого видения.
Т.о. «Директор» — выступает «бизнес-архитектором компании»… например, тот же самый, «планируемый бюджет» — это тоже «видение будущего состояния»… и если для выполнения бюджета потребуется утроить количество подписчиков, то задачей ИТ будет «Обеспечить» business continuity роста числа подписчиков.
в любом случае, и один и второй должны сначала дозреть до понимания необходимости «иметь бизнесс-видение» и «иметь Архитектуру».
а СІО (Архитектор) — должен дать инструментально-аппаратную поддержку этого видения.
Т.о. «Директор» — выступает «бизнес-архитектором компании»… например, тот же самый, «планируемый бюджет» — это тоже «видение будущего состояния»… и если для выполнения бюджета потребуется утроить количество подписчиков, то задачей ИТ будет «Обеспечить» business continuity роста числа подписчиков.
в любом случае, и один и второй должны сначала дозреть до понимания необходимости «иметь бизнесс-видение» и «иметь Архитектуру».
Не текст, а бальзам на душу. Воображение рисует ровные ряды полков, одновременно выступающих в поход, отблески восхода на медных шлемах, мудрых полководцев, склонившихся над подробной картой местности…
На практике же обычно встречается банда конкистадоров, которые думают, что приплыли в Индию, объявили официальной целью крещение туземцев, на самом деле хотят найти Эльдорадо, в какой стороне оно находится непонятно, с переводчиками проблема, вокруг непривычные тропики, но проявив смекалку и отвагу, всё-таки удаётся пограбить индейцев. В такой истории становятся востребованы совсем другие инструменты планирования, лидерские качества, тактика действий.
Но, всё-таки, здорово, когда кто-то пытается воплощать мечту. И мексиканское государство в итоге создали.
На практике же обычно встречается банда конкистадоров, которые думают, что приплыли в Индию, объявили официальной целью крещение туземцев, на самом деле хотят найти Эльдорадо, в какой стороне оно находится непонятно, с переводчиками проблема, вокруг непривычные тропики, но проявив смекалку и отвагу, всё-таки удаётся пограбить индейцев. В такой истории становятся востребованы совсем другие инструменты планирования, лидерские качества, тактика действий.
Но, всё-таки, здорово, когда кто-то пытается воплощать мечту. И мексиканское государство в итоге создали.
Отличная метафора, в духе трактата «Искусство Войны» Сунь-Цзы, который и в современности широко используется и для военного дела, и для концептуализации бизнес-планирования.
Саша, какой образный комментарий! Спасибо тебе! :)
Наш с тобой «военный совет» состоится в пятницу в переговорке №2. Вот там мы обсудим и стратегию, и тактику.
Думаю также, что лидерские качества нам пригодятся самые разные.
(Кстати, про «типы руководителей» хорошо написано у Адизеса)
А на наши с тобой мечты стоит посмотреть попристальнее — возможно, в них есть что-то общее ;) И будет здорово вместе и воплощать.
Наш с тобой «военный совет» состоится в пятницу в переговорке №2. Вот там мы обсудим и стратегию, и тактику.
Думаю также, что лидерские качества нам пригодятся самые разные.
(Кстати, про «типы руководителей» хорошо написано у Адизеса)
А на наши с тобой мечты стоит посмотреть попристальнее — возможно, в них есть что-то общее ;) И будет здорово вместе и воплощать.
Яростно плюсую! Реальная жизнь зачастую настолько далека от красивых картинок, что оторопь берет. Про смешные ситуации, когда при раскопках вместо 5 интерфейсов находится 15 можно и не говорить даже
Прочел две части текста и попытался для себя ответить на вопрос: о чем эти записки?
О том, как разрабатывается архитектура? О роли архитектора в этом процессе? О том, какие должны быть спецификации?
И если я пробую найти ответ уже на конкретный вопрос, то в статье вижу только общий набор клише. Либо, просто поднимается перечень вопросов, которые так же оставляются в статье без ответа.
Не знаю, выше видел много восторженных отзывов, но для меня это было, увы, потраченное время. Может быть есть что то, что я упустил?
Со своей стороны могу предложить в следующей статье, например, разобрать любую главу из Руководство Microsoft по проектированию архитектуры приложений.
Или, например, защитить концепцию, что Архитектор — это больше менеджер чем инженер.
О том, как разрабатывается архитектура? О роли архитектора в этом процессе? О том, какие должны быть спецификации?
И если я пробую найти ответ уже на конкретный вопрос, то в статье вижу только общий набор клише. Либо, просто поднимается перечень вопросов, которые так же оставляются в статье без ответа.
Не знаю, выше видел много восторженных отзывов, но для меня это было, увы, потраченное время. Может быть есть что то, что я упустил?
Со своей стороны могу предложить в следующей статье, например, разобрать любую главу из Руководство Microsoft по проектированию архитектуры приложений.
Или, например, защитить концепцию, что Архитектор — это больше менеджер чем инженер.
Приветствую Вас. Константин!
Мне жаль, что Вы не смогли найти ответы на свои какие-то внутренние вопросы в этой статье.
Но я никоим образом не претендую «на всезнайку». Я лишь писала о том, что мне интересно, через что пришлось пройти. И это порой был не самый простой опыт.
Видимо, для Вас эта тема является довольно животрепещущей — раз Вы потратили время на ее прочтение и теперь проявляете явное участие к ней!
Да, я не ставила такой задачи в короткой статье подробно осветить столь обширные вопросы и написать руководство к действию.
Хотела бы заметить, что последнее время прихожу к выводу, что правильно поставленный вопрос важнее досконального ответа на него. Именно так работают, например, коучеры. В т.ч. вопросы, на которые нет однозначного ответа. Видимо, это нас и цепляет. Известно, что «серебряной пули» не существует.
Спасибо за наводку на книгу (ссылка, что вы дали не работает, но мне документ удалось раздобыть — фундаментальный труд на 500 стр.).
И спасибо за идеи насчет продолжения. Правда, главы из данной книги я брать не стану — у меня есть своя тема.
Но «разбор главы из книги» — отличная идея для Вашей собственной публикации! Учитывая Ваш интерес и «заряженность» — думаю, она будет иметь успех! Удачи Вам!
Мне жаль, что Вы не смогли найти ответы на свои какие-то внутренние вопросы в этой статье.
Но я никоим образом не претендую «на всезнайку». Я лишь писала о том, что мне интересно, через что пришлось пройти. И это порой был не самый простой опыт.
Видимо, для Вас эта тема является довольно животрепещущей — раз Вы потратили время на ее прочтение и теперь проявляете явное участие к ней!
Да, я не ставила такой задачи в короткой статье подробно осветить столь обширные вопросы и написать руководство к действию.
Хотела бы заметить, что последнее время прихожу к выводу, что правильно поставленный вопрос важнее досконального ответа на него. Именно так работают, например, коучеры. В т.ч. вопросы, на которые нет однозначного ответа. Видимо, это нас и цепляет. Известно, что «серебряной пули» не существует.
Спасибо за наводку на книгу (ссылка, что вы дали не работает, но мне документ удалось раздобыть — фундаментальный труд на 500 стр.).
И спасибо за идеи насчет продолжения. Правда, главы из данной книги я брать не стану — у меня есть своя тема.
Но «разбор главы из книги» — отличная идея для Вашей собственной публикации! Учитывая Ваш интерес и «заряженность» — думаю, она будет иметь успех! Удачи Вам!
Елена, добрый день. Вы говорите, что пишите о собственном опыте, мне же кажется, что это как раз не так.
Предлагаю взять любую из глав в любой части. Например последнюю:
Поправьте меня, мне кажется у Вас тут две мысли:
1. Если не вкладываться, то компании когда нибудь станет плохо.
2. Все компании разные.
Отложим момент, что мне не удалось найти в этом разделе какого нибудь ответа на «когда». Видимо, Вы подразумеваете: «всегда, если хотим, чтобы компании было хорошо».
У меня к Вам следующий вопрос: что из этого раздела на три с половиной тысячи знаков является Вашим опытом? Можно ли привести какую то мысль и описать, как она стала результатом опыта? У меня это не получается.
Беру, например:
И вижу типовой шаблон: «архитектура влияет на все». Если ударится в философию, то любой процесс в компании влияет на другой любой процесс.
Для меня этот абзац обрел бы смысл, если бы Вы пояснили: какое влияние Вы имели ввиду, почему посчитали его важным и на каком примере из жизни. Сейчас же, простите мне мою уже сделанную оценку, это выглядит как клише.
Я не вижу ценности в таких мыслях. Т.е. я пробую представить человека, кто, например является или хочет стать архитектором и раньше он чего то не знал а теперь узнает. Или, раньше у него были разрозненные знания а тут он что то структурировал. Или еще какая либо ценность?
Предлагаю взять любую из глав в любой части. Например последнюю:
Когда компании нужно вкладываться в Архитектуру? И что будет, если этого не делать?
Поправьте меня, мне кажется у Вас тут две мысли:
1. Если не вкладываться, то компании когда нибудь станет плохо.
2. Все компании разные.
Отложим момент, что мне не удалось найти в этом разделе какого нибудь ответа на «когда». Видимо, Вы подразумеваете: «всегда, если хотим, чтобы компании было хорошо».
У меня к Вам следующий вопрос: что из этого раздела на три с половиной тысячи знаков является Вашим опытом? Можно ли привести какую то мысль и описать, как она стала результатом опыта? У меня это не получается.
Беру, например:
Кроме того, на архитектурные процессы влияют особенности корпоративной культуры компании – особенно модель принятия решений, способы коммуникации, информационная открытость и т.д.
И вижу типовой шаблон: «архитектура влияет на все». Если ударится в философию, то любой процесс в компании влияет на другой любой процесс.
Для меня этот абзац обрел бы смысл, если бы Вы пояснили: какое влияние Вы имели ввиду, почему посчитали его важным и на каком примере из жизни. Сейчас же, простите мне мою уже сделанную оценку, это выглядит как клише.
Я не вижу ценности в таких мыслях. Т.е. я пробую представить человека, кто, например является или хочет стать архитектором и раньше он чего то не знал а теперь узнает. Или, раньше у него были разрозненные знания а тут он что то структурировал. Или еще какая либо ценность?
Автор в самом начале первой статьи пишет, что все IMHO исходя из личного опыта :) Я многие вещи написанные здесь вижу, как подтверждение своего опыта о том, что понятие архитектура видится и слышится везде по разному и у разных заказчиков и разных проектов имеет чуть ли не противоположные смысловые нагрузки. Поэтому лично я приветствую эту статью, как повод обобщить и обозначить дальнейшее обсуждение этой не легкой то в общем темы. Уверен, что эти статьи вводная часть и дальнейшие статьи уже будут по конкретному опыту автора, с привязкой к мыслям и терминологии, обозначенных здесь.
Уважаемый Константин!
Я не сторонница публичных дискуссий в подобном формате. Если у Вас есть конкретные вопросы, и Вы считаете, что я могу Вам помочь с ответами — пишите в личку.
Я не сторонница публичных дискуссий в подобном формате. Если у Вас есть конкретные вопросы, и Вы считаете, что я могу Вам помочь с ответами — пишите в личку.
Поддержу предыдущего оратора.
Как-то обо всём и ни о чём.
Много фраз "лучше быть здоровым и богатым".
Очень похоже на статьи о стратегическом менеджменте бизнес-тренеров средней руки.
Разумеется, не уровня Адизеса — у него-то как раз всё по делу, один пассаж в коротеньком эссе о коррупции в России чего стоит.
Желаю Вам всё-таки не отрываться от земли, даже в статьях — мыши так и не смогут отрастить иголок.
P.S. прошу не воспринимать как критиканство, просто тоже прочёл и не ощутил, что было полезно.
Как-то обо всём и ни о чём.
Много фраз "лучше быть здоровым и богатым".
Очень похоже на статьи о стратегическом менеджменте бизнес-тренеров средней руки.
Разумеется, не уровня Адизеса — у него-то как раз всё по делу, один пассаж в коротеньком эссе о коррупции в России чего стоит.
Желаю Вам всё-таки не отрываться от земли, даже в статьях — мыши так и не смогут отрастить иголок.
P.S. прошу не воспринимать как критиканство, просто тоже прочёл и не ощутил, что было полезно.
Я тоже не смог посмотреть по ссылке, это имелась ввиду — та книга, которая готовилась на Codeplex-e — про "общую (правильную) архитектуру решений"? Front-end, back-end, etc.? под общей рубрикой Patterns & Practices? Если — да, то я смею немножко возразить уважаемому Joshua…
На вопрос КАК писать (кодить) решения — хорошо написано в P&P, а вот Архитектура дает более фундаментальый ответ нафига кодить приложение (решение)…
Фактически, ИТ Архитектор — собирает задачи от Бизнеса (в идеале, сидит на Совете Директоров и предлагает бизнесу) — как с помощью ИТ и новых технологий компания сможетдобиться конкурентного приемущества, повысить… уменьшить… сократить… и т.п. для достижения (бизнес) Цели Предприятия....
Потом, "видение" Архитектора превращается в целый набор меньших "P&P Solutions", типа CRM, WMS, ERP, etc… — и при хорошем архитетокре — все они будут служить одной цели… Но, к сожалению, часто, на роль CIO приходят вчерашние СТО, и мы получаем "ворох не связных решений", которые приходиться потом долго интегрировать, и заканчивается это чехардой смен "начальников отдела ИТ"… :-)
я бы очень рекомендовал к прочтению книжку Данилина http://www.ozon.ru/context/detail/id/2451566/, он хоть и крутой рейнджер в Майкрософт, но много пороху повидал и пишет technology agnostic
На вопрос КАК писать (кодить) решения — хорошо написано в P&P, а вот Архитектура дает более фундаментальый ответ нафига кодить приложение (решение)…
Фактически, ИТ Архитектор — собирает задачи от Бизнеса (в идеале, сидит на Совете Директоров и предлагает бизнесу) — как с помощью ИТ и новых технологий компания сможетдобиться конкурентного приемущества, повысить… уменьшить… сократить… и т.п. для достижения (бизнес) Цели Предприятия....
Потом, "видение" Архитектора превращается в целый набор меньших "P&P Solutions", типа CRM, WMS, ERP, etc… — и при хорошем архитетокре — все они будут служить одной цели… Но, к сожалению, часто, на роль CIO приходят вчерашние СТО, и мы получаем "ворох не связных решений", которые приходиться потом долго интегрировать, и заканчивается это чехардой смен "начальников отдела ИТ"… :-)
я бы очень рекомендовал к прочтению книжку Данилина http://www.ozon.ru/context/detail/id/2451566/, он хоть и крутой рейнджер в Майкрософт, но много пороху повидал и пишет technology agnostic
Вы очень хорошо пишете. Интересно и вообще… Требую продолжения!
XP ответила на вопросы, на которые данная статья не отвечает. Даже Фаулер частично с этим согласен martinfowler.com/articles/designDead.html
Sign up to leave a comment.
Записки правдивого архитектора: просто о самом главном (Ч.2)