Типичная ситуация в ИТ-проектах: приходит задача на автоматизацию, бизнес-аналитик начинает с нуля собирать требования, рисовать процесс, согласовывать его с заказчиком, выявлять исключения, уточнять роли и данные. Проходит время, задача уходит в разработку. Через месяц — новый запрос, и снова тот же путь. Процессы рисуются «под задачу», не связаны между собой, в каждом проекте — своя терминология и своё видение.

Обратная ситуация - если бы в компании была единая, поддерживаемая и согласованная модель деятельности, которую можно «взять» как основу для любой задачи на автоматизацию. Такая модель и есть процессная архитектура организации.

В своей практике я часто вижу одну и ту же проблему. Корпоративные архитекторы проектируют схемы целевой архитектуры (в лучшем случае - в репозитории в ArchiMate, но чаще просто в PowerPoint) , Solution и Software-архитекторы принимают тактические решения, а итоговая архитектура реализованного решения всё равно "плывёт" и не соответствует задуманному.

Стратегия остаётся слайдами в PowerPoint. Принципы — просто слова на виртуальной доске. Команды разрабатывают "как удобно" (или "как быстрее), а не "как задумано".

Почему так происходит? Потому что между стратегией и реализацией есть разрыв, т.к. между ролями участников ИТ-производства нет чётких процессов взаимодействия на уровне конкретных объектов управления и зон ответственности. Преодоление этого разрыва — зона ответственности архитектора-методолога.

В этой статье я разберу несколько ключевых концепций, которые помогают этот разрыв закрыть: Discovery и Delivery, TOGAF ADM и Change Management. А в финале покажу, как они агрегируются в IT-Governance — и почему архитектор-методолог (такую роль можно встретить очень редко в виде чётко сформулированного запроса) находится в центре этого агрегатора.

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

Этот разрыв преодолевается там, где архитектурное мышление интегрируется с методологией управления ИТ-процессами. Агрегация компетенций корпоративного архитектора и ИТ-методолога превращает ADM из теоретического цикла в работающий механизм трансформации.

ArchiMate, являясь языком проектирования архитектуры, предоставляет чёткую систему взаимосвязей между объектами. Эта система задаёт возможные варианты отношений для конкретной ситуации и контекста. Учитывая универсальность языка, это огромное преимущество — с его помощью можно описать как бизнес-архитектуру, так и системную, и технологическую.

В данной статье я приведу пример моделирования в нотации ArchiMate для ситуации, когда необходимо смоделировать бизнес-процесс сложной и противоречивой предметной области. Такая задача часто встречается при автоматизации процессов государственных органов и организаций, работающих в строгих законодательных рамках.

Представьте: вам поручили спроектировать систему, обрабатывающую персональные данные. Требования размазаны по пулу статей НПА, а за ошибку грозят миллионные штрафы. Как структурировать эту сложную область и убедиться, что вы ничего не упустили? В этой статье я на примере положений ФЗ «О персональных данных» (далее по тексту – ФЗ) покажу, как язык ArchiMate помогает превратить юридический текст в четкую архитектурную схему. Такой подход помогает выявить пробелы в требованиях, наглядно согласовать их с заказчиком и заложить основу для проектирования ИТ-решений.

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

Казалось бы, эта эпоха позади. ИТ и бизнес стали единым целым, а роли и специализации — общепринятой нормой. Но на смену старой проблеме пришла новая. Появилось множество методологий, фреймворков и новых ролей, однако единой и понятной модели так и не сложилось. Неопределённость сохраняется — особенно в названиях архитектурных ролей и их обязанностях, что отлично видно на порталах с вакансиями.

На практике это порождает новую версию старой фразы: «Ты же архитектор? Вот и придумай, как это сделать, собери требования, спроектируй данные и проверь, чтобы влезло в бюджет».

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

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

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

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

Бизнес-требования на автоматизацию и их связь с корпоративной архитектурой организации

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