Архитектор – строит, а что делает аналитик?

Пара вводных слов

Сразу сделаю несколько пояснений:

• Речь в этой статье только об области знаний и поле деятельности 1С. Т.е. если написано, «Специалист технической поддержки», то подразумевается, что это техническая поддержка 1С, а не поддержка приема и учета жалоб локального ЖКХ.
• В статье говорится о внедрении 1С на средних и крупных проектах. Данные рассуждения для малых компаний с запросом – «нам в бухгалтерии нужен вот такой отчетик» – не подходят.
• Рассматриваем только особенности применения архитектуры предприятия и ИТ-архитектуры на практике, и в рамках проектов внедрения ИТ. Более широкие вопросы, например, по трансформации бизнеса и изменений финансовых показателей и др. – не рассматриваем.

Часть 1. Попытка разложить все по полочкам

Об «архитектуре» пишут много, пишут часто, пишут вкусно, становятся экспертами, передают экспертный опыт, а еще бывают книги, тренинги, курсы, консалтинги, консорциумы, институты с обязательной вставкой EA (Enterprise Architecture) – IFEAD, iEAi, международные стандарты – ISO 15704, 42010 и др., и, да, можно говорить, писать долго и не по делу. А дело есть и вполне конкретное, и даже два:

• Вопросы, что такое «Архитектура», «Предприятие» и они вместе «Архитектура предприятия» остаются на повестке дня. И кто всем этим заведует?
• И, как 1С с этим сосуществует и интегрируется ли? 

Если начать вникать, то методик, моделей, фреймворков – много, например, все что оканчивается на AF (Architecture Framework) – TOGAF, FEAF, TEAF, DoDAF и т.п.

Однако, когда стоит цель – провести автоматизацию или модернизировать существующие процессы, то волей-неволей приходится сталкиваться с этими понятиями – «Архитектура предприятия» и «Информационная архитектура». И иметь четкое представление, что это и как с этим работать. Сейчас просто вспомним для общего понимания картины.

Погружаясь в эти понятия, можно заметить такое разделение:

• В иностранной литературе в понятие «ИТ-архитектура» входит понятие «Бизнес-архитектура». Одно следует из другого. Это наследие Дж. Захмана (J.A. Zachman). Он является родоначальником большинства известных описаний структур и именно он стал использовать их для описание ИТ-архитектуры. И со временем, скажем любимую фразу – исторически так сложилось, что понятие «Архитектура информационных систем» стало подменяться понятием «Архитектура предприятия». И произошло то, что сейчас, при описании чистой архитектуры предприятия, используются совсем не относящиеся к ней ИТ-термины.
• В отечественном понимании эти понятия раздельные. При этом понятие «Архитектура предприятия» практически всегда приравнивается к понятию «Организационная структура» или «Корпоративная архитектура». А понятие «ИТ-архитектура» приравнивается к понятию «Архитектура программного обеспечения».

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

Определения – это не объяснения, но попробуем разобраться во всем этом. Если взять хотя бы понятие «Архитектура», то их можно уже насчитать несколько и это, не используя какое-либо слово-приставку к нему. Поэтому данная статья не пытается дать точное определение (а такого может и не быть), а лишь обозначить приемлемый вектор понимания используемого понятия.

Итак, когда люди произносят «Архитектура», что они имеют в виду? – Правильно, здания, сооружения, исторические постройки, т.е. все что относится к зодчеству. А если взять кружку. У нее есть архитектура? Что делает кружку кружкой? Что отличает ее от пивного бокала или от демитассе? – Архитектура.

Архитектура – это описание модели, общих элементов, взаимосвязей, конструкций, описание каркаса, скелета.

Но нам нужно понять, что будет тогда архитектурой предприятия.

Предприятие (организация, бизнес, предпринимательская структура) – это по природе своей система с взаимосвязанными элементами, не просто зависимыми, а влияющими друг на друга и преобразующими друг друга.

Теперь соединим эти два понятия «Архитектура» и «Предприятие». Получаем.

Архитектура предприятия (Enterprise Architectures, EA) – это полное описание (модель) структуры предприятия как системы и способы ее работы, включающее описание ключевых элементов и требований этой системы, связей между ними, а также набор взаимосвязанных моделей, описывающих структуру и функции.

При определении «Предприятия» и «Архитектуры предприятия» фигурирует такое понятие как «Система».

Система – это совокупность элементов, находящихся в отношениях и связях друг с другом, которая образует определенную целостность.

Архитектура системы – это принципиальная организация системы, воплощенная в ее элементах, их взаимоотношениях друг с другом и со средой, а также принципы, направляющие ее проектирование и эволюцию.

Наравне с BABOK (Business Analysis Body of Knowledge) – сводом знаний по бизнес-анализу и CBOK (Business Process Management Common Body of Knowledge) – сводом знаний по управлению бизнес-процессами, существует и BIZBOK (Business Architecture Body of Knowledge) – свод знаний, охватывающий основные области бизнес-архитектуры организации и сопутствующие практики.

По версии BIZBOK в состав архитектуры предприятия входят: бизнес-архитектура, бизнес-модель, модель бизнес-процессов, организационная структура, структура технических средств (включающая ИТ-архитектуру и др.).

Бизнес-архитектура (Business Architecture, BA или Enterprise Business Architecture, ЕВА) – это чертеж организации, который отображает полную картину организации и используется для синхронизации стратегических целей и тактических потребностей.

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

Традиционно ИТ-архитектуру предприятия представляют в виде нескольких взаимосвязанных компонентов:

• Информационная архитектура (Enterprise Information Architecture, EIA) – набор методик и инструментов, описывающий информационную модель предприятия.
• Архитектура прикладных решений (Enterprise Solution Architecture, ESA) – представляет архитектуру приложений, включающую в себя совокупность программных продуктов и интерфейсов между ними. В ней выделяют архитектуру программного обеспечения (Software Architecture) – совокупность важнейших решений об организации программной системы, которая может быть описана с помощью фреймворков (Software Architecture Frameworks): 4+1, RM-ODP (Reference Model of Open Distributed Processing), Service-Oriented Modeling Framework (SOMF).
• Техническая архитектура (Enterprise Technical Architecture, ETA) – совокупность программно-аппаратных средств, методов и стандартов, обеспечивающих эффективное функционирование приложений.

Архитектура информационных систем предприятия основывается на двух идеологических определениях:

• Набор решений, наиболее существенным образом влияющих на совокупную стоимость владения системой;
• Набор ключевых решений, неизменных при изменении бизнес-технологии в рамках бизнес-видения.

Возвращаясь к определению архитектуры предприятия, можно выделить два подвида:

• Текущая архитектура (Current Architecture) описывает существующее состояние архитектуры предприятия, ее объективной реальности. Называется также архитектурой «Как есть» / AS IS, или базовым состоянием существующей архитектуры.
• Целевая архитектура (Target Architecture) описывает будущее желаемое состояние (модель) предприятия или то, «Как будет» / TO BE.

Говоря об архитектуре предприятия и особенно в момент ее развития или реинжиниринга требуется знать, как понятие «Стратегия бизнеса» («Бизнес-стратегия»), так понятие «ИТ-стратегия».

Бизнес-стратегия – это направления развития фирмы в соответствии с поставленными стратегическими целями и задачами. Она отвечает на вопрос – почему фирма должна развиваться именно так и в этом направлении. Бизнес-стратегия включает:

• цели и задачи, стоящие перед предприятием;
• бизнес-решения, необходимые для достижения поставленных целей и задач;
• изменения, которые нужно провести для достижения поставленных целей и задач.

ИТ-стратегия – это направления развития информационных технологий фирмы в соответствии с поставленными в бизнес-стратегии целями и задачами, а также варианты их исполнения. ИТ-стратегия включает:

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

Часть 2. Нужны ли эти все люди и как их называть?

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

Есть два мнения и каждое имеет право на существование. Особенно, если оно аргументировано минимум тремя пунктами.

1. «Как корабль назовешь, так он и поплывет» (С) Капитан Врунгель

Вроде все понятно и без доказательств. Если твоя должность «Специалист технической поддержки», то ну вряд ли ты будешь вводить первичную документацию за пользователей. Однако на практике встретить можно много всего интересного, например, должность «Бизнес-аналитик развития информационных систем» – так будет звучать вакансия, на самом деле окажется, что требуется консультант с хорошими знаниями различных видов учета (складского, финансового, оперативного, валютного и др.) в программе «1С:ERP Управление предприятием» («1C:ERP»). И на вопрос – а где тут развитие? Вы получите ответ – ну как, вы же будете решать насущные проблемы, т.е. развивать бизнес. Тут можно поспорить.

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

2. «Кадры решают все» (С) Сталин И.В.

Проблема как правило в кадрах. Это основной актив компании. Однако, как программиста ни назови – хоть архитектором, хоть разработчиком, хоть инженером – по сути это ничего не поменяет. Что было заложено в его должностных обязанностях при приеме на работу (или что по факту от него каждый день требуется, не взирая на его должностные обязанности), например, проектирования и реализации высоконагруженных систем, аудит текущей информационной системы, оптимизация производительности и в том же ключе – это и будет. Хотя вроде и программистом назван и должен просто кодить. Т.е. тут важен результат – поставила фирма цель – ее исполнять. Если есть тот, кто понимает, что делать для развития системы или если она стала не эффективной – это хорошо. Если нет такого человека, то тут далеко не уедешь.

А к чему эти два описанных выше момента, а к тому, что вспомним проект внедрения любой 1С. В команде будут: менеджер проекта, руководитель проекта, архитектор, аналитик, программист/ы, консультанты и еще много кого. И мы говорим о команде только со стороны исполнителей. А теперь подробнее:

• Менеджер проекта. Тут вроде все очевидно. Это такой человек, кто готовит документы – акты, накладные, смотрит сколько часов потрачено, выставляет счета. Присутствует на первой установочной встрече. Грубо говоря, ведет бумажную официальную работу между Клиентом и Исполнителем.
• Руководитель проекта. Вот тут уже становится интереснее. В общих и главных чертах руководитель проекта – это лицо, которое несет ответственность за проект. Или, иначе руководитель проекта (Project Manager, PM) – лицо, наделенное ответственностью и правами по руководству работами в рамках проектной задачи. А теперь внимательно посмотрим на его английское название и вот тут встречаем путаницу, так как Руководителя проекта частенько называют и приравнивают к Менеджеру проекта. А это совсем не так. Детально не будем останавливаться, но вкратце обозначим обязанности Руководителя проектов:
  • Определение устава, целей, задач и результата проекта.
  • Составление и подготовка плана внедрения нового проекта, определение контрольных точек.
  • Определение количества ресурсов, требуемых для выполнения проекта.
  • Определение стоимости и бюджета проекта.
  • Выбор команды проекта и определение ролей и обязанностей в проекте для всех членов команды проекта.
  • Мониторинг хода исполнения проекта, прогнозирование отклонений и принятие своевременных мер по их устранению.
  • Организация и проведение совещаний команды проекта, а также координация коммуникаций между всеми участниками проекта и его заинтересованными сторонами.
  • Решение проблем, возникающих на проекте. Как тех, которые исходят от команды проекта, так и тех, которые могут возникают при управлении заинтересованными сторонами проекта.
  • Проведение анализа эффективности этапов проекта и проведение послепроектного анализа.

• Архитектор. Его можно определить, как специалиста, организующего процесс разработки всех разделов проектной документации. Его основная цель – обеспечение решения задач бизнеса при помощи информационных технологий. В зависимости от масштаба проекта и понимание сущности проекта исполнителем, архитектор может быть далеко не один, и уже называться – бизнес-архитектором, функциональным архитектором, системным архитектором, техническим архитектором. Обобщенные ключевые обязанности:
  • Проектирование системы на основе требований заказчика;
  • Определение архитектуры системы;
  • Выбор технологии реализации поставленных задач;
  • Создание прототипа системы;
  • Обзор бизнес-требований;
  • Обзор и анализ кода больших изменениях;
  • Документирование всех архитектурных решений, постоянное обновление документации.

• Аналитик. Как правило, это специалист, занимающийся изучением и обобщением различного рода информации по заданной цели, владеем методами анализа и моделирования процессов. В целом тут может быть зеркальная позиция с архитектором. Они могут и по-хорошему должны работать в паре. Отсюда можно выделить аналитика бизнес-процессов, функционального аналитика, системного аналитика, технического аналитика. Обязанности аналитика на проекте:
  • Выявление, сбор, анализ и описание требований;
  • Взаимодействие с заказчиками и экспертами предметных областей;
  • Анализ состояния бизнес-процессов «Как есть» / AS IS и моделирование их состояния «Как надо» / TO BE;
  • Консультации по выбору и внедрению информационной системы, обеспечивающей оптимальное решение выявленных задач;
  • Контроль реализации требований на всех этапах проекта;
  • Разработка технических заданий и постановка задач на разработку.

• Консультант. Как правило на его долю выпадает постпроектное сопровождение или сопровождение на этапе промышленной эксплуатации. Т.е. его можно определить как специалиста, консультирующего пользователей по определенной предметной области и определенному кругу пользовательский вопросов, связанных с отражением хозяйственных операций в программе. Однако, могут встретиться еще две задачи, возникающие перед консультантами: вопросы по постановке учета в программах и формирование заданий программистам на разработку. Считать эти задачи задачами консультанта – не совсем корректно, особенно при наличии других ролей на проекте, например, архитектора и аналитика. Поэтому ключевая задача консультанта – доступно преподносить информацию разного уровня сложности и помогать разбираться в работе программы пользователям, возможно это совмещать с элементами обучения.
• Программист. Программист выстраивает программный алгоритм (пишет код) – это его основная задача. Тут все четко и понятно.
• Все остальные:
  • Тестировщик – иногда эту роль / функцию относят на уровень аналитиков, консультантов, ну и в самом крайнем случае – пользователей. Хорошо, данного специалиста может и не быть на проекте, если есть используется атематическое тестирование по кейсам.
  • Технический писатель – это специалист, который занимается составлением документации в рамках разработки различных программ и автоматизированных систем. К составляемым документам относятся задания для специалистов, руководство по эксплуатации для пользователей и многие другие.
  • UX-дизайнер (User Experience Designer) – это проектировщик, который изучает потребности пользователей, строит логические схемы работы интерфейса, тестирует прототипы на целевой аудитории и составляет техническое задание для UI-дизайнера.
  • UI-дизайнер (User Interface Designer) – дизайнер интерфейсов, который визуализирует рабочий прототип, отрисовывает кнопки, иконки, формы и другие его компоненты и собирает их в гармоничный работающий макет.
  • Специалист по информационной безопасности – принимают непосредственное участие в создании системы защиты информации, ее аудите и мониторинге, анализируют информационные риски, разрабатывают и внедряют мероприятия по их предотвращению.
  • Системный администратор – это специалист по обслуживанию компьютеров и локальных компьютерных сетей.
  • Администратор баз данных – это специалист, обслуживающий базы данных, как правило серверные базы данных, в которых информация собрана с разных компьютеров и может читаться на каждом из них.

Список «Всех остальных» может быть и избыточен, а может быть и недостаточен, все зависит от масштаба и уровня проекта по автоматизации.

А теперь накладываем все это на рассмотренные выше понятия «Архитектура предприятия» и «ИТ-архитектура», и получаем нужную картину. С этими двумя понятиями тесно работают два специалиста: архитектор и аналитик. Рассмотрим, какой архитектор и какой аналитик отвечает за какие области и решает какие задачи.

• Бизнес-архитектор / Бизнес-аналитик

Зона ответственность данных архитектора и аналитика расположена на самом верху. Они оперируют понятиями бизнеса и говорят на одном языке с Заказчиком. Их обязательная область знаний – методологии различных видов учета, а также организационное управление, они должны хорошо представлять предметную область. Работа происходит на уровне архитектуры предприятия и бизнес-архитектуры. Первооснова данных для них – это бизнес-цели фирмы.

Основные результаты их деятельности:

• • Карта бизнес-процессов «Как есть» / AS IS;
  • Перечень бизнес требований;
  • Карта бизнес-процессов «Как будет» / TO BE;
  • ИТ-ландшафт «Как есть» / AS IS;
  • Дорожная карта изменений (переход от AS IS к TO BE).

Дорожная карта изменений содержит в себе мероприятия нескольких типов:

• • Реинжиниринг бизнес-процессов или внедрение изменений процессов – выполняется бизнес-архитектором / бизнес-аналитиком;
  • Изменения методологии учета, иначе внедрение изменений учетной политики – выполняется бизнес-архитектором / бизнес-аналитиком;
  • Технологические изменения или внедрение / развитие программных продуктов под изменения бизнеса – выполняется системным архитектором / системным аналитиком.

Первая особенность дорожной карты изменений, что технологические изменения могут идти первыми, при выполнении двух условий:

• • Автоматизируемый бизнес-процесс или учет не предполагает изменений. Однако если бизнес-процесс или учет подлежат реинжинирингу (изменениям), то мероприятия по внедрению изменений в процесс и в ИТ-систему следует рассматривать и реализовывать отдельно и последовательно;
  • Автоматизируемый бизнес-процесс или учет соответствует требованиям автоматизации. Это означает, что бизнес-процесс или учет на текущий момент полностью осмыслен и внедрен и успешно используется бизнесом, но не автоматизирован. Если бизнес-процесс или учет существует только на бумаге, то первыми должны идти мероприятия по их внедрению.

Вторая особенность дорожной карты изменений. Если уйти от контекста ИТ-архитектуры, то, по сути, дорожная карта может содержать в себе еще внедрение финансовых и иных бизнес-понятий, таких как: изменения источников заемного финансирования, выход фирмы на IPO, открытие новых рынков сбыта, каналов продаж, открытие стартапа и т.д. Это задача бизнес-архитекторов, но более широкая и уже не в рамках ИТ-процессов.

• Функциональный архитектор / Функциональный аналитик

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

Основные первичные данные, с которыми происходит работа:

• • ИТ-ландшафт «Как есть» / AS IS;
  • Карта бизнес-процессов «Как будет» / TO BE;
  • Перечень функциональных требований.

Основные результаты их деятельности:

• • Сценарий работы с системой (часть технического задания, посвященная работе с существующим функционалом целевой архитектуры, может так же встречаться название – отчет о моделировании);
  • Перечень функциональных разрывов.
• Системный архитектор / Системный аналитик

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

Основные первичные данные, с которыми происходит работа:

• • Перечень бизнес требований;
  • ИТ-ландшафт «Как есть» / AS IS;
  • Карта бизнес-процессов «Как будет» / TO BE;
  • Требуемые изменение (т.е. автоматизируемая функция, или процесс, или учет в соответствии с дорожной картой изменений).

Основные результаты их деятельности:

• • ИТ-ландшафт «Как будет» / TO BE;
  • Карта бизнес-процессов «Как будет» / TO BE в понятиях целевой архитектуры, т.е. с учетом ограничений внедряемых продуктов;
  • Перечень функциональных требований;
  • Техническое задание на систему.

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

• Технический архитектор / Технический аналитик

Заключительное звено в цепочке разработки – это работа технического архитектора и технического аналитика. Они на основе данных трех предшественников формируют задания на разработку программистам. В основе своей работы они использую данные о платформе. Исходные данные для их работы: ИТ-ландшафт в модели «Как есть» / AS IS, карта бизнес-процессов «Как будет» / TO BE, сценарий работы с системой и перечень функциональных разрывов. Они ответственные за написание технических заданий и реализацию внесения изменений. Осуществляют контроль за исполнением технических заданий.

В итоге, на практике при внедрении программ системы 1С или, если более витиевато – при автоматизации бизнес-процессов Заказчиков, можно с большей вероятностью встретить аналитика, реже архитектора, логического разграничения внутри этих должностей как правило нет.

За некоторые интересные мысли благодарю Дениса Галимова – руководителя Отдела экспертизы ПервогоБИТа.