Инструменты управления архитектурой и управления требованиями

17 марта 2014
8

Последнее время возрастает интерес к теме управления архитектурой и поиску эффективных механизмов взаимодействия с бизнесом. Сообщество Global CIO активно обсуждает такие «архитектурные» темы, как «Архитектурный тупик и выходы из него», «Управление архитектурой предприятия как способ «наведения мостов» с бизнесом», «Отучение от ITIL. Три ошибки ITIL, которые надо обойти», «Уровни зрелости систем «Service Desk» и другие. Это радует.

Однако есть момент, на который я обратил внимание и который пока никто не обсуждал: с инструментами управления архитектурой творится какая-то вакханалия. Например, одним из общедоступных источников информации по сравнению этих инструментов являются «магические квадранты» от Gartner. Лидерами (квадрантов BPA или EATools)в разное время был инструментарий ARIS, Alfabet, Mega, Casewise и другие, уступая или вырываясь вперед по каким-то «магическим» причинам. В середине прошлого года Software AG приобрела Alfabet, что отразилось на оценках продуктов, в новых версиях «магических квадрантов» в лидерах оказались Mega и IBM Rational Enterprise, а новые интересные, в том числе оpensource, продукты оказались почему-то за рамками рассмотрения.

В общем, я и раньше не доверял «магическим квадрантам», а сейчас тем более. Поэтому решил разобраться для себя, пригласить энтузиастов к дискуссии и обменяться опытом, разобраться хотя бы с парой десятков инструментов в этой области. В рамках серии дискуссий я постараюсь сформулировать общие принципы и требования к инструментам управления архитектурой и на основе них сформировать материал, по которому будет легче разобраться, кто есть кто в текущей ситуации на этом рынке.

В ходе обсуждения я подготовлю и проведу (если позволят технические и организационные факторы) демонстрации продуктов в рамках вебинаров на площадке Global CIO, о чем буду объявлять дополнительно. Если будут видео или другие материалы по продуктам от вендоров, дам ссылки.

Предлагаю открыть обсуждение этой темы по вопросам:

1. Какие инструменты используются или к каким «присматриваются» участники сообщества для описания, проектирования архитектур (процессов, управления требованиями, бизнес-приложений, ИТ-инфраструктуры и т.п.). Какие инструменты хотелось бы увидеть подробнее?

2. Каков базовый и дополнительный функционал систем управления архитектурой?

3. Шаги и критерии оценки продуктов.

4. Сбор, публикация и обсуждение материалов о функциональности, сильных и слабых сторонах каждого продукта, опыта их промышленного внедрения и эксплуатации.

5. Получение представления о линейке продуктов, их сильных и слабых сторонах. Если получится со временем, напишу аналитический отчет по результатам сравнения.

6719
Поделиться
Коментарии: 8

Комментировать могут только авторизованные пользователи.
Предлагаем Вам в систему или зарегистрироваться.

  • Марк Шварцблат
    Рейтинг: 10
    КТ "Акведук"
    ИТ-директор
    18.03.2014 17:44

    Мндя. Что-то из "А не замахнуться ли нам на Вильяма нашего Шекспира". :)

    Я для себя давно сформулировал некий идеал, когда (идин из возможных примеров) инструментарий BPM влияет на инструментарий архитектуры, который влияет на КИС и инструментарий управления инфраструктурой непосредственно. Т.е. сквозная многосвязная структура. Но это идеал. Особого приближения к нему не наблюдается. Ну и актуальность проблемы для некрупных организаций не велика. Поэтому мал практический опыт. Но коллег с удовольствием почитаю.

    • Илья Караваев Марк
      Рейтинг: 10
      РДТЕХ
      Руководитель Практики ИТ-консалтинга
      04.04.2014 16:09

      Действительно, существует представление, что инструментарий (и методология) управления процессами должны влиять на архитектуру (включая набор систем и их реализацию, инфраструктуру и тп). А как конкретнее? В этой многослойной и «многосвязной» структуре надо наладить сквозные процессы, в том числе управления требованиями при внедрении или изменениях систем. По идее системы из упоминаемых квадрантов и должны решать в частности эту задачу. А как весьма верно подмечено, что-то не чувствуется приближения к этому. Вот и хотелось бы понять, что из них реально полезно. А некрупным организациям это тоже интересно, только это другая ниша, другой ценник, нужны уже отработанные подходы и инструменты…

      • Марк Шварцблат Илья
        Рейтинг: 10
        КТ "Акведук"
        ИТ-директор
        04.04.2014 17:58

        Нужны. И существуют. В виде шаблонов к офисным продуктам. :) А бесплатные открытые продукты - это первое, что сейчас проверяется при возникновении любой задачи. Если они есть, то уже появляется поле для манёвра.

        Не готов я много и связно по теме написать. Практика есть, но ее маловато.

    • Илья Караваев Марк
      Рейтинг: 10
      РДТЕХ
      Руководитель Практики ИТ-консалтинга
      04.04.2014 16:11

      Кстати, тема действительно "шекспировская". Вечная :)

  • Дмитрий Маслов
    Рейтинг: 10
    ООО "Магма-компьютер", ЗАО СиСофт
    Руководитель проектов комплексной автоматизации
    19.03.2014 07:16

    Здравствуйте!
    Тема ожидается интересной. У себя в организации мы, зная что существуют какие-то механизмы формализации процессов, пытались решать проблему. Но, ввиду большого практического опыта проектировщиков (!) (мы - архитектурная фирма) все сводилось к томам бумаги, оформленной по ISO9000 и абсолютно бесполезной... Сейчас у нас процессы идут как идут - носители процессов это конкретные специалисты. Управление - полуручное. Основной механизм контроля процессов - бесчисленные эксел-таблицы, выдаваемые нагора так называемыми экономистами. в общем, обычная практика для нынешних проектных организаций... хотя, я видел в прошлом году в Мостовике - Business-studio. Айтишнки уже ее используют. Думаю, что на этом продукте можно остановиться поподробнее - тем более, отечественный продукт

    • Илья Караваев Дмитрий
      Рейтинг: 10
      РДТЕХ
      Руководитель Практики ИТ-консалтинга
      04.04.2014 16:14

      Да, обязательно остановлюсь. C Business Studio часто сталкиваюсь у заказчиков, приходится объяснять что он может и чего не может в части управления ИТ-архитектурой. Надо понимать для чего действительно он эффективен

  • 19.03.2014 12:29

    <?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /> Господа, пзвольте небольшое уточнение по поводу «Инструментов управления архитектурой». Управляют не инструменты. Управляют люди. Инструменты лишь дают информацию для принятия решения и могут помочь провести это решение в жизнь. Разве «системы управления проектами» управляют проектами в вашей компании? Если уточнение принимается, то, все задачи управления архитектурой разделил бы на два класса:

    • Сбор и предоставление информации об объекте управления – Описание архитектуры
    • Проведение в жизнь решение об изменении архитектуры. Причем, инструментальное обеспечение этого класса задач совсем не исчерпывается автоматизированными системами проектирования. Сюда можно отнести практически все задачи, которые вносят изменения в функционирование компании.
    Т.е., если кто-то собирается чем-то управлять, то, было бы правильно, прилучить необходимую информацию об объекте управления и выбрать, среди имеющихся средств инструмент, подходящий для управляющего воздействия. А можно ли ограничиться чем-то одним? Увы, на практике, так оно и есть. Есть много историй про описание архитектуры компаний или конкретных видов деятельности компаний, которыми потом не пользуются. Есть и масса историй успеха про разработку и внедрение хороших архитектурных решений в компаниях, у которых и вовсе не было описания архитектуры As Is. Поскольку мой профессиональный интерес лежит именно в области задач описания архитектуры, то хочу воспользоваться вашей дискуссией и попросить участников высказаться по поводу продвигаемого нами подхода к описанию архитектуры (http://www.rbtechnologies.ru/cartography/Docs/cartography-17.04.2013.pdf). Не сочтите ссылку скрытой рекламой. Описываемый подход может воспроизвести любая компания своими силами. Да и ничего революционного в нем нет. Решение, которое предлагает для описания архитектуры предприятия компания РДТех – это то же самое, только на более высоком научно-техническом уровне. Гораздо более высоком, но концептуально близком.

  • Дмитрий Кудрявцев
    Рейтинг: 10
    CIO-on-demand.ru
    партнёр
    08.07.2014 16:41

    Магические квадраты - это инструмент "защиты" крутизны того решения, на которое вы сами уже замахнулись и пошли защищать бюджет. Остальное - от лукавого. Дело тут в другом.

    Вот Марк Рудольфович повыше сказал - что "идеальный конь" бывает, но только "в вакууме". Это не сложности его локальной ситуации, даже в Fortune-500 мало кто умеет сразу всё из требуемого. Если исходить из современных реалий, всё зависит от наличия целой, не побоюсь, культуры управления.

    Если посмотреть на задачу (каким инструментом описывать инфраструктуру), то идти надо и снизу и сверху. Ибо это не задача, а элемент мозаики, которая, не будучи сложенной, "не взлетит".

    Инфраструктура это материальные или сервисные ресурсы, которые поддерживают бизнес-процессы (если вы не ИТ-компания, конечно). То есть, следствие. Бизнес-процессы направлены на достижение бизнес-целей (т.е. их надо а) иметь и б) записав - декомпозировать до требований к скорость вращения "шестерёнок" бизнес-процессов - процедур, а оттуда выделить те, которые используют ИТ).

    Соответственно, "сверху" нужны стратегия и BPM.

    Увязывание требований "сверху" с ландшафтом ИТ - основное содержимое ИТ-стратегий. Но это если на бумаге. А если в жизни - нужно делать сервисно-ресурсную или ресурсно-сервисную модель (кому как нравится). Это фактически регулярно обновляемая CMDB. Мы тогда точно видим, какая доля каких железок, программ, человеко-часов и мегабит каналов связи утилизируется на сервис. Можем считать capacity и финансовые штуки, проектировать запас по мощности и ТОиР, да много чего там можно вытащить. Это уже ITIL'ная работа (по организации) и является кирпичиком "снизу". Чего мы не сможем тут сделать - провести однозначно связь между скоростью исполнения операции на АРМ и ландшафтом...

    ...потому что есть ещё кирпич "сбоку" - КИС. Это, фактически, "сшивающая" требования и ландшафт прослойка. Тут всё просто: нужно уметь мерять производительность КИС в определённом ракурсе (продолжительность выполнения операций), выявлять зависимость от программно-аппаратных ресурсов и встраивать эти коэффициенты в связь между сервисно-ресурсную модель (снизу) и перечнем требований к операциям из бизнес-модели (сверху).

    Вот тогда всё получится.

    Нереального тут ничего нет, но работы, прощу прощения, дохрена.

    А зачем это делать, никому неведомо.

    Собственно, инструментарий моделирования для этой задачи - вторичен. Ибо универсальный брать просто боязно (это что ж за монстр получится), а отдельно стоящие - их целые рынки, бери под свой кошелёк и вкус что угодно.

Предметная область
Отрасль
Управление