Самая большая головная боль для руководителя отдела ИТ-архитектуры – нехватка кадров. Организовать архитектурную практику в организации не просто. Надо суметь объяснить, что же такое архитектура руководству, показать её пользу на нескольких значимых проектах. А еще убедить разработчиков, администраторов, руководителей проектов и функциональных заказчиков, что архитектор — это не еще один вахтер в лабиринте корпоративных предписаний и правил, а скорее проводник, сталкер – помогающий найти easy way в нагромождении корпоративных ИТ. Но выстроить архитектурную практику и завоевать доверие заинтересованных лиц, это только первый шаг. Настоящие вызовы случаются позже. Главный архитектор очень быстро попадает в административные ловушки. С одной стороны, функциональные заказчики инициируют все новые и новые проекты и хотят заполучить в них внятных архитекторов. С другой — корпоративный HR регулярно сжимает и без того скудные позиции, а рекрутеры рассказывают грустную историю о том, что ИТ-архитекторов не существует и проще найти покемона в дополненной реальности, чем архитектора информационных систем на рынке труда. С ними сложно не согласиться. Из четырех сотен вакансий ИТ-архитектора на HH.ru значительная часть остается открытой более полугода. Читать далее Как заполнить позицию ИТ-архитектора
Симуляторы бизнес-процессов
Уже не первый год я не перестаю удивляться сценарию внедрения системы управления бизнес-процессами BPMS, разыгрываемому вендорами таких систем. Выглядит это примерно так. После успешной презентации своего решения они собирают команду заинтересованных лиц со стороны заказчика и начинают обучать его рисованию бизнес-процессов в нотации BPMN. Обычно в такую команду входят ИТ-начальники, а также эксперты и руководители функциональных подразделений заказчика. В общем все те люди, которые рисовать процессы скорее всего не будут, ни на бумаге, ни в рисовалках диаграмм, ни в навернутом BPMS инструменте, обещающем реализацию концепции model-driven development. Далее, пару недель эти люди что-то пытаются сделать и потом из тех или иных соображений принимается решение о приобретении или отказе в приобретении рассматриваемой системы. Возможной причиной такого развития событий является отсутствие в организации собственных бизнес-аналитиков (Впрочем, у поставщиков решения их тоже обычно нет, потому как продавец и аналитик – это довольно разные должности. Вряд ли хороший аналитик долго протянет в системе мотивации, выстроенный для sales). Читать далее Симуляторы бизнес-процессов
Переставляя картинки будущего
Сегодня я хочу затронуть очень абстрактную тему – чем на самом деле занимается архитектор информационных систем. Предпочитающим конкретные рецепты и практические советы лучше этот пост пропустить. Внизу в моем блоге есть много других интересных, а иногда, я надеюсь, даже и полезных сообщений. Тех же, кто решил продолжить чтение, я попрошу ответить для себя на один простой вопрос: как бы Вы сформулировали задачу своему архитектору. Причем не так уж и важно, о чем именно идет речь – о некотором отдельном приложении, продукте, включающем в себя несколько информационных систем или же целом корпоративном ИТ-ландшафте. Поставьте себя на минуту на место заказчика. Вот к вам на встречу привели человека, которого называют архитектором. Вам предстоит озвучить свои ожидания от его деятельности. Что бы Вы у него попросили? Читать далее Переставляя картинки будущего
Requirements as a Service
Одно время в моей ленте в FB довольно часто проскакивали сообщения о реестре отечественного ПО. Полное название этого чудесного справочника Единый реестр российских программ для электронных вычислительных машин и баз данных. Кто-то искренне радовался включению в этот список своей программы. Другие искренне негодовали по поводу очередной глупости чиновников. Третьи ностальгировали по временам своей молодости, вспоминая такую штуку, как фонд алгоритмов и программ. Меня же во всей этой истории удивляло только одно: почему во второй декаде XXI века эта штука называется реестр, а не marketplace. Слово реестр устойчиво ассоциируется с документооборотом. Мол есть где-то там сами программы(вероятно в виде распечатанных исходников), но чтоб вам, дорогие друзья, их самим все не просматривать, мы подготовили для вас единый реестр. Читать далее Requirements as a Service
16-17 июня. Тренинг по архитектуре ИТ-решений
Хочу совсем кратко рассказать об изменениях, которые случились в формате и содержании тренинга по архитектуре ИТ-решений и которые я впервые представлю уже в июне в курсе ITARC «Разработка и управление ИТ-архитектурой», организованном компанией IT Expert. Мы затронем два основных вида деятельности solution architect: выбор и защита варианта реализации ИТ-проекта и декомпозиция решения — определение набора изменений, необходимых для реализации проекта. Читать далее 16-17 июня. Тренинг по архитектуре ИТ-решений
Запись вебинара: архитектура ИТ-решений (IT Expert 28 апреля 2016)
Вебинар: Архитектура корпоративных приложений. Web-scale IT, DevOps, Microservices
25 мая я проведу еще один вебинар по архитектуре информационных систем. На этот раз он будет посвящен именно архитектуре приложений. Эффективная операционная модель ИТ, целевая архитектура предприятия, гибкие методологии разработки – всё это важные и нужные вещи. Но ни одна из них не исправит ошибки, допущенные при разработке архитектуры конкретного приложения. Десять лет назад SOA уже пыталась существенно улучшить архитектуру приложений. Большинству корпоративных информационных системам это не сильно помогло. Сегодня многие разработчики связывают надежды на реализацию обещаний SOA с DevOps и микросервисной архитектурой. Поверят ли в эти слова организации, будет ли у ИТ еще один шанс решить проблему унаследованных приложений?
Подробное описание вебинара и ссылка на страницу регистрации на сайте IT Expert: Архитектура корпоративных приложений. Web-scale IT, DevOps, Microservices
Отображение пути вместо рисования связей
Для упомянутого в предыдущем сообщении вебинара я нарисовал простую картинку (см. рисунок, кликабельно). Я не следовал какой-то строгой нотации в этом наброске. Моей целью являлось в двух словах рассказать о том, что такое система управления инцидентами, какие акторы (действующие лица) участвуют в работе с такого рода системой и как выглядит процесс решения инцидента. Главным характеризующим свойством такого рода процессов является наличие двух уровней поддержки. (Иногда выделяют большее количество уровней, но для нас сейчас это не принципиально) На первом уровне происходит классификация обращения и назначение его на соответствующую группу второго уровня. Иногда инцидент может быть решен и на первом уровне. Есть даже специальный KPI, именуемый First Line Resolution Rate, который показывает долю инцидентов, закрытых первым уровнем поддержки. Читать далее Отображение пути вместо рисования связей
Вебинар: архитектура ИТ-решений
Уже скоро. 28 апреля, в четверг с 11:00 (MSK). Подробности и регистрация: http://www.itexpert.ru/rus/webinar/
Уровни зрелости разработчиков интеграционных решений
Лет 7-10 тому назад, во времена всеобщего увлечения сервис-ориентированной архитектурой было модно придумывать уровни зрелости SOA сервисов. Open Group придумал Service Integration Maturity Model (OSIMM). IBM отметился свое трактовкой уровней зрелости (см., например Solution design in WebSphere… ), обещающий достигнут пятого из семи возможных уровней зрелости посредством внедрения WebSphere Process Server (см. рисунок ниже). Ну, а Microsoft c Informatica-ой занимались оценкой уровней зрелости в деле интеграции данных (A Maturity Model for Data Integration) В общем, каждый занимался своим делом. IBM даже порывался сделать у нас консалтинговый проект, но мы сами приписали себе второй или третий уровень зрелости и сразу согласились на пилотный проект с WS Process Server.По результатам пилота мы даже приняли решение внедрить BPEL Engine, правда не от IBM-а, а open source, да и WebSphere Message Broker из эксплуатации вывели (кому нужен инструмент не того уровня зрелости 😉 Читать далее Уровни зрелости разработчиков интеграционных решений