Современные информационные технологии (ИТ) становятся неотъемлемой составляющей любого предприятия. Сегодня они для многих предприятий - не просто способ автоматизации рутинныхопераций (технологическая подложка), а эффективный инструмент в конкурентной борьбе. Современные ИТ – системы призваны быстро адаптироваться к новым потребностям бизнеса (его целям задачам) и полностью соответствовать архитектуре предприятия (EnterpriseArchitectureEA).
В настоящее время много говорится об эффективности информационных технологий на предприятии, но при этом многие из аналитиков крупных компаний (например, Клиф Финкельштейн) считают, что предприятия просто перешли от состояния ручного хаоса к состоянию хаоса автоматизированного. Соответственно, любые крупные предприятия требуют структуризации и документирования, как бизнес-процессов, так и поддерживающих их информационных технологий.
Зачем нужна архитектура предприятия? Вопрос о необходимости архитектуры предприятия и архитектуры информационных технологий возникает достаточно часто. Понятие «архитектура» изначально относилась к области градостроительства. Для того, чтобы построить дом или спроектировать город, необходимо иметь определенный план, чертеж, позволяющий оценить все сооружение, в целом, и посчитать затраты на его реализацию. План здания (города) должен четко соответствовать функциональным требованиям заказчика к сооружениям этого класса.
Внедрение информационных технологий на предприятии, как и строительство, является сложным трудоемким процессом, но, при этом, многие крупные компании тратят колоссальные денежные средства на внедрение различных информационных систем без малейшего представления об общей концепции развития предприятия. Можно себе представить крупный город, в котором строительство отдельных зданий производится хаотично, без архитектурных планов и долгосрочной концепции развития?
Построение комплексной информационной системы современного предприятия можно сравнить по сложности с проектированием города, где информационные системы соответствуют зданиям. Информационные системы, как и отдельные здания, требуют поддержки и правильной эксплуатации, ремонта и модернизации. Но жизненный цикл информационной системы существенно короче жизненного цикла здания.
При построении комплексной информационной системы предприятия (как правило, включающей множество различных по функциональности информационных систем или подсистем) нам необходимо иметь документированную информацию о текущем состоянии и концепцию развития наших информационных технологий в будущем.
Под архитектурой предприятия (EA - Enterprise Architecture), обычно понимается полное описание (модель) структуры предприятия, как системы, включающее описание ключевых элементов этой системы, связей между ними.
Архитектура предприятия определяет общую структуру и функции систем (бизнес и ИТ) в рамках всей организации в целом (включая партнеров и другие организации, формирующие так называемое «предприятие реального времени») и обеспечивает общую рамочную модель (framework), стандарты и руководства для архитектуры уровня отдельных проектов. Общее видение, обеспечиваемое архитектурой предприятия, создает возможность единогопроектирования систем, адекватных, с точки зрения обеспечения потребностей организации , и способных к взаимодействию и интеграции там, где это необходимо.
В основе архитектуры предприятия заложен «Архитектурный взгляд» на системы, определенный в стандарте ANSI/IEEE 1471, как «фундаментальная организация системы, состоящая из совокупности компонент, их связей между собой и внешней средой, и принципы, которыми руководствуются при их создании и развитии».
Архитектура предприятия описывает деятельность компании с двух основных позиций:
· Бизнес-архитектура описывает предприятие с позиции логических терминов, таких, как взаимодействующие бизнес-процессы и бизнес правила, необходимая информация, структура и потоки информации.
· Архитектура информационных технологий описывает предприятие с позиции технических понятий, таких как аппаратные и компьютерные средства, программное обеспечение, защита и безопасность.
Документирование и оптимизация архитектуры информационных технологий обеспечивает нам уменьшение уровня сложности информационных систем и упрощает их интеграцию. Оптимизация бизнес-процессов компании и оптимизация функциональности информационных систем, использующихся для автоматизации бизнес-процессов, увеличивает приток инвестиций в информационные технологии. Архитектура предприятия в первую очередь объединяет архитектуру информационных технологий и бизнес - архитектуру в единое целое, обеспечивая комплексный взгляд на обе существующие области (рисунок 1.1.).
Архитектура предприятия является важным критическим элементом, связывающим информационные технологии, бизнес потребности предприятия и объединяет в себе процессы стратегического бизнес – планирования, прикладные информационные системы и процессы их сопровождения.
При этом архитектура предприятия неразрывно связана с основными рабочими процессами:
· стратегия и планирование на уровне предприятия;
· управление корпоративными проектами.
Рисунок 1.1. Взаимосвязь бизнеса и ИТ
Разработка стратегии современного предприятия (StrategyandPlanning) и управление корпоративными проектами (Enterpriseprogrammanagement) включают в себя направление, связанное непосредственно с информационными технологиями. Современные тенденции рассматривают ИТ проекты и стратегические инициативы как определенный актив компании, которым можно управлять аналогично финансовым активам.
Управление портфелем информационных технологий (BusinessandITportfoliomanagement) – это процесс управления инвестициями в области управления ИТ проектами. Под портфелем понимается совокупность проектов, выполняемых на общем пуле ресурсов (финансы, люди, оборудование, материалы, энергия), при этом пул ресурсов и результаты всех проектов портфеля находятся в компетенции одного центра ответственности.
Аналитики компании METAGroup считали, что это - область пересечения архитектуры предприятия, стратегии предприятия и управления корпоративными проектами (рисунок 1.2.). Стратегия и планирование при этом обеспечивают основу для выработки ИТ стратегии предприятия, в соответствии с которыми появляются проекты внедрения (модернизации) информационных систем. Управление проектами – можно рассматривать, в первую очередь, как механизм, обеспечивающий переход от текущего состояния к планируемому, или, другими словами, переход от текущей архитектуры предприятия к целевой архитектуре.
Рисунок 1.2. Управление портфелем ИТ.
Представление информационных технологий в виде активов, позволяет предприятию корректно оценивать и расставлять приоритеты при вложении инвестиций и управлении ИТ проектами (активами) с учетом приемлемого уровня риска, и, таким образом планировать инвестиции в эту область. Считается, что управление ИТ портфелем должно преследовать три основные цели:
· максимизация ценности портфеля;
· синхронизация ИТ - портфеля с требованиями бизнеса;
· поиск оптимального баланса между риском и потенциальной отдачей от ИТ - портфеля.
Архитектура предприятия является одним из элементов управление ИТ портфелем и предоставляет необходимую информацию о бизнес-процессах и технологиях, необходимых для их автоматизации. Архитектура предприятия не только является основой для разработки портфеля активов, но также обеспечивает весь жизненный цикл многих ИТ - активов.
Архитектура предприятия позволяет увидеть все предприятие целиком. Создать цепочку, показывающую воздействие отдельных элементов стратегии развития предприятия на его бизнес-процессы, и их зависимость от информационных систем и технологических элементов.
Выделяют различные уровни абстракции архитектуры предприятия, но на каждом из них существует единый набор моделей, принципов, руководства и, которые используются для создания и развития систем в контексте деятельности всего предприятия в целом. Можно выделить следующие три уровня абстракции (рисунок 1.3.): уровень архитектуры предприятия; уровень архитектуры отдельных решений; прикладной уровень (дизайн и разработка решений).
Уровень архитектуры предприятия – описывает высокоуровневые элементы архитектуры, ориентированные на создание общей концепции развития в масштабах всего предприятия, в целом. На этом уровне рассматриваются основные цели и задачи предприятия, стратегия его развития, на основе которых разрабатывается ИТ - стратегия и высокоуровневая архитектура. Здесь определяется общая структура информационных систем в рамках всей организации, в целом, и выделяются их основные функции.
Уровень архитектуры предприятия – это в первую очередь общая схема функционирования всего предприятия в целом, дающая возможность единого проектирования информационных систем, обеспечивающих потребности всего предприятия, и их эффективную интеграцию. Построение такой схемы позволяет не только показать, какие именно бизнес-процессы, и информационные системы обеспечивают достижение основных целей предприятия, но и избежать их дублирования, повысить эффективность совместной работы.
Уровень отдельных решений – определяет структуру и функции в рамках отдельных проектах. На этом уровне, формируется детализированная информация о приложениях, бизнес-процессах и их взаимосвязях. Здесь определяется структура информационных систем, их интерфейсы и функции. Определяются планы и схемы их развития, разрабатывается соглашение об уровне обслуживания (SLA).
Архитектура уровня отдельных проектов описывает, как именно, новые информационные системы будут вписываться в контекст всего предприятия, с кем они будут взаимодействовать и какие технологии использовать.
Рисунок 1.3. Контекст и уровни абстракции архитектуры предприятия.
Прикладной уровень , включающий в себя дизайн отдельного решения и его архитектуру, планы реализации проектов. На этом уровне происходит работа уже непосредственно с информационными системами. Определяется структура и функции отдельных приложений, которые разрабатываются с целью обеспечения конкретной функциональности. Здесь происходит реализация стандартов и руководств, определенных на верхних уровнях.
Информационная система, на данном уровне рассматривается как сложный комплексный объект, динамически изменяющийся во времени. Конкретная реализация системы включает в себя экземпляры приложений и их физическое расположение, фактические потоки данных и реализацию процессов управления.
При внесении изменений в архитектуру предприятия можно использовать различные способы разделения на уровни абстракции. Это связано с тем, что каждый уровень абстракции использует свои модели, описывающие определенные предметные области. Например, при внедрении информационных технологий на предприятии принято выделять следующие уровни абстракции:
· Уровень контекста (почему?) ориентирован в первую очередь на руководство и обосновывает необходимость проектов.
· Концептуальный уровень (что?) определяет общие требования к проекту и возможные варианты его реализации.
· Логический уровень (как?) описывает способ реализации данного проекта.
· Физический уровень определяет решения, стандарты и технологии, позволяющие реализовать проект.
Количество уровней абстракции и их тип могут варьироваться в зависимости от поставленных задач. Основное достоинство уровней абстракции заключается в обеспечении возможности декомпозиции предприятия на отдельные элементы для последующего детализированного рассмотрения. Концепция разделения архитектуры предприятия на различные уровни абстракции позволяет управляющим четко видеть влияние планируемых изменений на все предприятие, в целом.
Таким образом, можно говорить, что «архитектура – это инвестиция в стандарты процессов, технологий и интерфейсов в целях улучшения возможностей организаций и уменьшения стоимости разработки и сопровождения информационных систем, а корпоративная архитектура ИТ – это видение, принципы и стандарты, которыми организации руководствуются при разработке и внедрении технологий».
Архитектура предприятия является инструментом управления, обеспечивающим процесс принятия решений об инвестициях в информационные технологии, стирающие грань между бизнесом и ИТ - подразделением.
Традиционно считается, что новые инициативы по внедрению информационных технологий должны проявляться в виде требований от бизнеса, и новые информационные системы должны отвечать именно этим требованиям. Но бизнес должен, в то же время, получать и учитывать «сигналы» от ИТ - подразделения, которое, соответственно, должно показывать новые возможности, появляющиеся у предприятия при внедрении новых ИС. Таким образом, архитектуру предприятия можно рассматривать как новый виток развития организационных принципов построения деятельности предприятия, обеспечивающий его эффективное функционирование (рисунок 1.4.).
Рисунок 1.4. Эволюция организационных принципов.
Любому предприятию требуется планомерное развитие его структуры, бизнес-процессов, информационных систем и их интеграция между собой. Архитектура предприятия собственно и является планом развития предприятия (целевая архитектура ) и документированной схемой того, что происходит в компании в текущий момент времени (текущая архитектура ).
Текущая архитектура (Current architecture) - описывает существующее состояние архитектуры предприятия. Называется также архитектурой “как есть” (AS-IS) или базовым состоянием существующей архитектуры.
Текущая архитектура – это отображение объективной реальности, включающей в себя существующие компоненты (бизнес-процессы, информационные системы, технологические элементы) и их связи. Это набор моделей с неизбежными упрощениями, ограничениями и субъективными искажениями.
Процесс разработки текущей архитектуры – это, в первую очередь, процесс документирования и поддержания информации о состоянии предприятия в актуальном виде, обеспечивающий регистрацию и контроль информации обо всех элементах архитектуры предприятия, включающий в себя ведение базы данных по архитектурным объектам; ведение управленческого учета и учета состояния.
Процесс разработки текущей архитектуры аналогичен процессу ITIL/ITSM(управление конфигурацией - Configuration Management). Для упрощения работы по разработке текущей архитектуры многие компании используют базу данных конфигурационных единиц (CMDB), дополнив ее необходимой информацией.
Целевая архитектура (Target Architecture) - описывает желаемое будущее состояние предприятия или "что должно быть сформировано" (TO-BE). Другими словами, целевая архитектура является будущей моделью предприятия.
Целевую архитектуру можно назвать идеальной моделью предприятия, в основу которой заложены:
· стратегические требования к бизнес-процессам и информационным технологиям;
· информация о выявленных «узких местах» и путях их устранения;
· анализ технологических тенденций и среды бизнес деятельности предприятия.
Целевая архитектура (модель to-be) и текущая архитектура (модельas-is) позволяют описать начальное и конечное состояние предприятия – до и после внесения изменений в его структуру, оставляя без внимания сам процесс изменений.
Процесс перехода от текущей архитектуры предприятия к целевой переводит предприятие на новую спираль развития и, таким образом, мы можем говорить, что архитектура предприятия характеризуется определенным жизненным циклом, похожим на жизненный цикл информационных систем.
Современные подходы к построению архитектуры предприятия традиционно разделяют ее на несколько слоев (предметных областей). Количество архитектурных слоев варьируется в различных методиках. Ниже мы рассмотрим слои, использующиеся в большинстве из существующих методик (рисунок 1.5.):
Рисунок 1.5. Основные слои архитектуры предприятия
· Стратегические цели и задачи предприятия.
· Бизнес – архитектура предприятия.
· Архитектура информационных технологий (ИТ архитектура предприятия).
Архитектуру информационных технологий, в свою очередь, разделяют на:
· Информационную архитектуру (Enterprise Information Architecture).
· Архитектуру прикладных решений (Enterprise Solution Architecture).
Информационные технологии и управление предприятием Баронов Владимир Владимирович
Зачем требуется понятие архитектуры
Использование понятия «архитектура предприятия» позволяет установить связь между бизнесом предприятия и параметрами информационной системы – функциями системы и интероперабельностью данных.
Основными предпосылками к использованию понятия архитектуры являются стандарты и унификация методов сбора данных
Существуют добровольные промышленные стандарты, в которых взаимосвязи различных компонентов полностью определены спецификацией интерфейсов, доступных всем. Одна из главных целей заключается в использовании заимствованных архитектурных решений, однако на начальных этапах развертывания такие решения и системы могут составлять лишь отдельную часть общего проекта. Ключевое требование состоит в том, чтобы любая информация, создаваемая в информационных системах, была полностью независима от программного обеспечения разработки. Это означает концентрацию внимания на интероперабельности данных и быстрое продвижение по пути использования Internet и Web-стандартов, языка XML, порталов, Web-сервисов, а также увеличения использования услуг провайдеров приложений. Все это ограждает пользователей от традиционных проблем по поддержке интероперабельности, которые возникают в процессе работы с различными аппаратными и программными платформами. Основным принципом руководителей подразделений информационных систем должно стать устранение использования программного обеспечения собственного изготовления. Это требование необходимо включить в текущие и будущие планы.
Стандартизация данных устраняет избыточность и гарантирует их согласованность. Это особенно важно, поскольку традиционно существующие организационные и функциональные границы, в которых ранее данные представляли независимые друг от друга острова, могут пересекаться. Поэтому принцип «однократное поступление, многократное использование» должен быть реализован в более широком контексте, чем это было ранее.
Понятие архитектуры предприятия целесообразно использовать для достижения максимума показателей «возврат инвестиций» и «эффективность/ стоимость», а также для обеспечения эффективной защиты данных. Информация об архитектуре предприятия доступна и полезна благодаря следующим аспектам:
согласованность – архитектура предприятия является компонентом стратегического планирования, гарантирующим на стратегическом уровне согласованность развития информационных технологий и стратегического развития;
межведомственное взаимодействие – архитектура предприятия содействует совместному использованию информации между разными предприятиями, а также в государственных учреждениях (например, в органах местной власти, в различных международных организациях и т. д.).
Архитектура предприятия определяет общие и наиболее распространенные потребности деятельности и идентифицирует процессы, необходимые для того, чтобы реализовать эти потребности. С ее помощью осуществляется сбор и повышение качества данных – архитектура предприятия устанавливает согласованные с пользователями методы сбора данных, что в целом сокращает затраты на этот процесс. Использование понятия архитектуры предприятия содействует распространению унифицированных способов доступа к данным, представляющим интерес для пользователей, особенно с применением Internet. Архитектура предприятия благодаря наличию общих решений может оказать помощь другим предприятиям в подготовке технологической информации по планированию процессов инвестирования. В части планирования инвестиций в информационные технологии архитектура предприятия позволяет определять и прогнозировать перспективные направления их развития и возможности использования в деятельности организации. С учетом этих сведений могут приниматься более обоснованные решения по инвестициям в информационные технологии.
Архитектура предприятия содержит схему о состоянии информационных технологий в разные периоды времени. Имея такую информацию, специалисты получают возможность быстрее реагировать на изменяющуюся ситуацию, минимизировать количество промежуточных шагов при проведении изменений, а самое главное, значительно упростить процессы переосмысливания потребностей и анализа принимаемых решений. Собранные вместе различные проекты архитектур предприятия предоставляют наиболее полную картину о них и позволяют воплощать самые передовые, например дистанционное обучение через Internet. Набор схем архитектур предприятия представляет собой пул применявшихся приемов, которые могут использоваться как исходные данные для принятия быстрых и грамотных решений по развитию и разработке информационных технологий.
Особо стоит выделить финансовые аспекты применения такого понятия, как архитектура. Сокращение затрат при использовании стандартизованной архитектуры предприятия реализуется, во-первых, благодаря типовым архитектурам и, во-вторых, за счет уменьшения необходимости начинать разработки с нуля тех решений, которые уже известны.
Перечислим другие мотивы, которые стимулируют разработку и использование архитектуры предприятия:
Приведение предприятия в соответствие с намерениями – реальное обеспечение того, что преобразованное предприятие будет соответствовать исходным требованиям;
Интеграция – реализация того, что бизнес-процедуры и правила являются непротиворечивыми, данные – защищенными, интерфейсы и потоки информации – стандартизированными, коммуникации и взаимодействие (интероперабельность) поддерживаются в пределах всего предприятия и государства;
Облегчение управления изменениями в любых аспектах предприятия:
– конвергенция – использование стандартных информационных технологий;
– улучшение связи между основными подразделениями и подразделениями информационных технологий в пределах всего предприятия на основе использования стандартизированного словаря;
– наглядное представление предприятия, которое помогает связывать и описывать большие системы и облегчает управление в сложных средах;
– ориентация на стратегическое использование современных технологий для управления большими потоками информации;
Улучшение согласованности, точности, своевременности, целостности, качества, пригодности, доступности и возможностей совместного использования общей информации;
Совершенствование процессов планирования капиталовложений и инвестиционного управления;
Появление возможностей повышения качества и гибкости используемых приложений без увеличения затрат (стандартизация);
Достижение экономии на основе совместного использования услуг в масштабах всего предприятия;
Упрощенная интеграция наследуемых, перемещаемых и новых систем.
Данный текст является ознакомительным фрагментом. Из книги Все о счетах-фактурах автора Клокова Анна Валентиновна3.4. Счет-фактуру требуется исправить В предыдущих разделах анализировались ошибки, которые допускаются при заполнении счетов-фактур и возникновение последствий при предъявлении НДС к вычету по таким счетам-фактурам. Согласно пункту 1 статьи 169 НК РФ документом, служащим
Из книги Управление дебиторской задолженностью автора Брунгильд Светлана Геннадьевна3. ЧТО ТРЕБУЕТСЯ ЗНАТЬ О КОНТРАКТАХ И ДОГОВОРАХ Надлежит законы и указы писать явно, чтоб их не перетолковывать. Правды в людях мало, а коварства много. Под них такие же подкопы чинят, как и под фортецию. Петр
Из книги Управление салоном красоты автора Шамкуть Ольга ВладимировнаЧто требуется 1. Документы о регистрации фирмы (форма собственности и устав).2. Договор аренды с регистрацией.3. Заключение СЭС.4. Заключение пожарной инспекции.5. Разрешение на деятельность от районной Управы (выдается бесплатно).6. Разрешение на торговлю сопутствующими
Из книги Новая эпоха - старые тревоги: Политическая экономия автора Ясин Евгений ГригорьевичТребуется политическая организация Итак, нужна демократия. Это сегодня уже не красивое слово, а жизненная потребность для страны. Но она должна опираться на какие-то социальные и политические силы, которые стали бы за демократию бороться. А что же наши демократы? Увы, они
Из книги Покажите мне деньги! [Полное руководство по управлению бизнесом для предпринимателя-лидера] автора Рэмси ДэйвМиф о том, что для крупной покупки требуется взять деньги в долг Билл – хороший, трудолюбивый, честный человек. У него замечательные отношения с женой, он любит своих детей, и он порядочен в вопросах, касающихся бизнеса. Он сидел со своей женой Соней за столом напротив меня.
автораОпределение архитектуры предприятия Архитектурой предприятия называются информационные составляющие, которые определяют: структуру бизнеса; информацию, которая необходима для ведения этого бизнеса; технологии, которые необходимы, чтобы поддерживать деловые
Из книги Информационные технологии и управление предприятием автора Баронов Владимир ВладимировичОписание слоев архитектуры Как отмечалось ранее, архитектура предприятия представляется с помощью такого понятия, как слои. Обычно рассматривают следующие слои: бизнес-слой; архитектура данных; интеграция физических данных; концептуальная модель/модель
Из книги Идеальный руководитель. Почему им нельзя стать и что из этого следует автора Адизес Ицхак КалдеронТребуется переводчик Проблему дополнительно усложняет то, что каждый из четырех (PAEI) – типов вкладывает разный смысл в слова «быть», «хотеть» и «требоваться» исходя из своеобразия собственной картины мира.Предприниматель, как правило, принимает решения, воспринимая
Из книги Самое главное в PR автора Олт Филип Г.Требуется: знание экономики Готовя себя к карьере специалиста по связям с общественностью, человек должен получить солидное образование в области экономики. Будучи принятым на работу в качестве профессионала, ему придется иметь дело с финансовыми аспектами
автора Джестон ДжонШаг 6. Применение архитектуры Любая организация, желающая использовать архитектуру процессов, должна наладить необходимую дисциплину. Это означает, что все соответствующие проекты должны учитывать архитектуру и выявлять, где они отклоняются от согласованных
Из книги Управление бизнес-процессами. Практическое руководство по успешной реализации проектов автора Джестон ДжонОбразец типовой архитектуры Обобщенные целевые показатели: в следующие три года обеспечить рост выручки от реализации на 200 %; обеспечить рост прибыли на 150 % в следующие три года.Общие принципы: наши корпоративные ценности: лучшая ценность за уплаченную
Из книги Теория ограничений Голдратта. Системный подход к непрерывному совершенствованию автора Детмер УильямЗачем нужно понятие «утверждение»? Для чего мы пользуемся понятием «утверждение»? Если говорится, что «пропущено какое-то утверждение», значит, в логическом дереве не упомянут некий важный элемент (причина, следствие, промежуточная цель или задача и т. д.). Используя
Из книги Истинный профессионализм автора Майстер ДэвидЧто для этого требуется? Если будет желание, то совсем не трудно создать внесенные в список преимущества. Возьмем, к примеру, совместного использования навыков и опыта в подразделении. Для этого требуется эффективно функционирующее подразделение, обладающее потенциалом
Из книги Практика и проблематика моделирования бизнес-процессов автора Всяких Е ИГлава 1 Зачем нужна модель бизнес-архитектуры: стандартные постановки задач по моделированию бизнес-процессов Во многом обоснование необходимости разработки модели бизнес-архитектуры связано с пониманием факторов, подталкивающих предприятие к поиску оптимизационных
Из книги Легко не будет [Как построить бизнес, когда вопросов больше, чем ответов] автора Хоровиц БенТребуется некоторый опыт Эти предпринимательские планы заставили вспомнить о собственном первом опыте работы с венчурными инвесторами.В 1999 году, получив первый транш финансирования для Loudcloud, мы с партнерами отправились к нашему новому инвестору – венчурному
Из книги Метод Сильвы. Искусство управления автора Сильва ХосеТребуется гений Средние способности уже недостаточны. Мы развиваемся. То, что является средним сегодня, завтра будет ниже среднего. Мы не на ярмарочной карусели, где достаточно просто держаться за медное кольцо, чтобы не упасть. Мы непрерывно движемся вперед. Происходит
Вторая статья про мифологическое сознание тоже будет короткой. Сегодня я расскажу, к каким проблемам приводит мифологическое сознание при моделировании архитектуры предприятия.
Известная модель Захмана пытается ответить на вопрос, что такое архитектура предприятия, и рассказывает о том, как она должна моделироваться. Основой этой модели являются вопросы, на которые предлагается ответить: кто, когда, где, почему и как совершает что-то над чем-то. Кажется, что это логичный фреймворк для описания архитектуры предприятия, и многие думают, что так оно и есть.
Однако, даже беглый взгляд на этот фреймворк оставляет чувство неудовлетворенности, потому что не понятно, как ответить на вопрос: кто и почему выточил деталь? Кто: Иван Иванович, или токарь, роль которого исполнял Иван Иванович? Почему: потому что токарь получил задание, или потому что Иван Иванович заключил контракт, в соответствии с которым он обязуется выполнять роль токаря в обмен на еду? Почему: потому что Иван Иванович хочет покушать, или затем, что деталь нужна в сборочном цехе?
Более глубокое изучение этого фреймворка заставляет задуматься над его применимостью к описанию технологических процессов. Например, пусть кукуруза растет в поле. Применяя модель Захмана, я должен ответить на вопросы. Кто? Кукуруза. Что делает? Растет. Почему? Потому что так устроен мир. Зачем? Да кто же его знает, зачем растет кукуруза?!
Читатель, натренированный в описании архитектур предприятий, быстро меня поправит. Он скажет, что я неправильно ставлю вопросы. Надо спрашивать: кто выращивает, почему он выращивает, что выращивает. Но тогда получается, что я могу описать деятельность субъекта, который выращивает кукурузу, но не могу описать сам рост. Смирившись с тем, что я не могу описать процесс роста, у меня все равно остаются неразрешенные вопросы: кто и почему выращивает кукурузу (см. выше)?
Получается, что, задавая вроде бы логичные вопросы, я в лучшем случае получаю несколько ответов, а в худшем, не получаю их вообще. Если взять предельный случай, когда у нас есть полностью роботизированное предприятие, на котором вообще нет людей, то ответом на вопрос «кто?» будет - «никто». В результате мы вообще ничего не можем сказать об этом предприятии! Правда, есть один выход из этой ситуации, немного лукавый, – надо лишь воспользоваться мифическим сознанием и одушевить роботов. Тогда, одушевив неодушевленное, мы сможем ответить на вопрос: кто? Робот. Почему? Потому что так устроен этот робот, или потому что программист его так запрограммировал. На второй вопрос мы снова получаем странные ответы. Почему же так получилось, и какие вопросы на самом деле стоит задавать? Я попытаюсь кратко изложить свое мнение на этот счет, рассказав о тех логических ошибках, которые я нашел в модели Захмана.
Если посмотреть на вопросы, которые задаются в модели Захмана, можно убедиться, что они в точности соответствуют теории деятельности. Деятельность – это психическая функция субъекта (группы субъектов). Поэтому, отвечая на вопросы Захмана, мы строим модель психической функции субъекта (субъектов). Наука, изучающая психические функции субъектов, называется психология. Получается, что Захман отвечает на вопросы, которыми задаются психологи: зачем субъект делает то или иное действие? Или как мотивировать субъекта на выполнение тех или иных действий? Эти вопросы, безусловно, интересные и важные, но являются ли ответы на них описанием архитектуры предприятия? Чтобы ответить на этот вопрос, надо понять, что же такое предприятие?
Как же на самом деле происходит проектирование предприятия и какие артефакты при этом возникают? Прежде чем проектировать предприятие, строится модель требований к нему. Модель требований формируется на основе требований, которые предъявлены к этому предприятию со стороны всех его участников, контрагентов и стейкхолдеров. Аналог в ИТ - требования к программному продукту. Далее на основе этих требований строится модель процессов предприятия с необходимой степенью детализации. Аналогом в ИТ будет перечень функций программного продукта. Далее строится модель функциональных объектов, или, говоря специализированным языком, технических мест, которые должны участвовать в перечисленных ранее процессах. Аналогом в ИТ будет описание процедур, и объяснение какие процедуры в каких функциях участвуют. Далее подбираются те единицы оборудования, которые могут выполнять роли перечисленных технических мест. Аналог в ИТ - это программный код.
Предприятие – это функциональный объект, который создан удовлетворяющим определенным требованиям. В этом смысле предприятие ничем не отличается от такого объекта, как часы, или производственная линия. Часто вместо термина функциональный объект можно услышать термин техническое место. Техническое место отличается от единицы оборудования тем, что единица оборудования выполняет роль технического места. Например, трансформатор выполняет роль преобразователя напряжения, при этом в разное время разные трансформаторы могут выполнять роль одного и того же преобразователя. Еще одним примером технического места является должность, отдел, подразделение, штат. Например, токарь участвует в функции изготовления деталей. Это - техническое место, роль которого в разное время могут выполнять разные единицы оборудования (физические лица). О сложностях моделирования технических мест и единиц оборудования я кратко написал в статье .
При моделировании технических мест, мы описываем процессы и участников этих процессов. Замечу, что именно участников, а не исполнителей, - трансформатор не может преобразовывать напряжение, потому что он не является одушевленным существом. Об этом я писал в прошлой статье . Если все же сказать, что трансформатор «преобразует» напряжение, то это – метонимия, которая раскрывается так: трансформатор, исполняет роль преобразователя напряжения, который (преобразователь) участвует в процессе преобразования напряжения. О метонимии можно прочитать в книге «Метафоры, которыми мы живем», авторы: Джордж Лакофф, Марк Джонсон. Другой распространенной метонимией будет высказывание: «компьютер решает задачи». Те же, кто действительно считают, что трансформатор, или компьютер что-то делает на самом деле, одушевляют неодушевленное, пользуясь мифическим сознанием.
Заметим, что до сего момента мы ни слова не сказали о целях, об исполнителях и причинно-следственных связях. Мы лишь говорили о требованиях, о функциях и участниках этих функций – технических местах. Цели остались на этапе формирования требований к предприятию и далее они не пошли. Мы можем знать эти цели, а можем не знать, - для модели предприятия это не имеет никакого значения. Модель предприятия отвечает на вопрос: как мы удовлетворяем требования, а не то, откуда взялись эти требования. Исполнителей тоже нет, потому что нам не надо пользоваться теорией деятельности, чтобы описать участников активности. Мы не строим причинно-следственные связи. Если же надо построить модель причинно-следственных связей, то это еще одна дополнительная модель. Это знания, которыми пользуются технологи при проектировании предприятия, и я не видел, чтобы кто-то строил такие модели. Это - отраслевые знания, и учат им в институтах по много лет. Смоделировать, почему летит самолет – нереально трудно, и никто этого не делает. Просто моделируют полет самолета.
Итак, модель Захмана не включает в себя требования к предприятию, включает в себя модель процессов, но довольно специфическим способом - с указанием на исполнителей процесса, которых, как я уже сказал можно найти только в теории деятельности, и не разделяет модель технических мест и модель единиц оборудования.
Как я сказал ранее, модель Захмана скорее про деятельность. При этом было бы неплохо, если бы модель Захмана использовалась по назначению, - как способ описания деятельности. Это давало бы возможность анализировать мотивы и заинтересованность людей в их работе, но беда в том, что эта модель используется неверно. Например, на вопрос «почему токарь точит деталь?» можно получить ответ: «она нужна в сборочном цехе». Но необходимость ее в сборочном цехе не отвечает на вопрос, почему токарь точит деталь. Ответ был не на поставленный вопрос, а на какой-то другой. Например, для такого ответа правильным был бы вопрос: в каком процессе, или в какой операции должна участвовать выточенная деталь? Или на каком рабочем месте она нужна? Вы видите, что это совсем не вопрос «почему?». Кроме того, меня сильно смущает наделение Захманом компьютера или информационной системы способностью что-то делать. Скорее всего, он не одушевляет их, но использует метонимию в моделировании, что на мой взгляд, недопустимо.
Правильными вопросами будут: Какие существуют требования к предприятию? Какие процессы протекают на предприятии? Какие технические места в каких процессах участвуют? Какие единицы оборудования выполняют роли каких технических мест и когда?
Собственно, все. С наступающим, и до новых встреч!
1. Архитектурное описание предприятия: как сделать видимой организацию работ
Архитектура предприятия -- это то, как оно организовано. Как организовано (архитектура) -- это кто над чем работает, и кому эта работа нужна. Предприятие всегда как-то организовано, хорошо или плохо. Организация (архитектура) предприятия невидима, но можно сделать вполне видимое архитектурное описание. Если есть архитектурное описание, то можно его использовать для обсуждения организации предприятия всеми заинтересованными в этой организации сторонами (включая компетентных в вопросах организации людей) -- и тогда есть шанс, что организацию удастся улучшить. Если документированного на каком-нибудь отчуждаемом из головы носителе информации архитектурного описания нет, то каждый имеет какое-то (не спрашивайте, какое) описание в каком-то (не спрашивайте, в каком) виде в собственной голове, и даже в ходе одного разговора это описание может у одного человека меняться три-четыре раза. При обсуждении организации работ предприятия у всех гарантированно будут разные представления о договоренностях, а результат работ по таким договоренностям описан в басне Крылова про лебедя, рака и щуку.
Архитектурное описание состоит из ряда диаграмм, по которым люди водят пальчиком, чтобы понять устройство организации и затем договориться, что нужно в организации поменять. Архитектурное описание прежде всего -- это инструмент для заключения договорок важных людей (заинтересованных сторон) по поводу важных аспектов организации работ. Не нужно путать организационные регламенты (в которых написано и важное, и не очень важное, и вообще много слов) с архитектурным описанием, в котором есть только самое-самое важное, зато выраженное максимально формально с целью избежать ошибок.
Для описания архитектуры предприятия используется специальный язык Архимейт. Этот язык позволяет записать самое важное, что есть в организации предприятия -- и проигнорировать мелкие детали.
Сразу оговоримся, что в Архимейте можно описывать только организацию работ для офисного планктона. Никаких объектов реального материального производства в Архимейте описать нельзя, описывается только информация об этих объектах. Никакой варки картофеля, никаких переносов чушки со станка на станок -- только и исключительно информация обо всём этом. Архимейт идеален для банков и страховых компаний, штаб-квартир (из которых реальных цехов не видно), проектных бюро (где тяжёлые балки есть только в компьютерных моделях и бумажных распечатках) и даже штабов строек (где занимаются раздачей поручений и учётом сделанного, но сами руками ничего не делают). А вот те части предприятия, которые занимаются не учётом закручивания гаек, но реально закручивают ржавые гайки, получив их со склада, описать Архимейтом нельзя. Зато складской учёт изобразить, или проектирование и учёт работ -- пожалуйста.
Архитектор -- это тот, кто придумывает такую архитектуру, которая удовлетворит все заинтересованные стороны. Эту архитектуру он придумывает, описывает в виде Архимейт-диаграмм, и согласовывает её с разными важными людьми. Сам момент описания архитектуры на Архимейте неважен. Те, кто просто пишут на Архимейте (испанском, суахили) под диктовку, не могут называться архитекторами, они просто писари (писцы). Ну ладно, архиписари (архиписцы).
Для многих людей, назначенных архитекторами, оказывается полной неожиданностью неминуемый переход от изображения на Архимейте результатов разных интервью в качестве "архитектурного описания as is" к сочинению "архитектурного описания to be" и немедленно следующему плотному общению с начальством по поводу превращения свежесочиненных диаграмм Архимейта в организационную реальность предприятия. Архимейт поможет вам в вашем деле не больше, чем спеллчекер Ворда в получении нобелевской премии по литературе.
Вы предупреждены.
2. Люди, программы, оборудование
Самым-самым важным в предприятии Архимейт считает наличие трёх уровней работ , на каждом из которых уменьшается человеческое начало: людей , программ и оборудования . Люди без программ беспомощны, программы без оборудования мертвы. Оборудование без работы программ -- бесполезный кусок железа, программы без работы людей тоже не нужны. Так что в архитектуре предприятия обязаны быть представлены все три уровня выполнения работ в их взаимосвязи.
На каждом уровне есть свои выполнители работ , и свои объекты работ работы. Собственно, работа заключается в том, что выполнители изменяют как-то объекты работ. Выполнители работ и объекты работ обычно представлены существительными, работы -- глаголами и отглагольными существительными. Важно, что объекты работ сами ничего выполнять не умеют, они пассивны. А вот выполнители активны, они-то и трудятся над объектами и с использованием объектов.
Уровень людей содержательный. Люди за информацией видят те объекты окружающего мира, которые эта информация изображает. Смотрят на прогноз погоды и видят завтрашнюю погоду (а не описание погоды), смотрят на отчёт о стройке и видят количество реальных этажей (а не собственно отчёт), смотрят на отчёт о прибылях и убытках и видят ту самую прибыль. У людей есть цели, полномочия (могут выдавать некоторым другим людям поручения на выполнение работ) и ответственность (должны обещать, что выполнят поручения некоторых других людей). Целенаправленная деятельность есть только на этом уровне.
Уровень программ -- это обработка информации, заключенной в данных. Из одних данных программы делают другие данные, отличающиеся как форматом, так и содержанием. Никто никому ничего не обещает (обещать программы не могут, это могут только люди) и не даёт поручений (поручать могут только люди), не преследует никаких целей (цели есть только у людей). На этом уровне известно, что означают данные в реальном мире: ведь опасно к килограммам прибавлять километры. Главная задача уровня программ -- чтобы нужным способом обработанные данные оказались в нужный момент у нужных людей.
Уровень оборудования -- это бездушный мир, в котором никакой обработки данных уже нет, а есть только хранение и пересылка данных. Конечно, на уровне оборудования тоже есть программы, но они уже другого рода -- тут уже никто не знает, что означают эти данные в реальном мире. Задача оборудования -- хранить адресуемые как-то байты, не вдаваясь в их смысл, пересылать эти байты по запросам программ, а также хранить сами программы и давать им возможность выполняться.
3. Элементы и отношения
Предприятие в Архимейте описывается в виде элементов (изображаются разными фигурами), находящихся друг с другом в каких-то отношениях (отношения изображаются в виде соединительных линий между фигурками элементов). Архимейт ценен тем, что предлагает для описания работы предприятия всего
-- 16 типов элементов для уровня людей,
-- 7 типов элементов для уровня программ,
-- 9 типов элементов для уровня оборудования,
-- 11 типов отношений, в которых элементы могут находиться друг с другом, и показ развилок для этих отношений.
Если вы собираетесь как-то менять архитектуру предприятия в реальной жизни (а иначе зачем вы вообще стали рисовать диаграммы Архимейта?), то для этого можно использовать ещё:
-- 7 типов элементов для целеполагания и обоснования изменений в организации
-- 4 типа элементов для проектирования перехода к новой архитектуре
Еще есть комментарий и отношение связи комментария с какими-то другими элементами, а также рамочка для группировки элементов.
Вот и весь Архимейт. Но не нужно обольщаться его простотой. В Великом и Могучем тоже всего 33 буквы.
4. Нужен не ты, нужен твой сервис.
Важно, что никакие работы на предприятии не делаются просто так, они все кому-то зачем-то нужны. Сервисы -- это полезные для каких-то других выполнителей (точнее, полезные для работ этих выполнителей) работы. Для потребителей сервисов абсолютно неважно, как организовано выполнение этих работ: кто с чем работает, чтобы выставить сервис для внешнего потребления. Для них важно только, по каким каналам (электронная почта, окошечко с девушкой, телефонный звонок и т.д.) и интерфейсам (если это программы) будут предоставлены эти сервисы.
Есть сервисы оборудования, предоставляемые программам, и сервисы программ, предоставляемые людям. Три уровня предприятия склеены именно этими сервисами -- из каждого уровня главным образом видны только сервисы других уровней.
То есть можно заменить всё оборудование, и программы этого не заметят, если сервисы оборудования остались прежними. Так же и с программами: замени их все, но если сервисы останутся теми же, то люди это вполне переживут. В принципе, это относится и к самому предприятию: если сервисы людей, которые предприятие оказывает окружающему миру (а объединение таких сервисов и связывающего их контракта называется продуктом ) будут выполняться совсем по-другому организованными людьми, которые пользуются совсем другими программами, которые работают на совсем другом оборудовании, то клиенты этого не заметят. Этим и пользуются архитекторы предприятия: они описывают предприятие, а потом потихоньку меняют программы и оборудование, поддерживая предоставление критически важных сервисов. Это и называется сервис-ориентированным подходом: разделять (разные уровни работы сервисами) и властвовать. Так что это ещё как посмотреть: предприятие склеено сервисами, а для архитектора оно этими сервисами разделено.
Стремление разделять и властвовать у архитекторов так велико, что они разделяют сервисами и работы даже одного и того же уровня. Например, легко представить себе программы, оказывающие сервис не людям, а другим программам. Или оборудование, смысл существования которого -- служить (оказывать сервис, т.е. "работать для") другому оборудованию.
Для предоставления внешне видимой работы-сервиса нужно выполнить много-много извне невидимой внутренней работы -- изменения объектов работы выполнителями работ. Наличие этой границы внутреннего и внешнего рассмотрения ("черного ящика" с невидимыми внутренними выполнителями, работами и объектами против "прозрачного ящика", когда они отлично видны) -- это наличие границы системы . Архимейт моделирует системы , разделяя части/уровни предприятия сервисами (хотя про "системы" в спецификации Архимейта и не сказано ни слова).
5. Люди
Напомним пункт три: для описания уровня организации работы людей Архимейт имеет столько же типов элементов (17), сколько для уровней программ и оборудования вместе взятых (7+9) -- и это совсем не случайно.
Сами люди в Архимейте представлены не своими личностями. В Архимейте не человек красит место, а место красит человека. В Архимейте выполнителем является живой человек, но только занимающий организационное место. Поэтому Архимейт "людьми" называет эти самые места, кто бы их в данный момент ни заполнял -- один человек, целая группа людей из организационного звена (от сектора и отдела до филиала в другом государстве или даже всей компании целиком), временные работники, случайные граждане-клиенты, партнерские фирмы. Архимейт понимает, что это все эти оргместа занимают живые люди, но называет этих людей именно по наименованиям оргмест. Разнорабочий, зам.нач.отдела доставки, отдел доставки, филиал в Мытищах, клиент, аудитор -- это и есть "люди", кто бы ни были те сотрудники, которым доведется занимать эти организационные позиции. Архитектор, как водится, заботится о вечном: если разнорабочий или президент заболели, и один человек подменил другого на время болезни, диаграмма останется верна: организация труда не изменится.
Люди Архимейта более разнообразны, чем те люди, которых можно найти в "оргструктуре" (органиграмме): отнюдь не все отношения между людьми Архимейта сводятся к начальствованию-подчинению. Так, партнеры и клиенты обычно в оргструктуре не упоминаются, а в Архимейте их показ -- обычное дело.
6. Роли
Архитекторы настолько коварны, что работают и с частями людей, называя их "роли". Ролью называется та выделенная во времени часть людей, которая выполняет определенный ряд работ, требующих какой-то особой квалификации. Так, если разнорабочий в театре вынужден то петь, то танцевать, у него есть две роли: когда он поёт, то роль -- певец, а когда танцует -- роль танцор.
Люди назначаются на роли, а роли назначаются на работы. Особо нужно отметить факт, что архитекторы организации занимаются организацией работ, а не лидерством (leadership). Распределение людей по ролям, а ролей по работам -- это забота архитектора организации. А забота лидера -- это а) назначение на места "людей" живых "человеков" с фамилиями, именами и отчествами, вредными и полезными привычками, определенными умениями и б) убалтывание кнутом и пряником человеков на местах "людей" выполнять назначенные им работы. Так что фамилий на диаграммах Архимейта не увидишь: только должности, роли, подразделения, фирмы, "люди при исполнении", "представители", коллегиальные органы, временные группы и объединения и т.д..
В жизни назначение на роли и на работы обычно отражается приказами, распоряжениями, положениями и прочими "распорядительными документами". Такая система дробления людей нужна не только, чтобы показать многогранность занятий людей (напомню: и отдельных людей, и целых подразделений -- когда большая компания из 1000 сотрудников выступает как в роли поставщика по отношению к одним фирмам, так и в роли заказчика по отношению к другим фирмам), но и чтобы свои диаграммы архитекторы меняли поменьше, а устанавливающие организацию работ приказы издавались пореже.
Типичный пример: в организации начинают заниматься посадкой петрушки, но пока непонятно, кто будет эту петрушку сажать -- начальство говорит, "вы покажите, что там нужно будет делать, а я уж тогда назначу подходящую кандидатуру". Пишут "Положение о петрушке", где вводят роль "главного по петрушке" и "старшего по петрушке" и прописывают все их работы. Заметим, что Положение -- это еще не приказ, и не распоряжение. Это констатация факта, что какие-то организационные места (главного и старшего по петрушке) нужно заполнить, чтобы работы (по посадке петрушки) пошли. Начальник изучает этот проект положения, и заключает, что посадкой петрушки у него должны заниматься инженеры и юристы. Далее он пишет приказ, в котором он а) утверждает положение и б) прописывает, что роль главного по петрушке будет занимать инженер, а старшего по петрушке -- юрист. Вот как это выглядит:
Соединительные линии с точечками -- это и есть "отношение назначения" между элементами. Отношения есть, конечно, и между людьми и работами непосредственно (если опустить упоминание роли). Такое отношение будет называться производным, но оно всё равно есть -- можно говорить, что в данном случае инженер назначен на обеспечение всходов, а юрист на пригляд за посадкой.
Обратите внимание, что эта конструкция будет работать, даже когда инженер Иванов уйдёт на пенсию, а вместо него на это место будет принят Сидоров. В этой конструкции легко поменять инженера на агронома, или на Дирекцию по петрушке (когда деятельность разрастётся) -- этот механизм назначения ролей на работы (например, Положением), а людей на роли (например, Распоряжением) работает и в случае, когда "люди" -- это целая толпа людей, т.п. речь идет об организационном звене. Все эти Положения и Приказы на диаграмме обычно не отмечаются: на диаграммах договариваются, как будут организованы работы, а не какими документами эти договоры будут оформлены.
Подсказка: я знаю несколько организаций, где альбомы архитектурных описаний предприятия утверждались директором вместо толстой пачки регламентов. Ибо архитектурные диаграммы оказывались точнее и выразительнее многочисленных текстовых описаний, которые потом пытались по ним составить.
Понятно, что на посадке петрушки в конечном итоге работают самые живые Иванов и Сидоров (или сотрудники, которые числятся в Дирекции по петрушке). Но на предприятие они будут тратить только часть своего времени и талантов (и только эта часть времени отражается элементом "люди" в архитектуре предприятия), а остальное время спать, есть, гулять, учиться и развлекаться. На их роль в работах по посадке петрушки они будут тратить только часть времени, которое потратят на предприятие -- ибо у них наверняка много разных ролей, они выполняют много разных работ. Да и на одну и ту же роль вполне могут быть назначено и некоторое количество людей -- отдельных человек или даже несколько подразделений.
И людей, и ролей можно дробить на любое число частей, если нужно показать какие-то детали занятости людей-выполнителей.
Для выполнения какой-то работы разные люди могут на время объединиться (это обычно никак не отражается в оргструктуре), и такое временное объединение называют коллегиальной ролью .
7. Работы людей
Работы людей бывают такие:
- уже случившиеся -- события . Называют обычно события глаголом совершенной формы прошедшего времени: "петрушка посажена". Эти работы могут быть выполнены непреднамеренно ("случилась ошибка"), людьми не из предприятия (клиентами, конкурентами, партнёрами), да и не вообще эта работа могла быть выполнена не людьми (а, например, программами, оборудованием, или даже силами природы -- "солнце зашло").
- направленные на достижение результата, и исполняемые в развертке времени (часто -- друг за дружкой) --процессы. Их называют глаголом в неопределенной форме -- "копать", "посадить", "разработать". Процессы обычно запускаются событием, и запускают события, а также запускают друг друга, образуя цепочку от начального события до события-результата.
- полученные в результате работы временного коллектива, объединённого коллегиальной ролью -- коллегиальные процессы. Их тоже называют глаголом в неопределенной форме.
- отобранные по какому-то иному, чем развертка во времени для получения результата (например, требующие назначения на них ролей с определенной квалификацией или потребляющие какой-то специфичный вид ресурсов) -- практики . Практики не столько сами выполняются, сколько в разные моменты выполняются те или иные объединённые ими процессы (или фрагменты процессов, до которых дело на диаграмме так и не дошло, поэтому их изобразили без развертки во времени, чохом, "в мешке" -- то есть обозначили "что практикуется", а не указали на выполнение в какое-то определенное время). Поэтому практики обозначаются не глаголами, а отглагольными существительными: "посадка петрушки" это именно практика.
- предоставляемые кому-то вовне работы, как они значимы и видятся снаружи -- сервисы . Сервисы реализованы внутренними работами, выполняемыми внутренними ролями, и используется в ходе внешних работ, выполняемых внешними ролями. В принципе, любые работы людей выполняются только для того, чтобыреализовать какой-то сервис -- то есть для того, чтобы кто-то другой (например, клиент, или смежники) смогли воспользоваться этими работами.
В принципе, все предприятие разбито на какие-то части, и эти части выставляют наружу (для других частей предприятия, или за границы предприятия, или для другого уровня) сервисы, чтобы оправдать своё существование. Если есть трудности в понимании, кто в каких работах использует те или иные сервисы, или какие сервисы реализуют те или иные работы -- значит, вы что-то не знаете, или не продумали.
Для уточнения того, чем же именно ценен сервис, в Архимейте даже есть специальный элемент: внешняя польза , которая связана с сервисом.
* * *
В принципе, уже видно, что рассказ в таких терминах вполне получается -- он не выглядит слишком абстрактным и заумен ровно в той мере, в какой заумен сам Архимейт. Дальше можно уже не писать новые тексты из серии "Архимейт по-русски", а просто подкорректировать ранее написанные. Ну, и продолжить локализацию программы. 1. Архитектурное описание предприятия: как сделать видимой организацию работ
Архитектура предприятия -- это то, как оно организовано. Как организовано (архитектура) -- это кто над чем работает (кто за что ответственный ), и кому эта работа нужна. Предприятие всегда как-то организовано, хорошо или плохо. Организация (архитектура) предприятия невидима (она -- "логический объект"), но можно сделать вполне видимое архитектурное описание. Если есть архитектурное описание, то можно его использовать для обсуждения организации предприятия всеми заинтересованными в этой организации сторонами (включая компетентных в вопросах организации людей) -- и тогда есть шанс, что организацию удастся улучшить. Если документированного на каком-нибудь отчуждаемом из головы носителе информации архитектурного описания нет, то каждый имеет какое-то (не спрашивайте, какое) описание в каком-то (не спрашивайте, в каком) виде в собственной голове, и даже в ходе одного разговора это описание может у одного человека меняться три-четыре раза. При обсуждении организации работ предприятия у всех гарантированно будут разные представления о договоренностях, а результат работ по таким договоренностям описан в басне Крылова про лебедя, рака и щуку. Даже если договорились об "оргструктуре" (единственное, что обычно документируют при таких разговорах), это только маленький кусочек того, о чём правильно было бы договариваться.
Архитектурное описание состоит из ряда диаграмм, по которым люди водят пальчиком, чтобы понять устройство организации и затем договориться, что нужно в организации поменять. Архитектурное описание прежде всего -- это инструмент для заключения договорок важных людей (заинтересованных сторон -- стейкхолдеров ) по поводу важных аспектов организации работ, затрагивающих интересы этих стейкхолдеров. Не нужно путать организационные регламенты (в которых написано и важное, и не очень важное, и вообще много слов) с архитектурным описанием, в котором есть только самое-самое важное (то, что если изменить -- то нужно будет менять и много чего остального), зато выраженное максимально формально с целью избежать ошибок.
Для описания архитектуры предприятия используется специальный язык Архимейт. Этот язык позволяет записать самое важное, что есть в организации предприятия -- и проигнорировать мелкие детали.
Сразу оговоримся, что в Архимейте можно описывать только организацию работ для офисного планктона. Никаких объектов реального материального производства в Архимейте описать нельзя, описывается только информация об этих объектах. Никакой варки картофеля, никаких переносов чушки со станка на станок -- только и исключительно информация обо всём этом. Архимейт идеален для банков и страховых компаний, штаб-квартир (из которых реальных цехов не видно), проектных бюро (где тяжёлые балки есть только в компьютерных моделях и бумажных распечатках) и даже штабов строек (где занимаются раздачей поручений и учётом сделанного, но сами руками ничего не делают). А вот те части предприятия, которые занимаются не учётом закручивания гаек, но реально закручивают ржавые гайки, получив их со склада, описать Архимейтом нельзя. Зато складской учёт изобразить, или проектирование и учёт работ -- пожалуйста.
Архитектор -- это тот, кто придумывает такую достигающую поставленные цели архитектуру, которая удовлетворит все заинтересованные стороны, всех стейкхолдеров. Эту архитектуру он придумывает, описывает в виде Архимейт-диаграмм, и согласовывает её с разными важными людьми. Сам момент описания архитектуры на Архимейте неважен. Те, кто просто пишут на Архимейте (испанском, суахили) под диктовку, не могут называться архитекторами, они просто писари (писцы). Ну ладно, архиписари (архиписцы). Архитекторы -- это те, кто придумывает что записывать про организацию, а не как это выразить в Архимейте хитрыми значками.
Для многих людей, назначенных архитекторами (особенно для тех, кто пришёл "из программистов" или "из сисадминов"), оказывается полной неожиданностью неминуемый переход от изображения на Архимейте результатов разных интервью в качестве "архитектурного описания as is" к сочинению "архитектурного описания to be" и немедленно следующему плотному общению с начальством по поводу превращения свежесочиненных диаграмм Архимейта в организационную реальность предприятия. Архимейт поможет вам в вашем деле не больше, чем спеллчекер и умение управляться со стилями Ворда в получении нобелевской премии по литературе.
Вы предупреждены.
2. Деятельность, "софт", "железо"
Самым-самым важным в предприятии Архимейт считает наличие трёх уровней работ , на каждом из которых уменьшается человеческое начало: деятельности , "софта" и "железа" . Деятельность без "софта" архаична и беспомощна, "софт" без "железа" мёртв. "Железо" без работы программ -- бесполезное железо, а программы без использования их в деятельности людей тоже никому не нужны. Так что в архитектуре предприятия обязаны быть представлены все три уровня выполнения работ в их взаимосвязи.
На каждом уровне есть свои выполнители работ , и свои объекты работ. Собственно, работа заключается в том, что выполнители изменяют как-то объекты работ. Выполнители работ и объекты работ обычно представлены существительными, работы -- глаголами и отглагольными существительными. Важно, что объекты работ сами ничего выполнять не умеют, они пассивны. А вот выполнители активны, они-то и трудятся над объектами. "Кто-то" (выполнитель работы) что-то делает (работа) с чем-то (объект работы).
Уровень деятельности содержательный. Люди за информацией видят те объекты окружающего мира, которые эта информация изображает. Смотрят на прогноз погоды и видят завтрашнюю погоду (а не описание погоды, на которое они смотрят), смотрят на отчёт о стройке и видят количество реальных этажей (а не собственно отчёт, на который они смотрят), смотрят на отчёт о прибылях и убытках и видят ту самую прибыль (не обращая внимания, отчёт этот на экране или на бумаге). У людей есть интересы и цели, они могут быть ответственными (должны обещать, что выполнять некоторые поручения других людей), у них есть полномочия (могут выдавать некоторым другим людям поручения на выполнение работ). Целенаправленная деятельность, удовлетворяющая интересам и целям каких-то людей-стейкхолдеров, есть только на этом уровне.
Уровень "софта" -- это обработка информации, заключенной в данных. Из одних данных программы делают другие данные, отличающиеся как форматом, так и содержанием. Никто никому ничего не обещает (обещать программы не могут, это могут только люди в их деятельности) и не даёт поручений (поручать могут только люди). На этом уровне известно, что означают данные в реальном мире: ведь опасно к килограммам прибавлять километры. Главная задача уровня программ -- чтобы нужным способом обработанные данные оказались в нужный момент у нужных ответственных, выполняющих какую-то роль в предприятии.
Уровень "железа" -- это бездушный мир, в котором никакой обработки данных уже нет, а есть только хранение и пересылка данных. Конечно, на уровне "железа" тоже есть программы (системный софт), но они уже другого рода -- тут уже никто не знает, что означают эти данные в реальном мире. Задача "железа", как и любого оборудования -- хранить адресуемые как-то байты, не вдаваясь в их смысл, пересылать эти байты по запросам прикладных программ, а также хранить сами программы и давать им возможность выполняться.
3. Элементы и отношения
Предприятие в Архимейте описывается в виде элементов (изображаются разными значками), находящихся друг с другом в каких-то отношениях (разные отношения изображаются в виде по-разному рисуемых соединительных линий между значками элементов). Архимейт ценен тем, что предлагает для описания работы предприятия всего
-- 16 типов элементов для уровня деятельности,
-- 7 типов элементов для уровня программ,
-- 9 типов элементов для уровня оборудования,
-- 11 типов отношений, в которых элементы могут находиться друг с другом, и показ развилок (вида "и" и "или") для этих отношений.
Если вы собираетесь как-то менять предприятие в реальной жизни (а иначе зачем вы вообще стали рисовать диаграммы Архимейта, отражающие его архитектуру?), то для этого можно использовать ещё:
-- 7 типов элементов для целеполагания и обоснования изменений в организации
-- 4 типа элементов для проектирования перехода к новой архитектуре
Еще есть комментарий и отношение связи комментария с какими-то другими элементами, а также рамочка для группировки элементов.
Вот и весь Архимейт, 54 понятия. Но не нужно обольщаться его простотой. В Великом и Могучем тоже всего 33 буквы.
4. Нужен не ты, нужен твой сервис.
Важно, что никакие работы на предприятии не делаются просто так, они все кому-то зачем-то нужны. Сервисы -- это полезные для каких-то других выполнителей (точнее, полезные для работ этих выполнителей) работы, видимые "снаружи" какого-то куска предприятия. Для потребителей сервисов абсолютно неважно, как организовано выполнение этих работ: кто с чем работает, чтобы выставить сервис для внешнего потребления. Для них важно только, по каким каналам (электронная почта, окошечко с девушкой, телефонный звонок и т.д. вели это деятельность) и интерфейсам (если это "софт") будут предоставлены эти сервисы.
Есть сервисы "железа", предоставляемые "софту", и программные сервисы, предоставляемые деятельности. Три уровня предприятия склеены именно этими сервисами -- из каждого уровня главным образом видны только сервисы других уровней. Можно просто не показывать ничего, кроме сервиса: именно сервисы позволяют абстрагироваться от подробностей устройства предприятия, именно сервисы реализуют системный подход и делят всю систему на части. Современные архитектуры сервис-ориентированы.
Эти части системы одновременно функциональны (назначение сервиса -- выполнить какую-то функцию по отношению к использующей его системе, сервисы -- это то, как работы выглядят "извне" подсистемы) и модульны (то есть взаимозаменяемы, если сохраняется функция). Так, можно заменить всё "железо", и "софт" этого не заметит, если сервисы "железа" остались прежними. Так же и с "софтом": замени его хоть весь, но если программные сервисы останутся теми же, то деятельность это не заметит -- все те же функции софта будут доступны в деятельности. В принципе, это относится и к самому предприятию: если оргсервисы, которые предприятие оказывает окружающему миру (а объединение таких оргсервисов и связывающего их соглашения об уровне обслуживания называется оргсервис-продуктом ) будут выполняться совсем по-другому организованной деятельностью, которая пользуется совсем другим "софтом", который в свою очередь работает на совсем другом "железе", то клиенты этого не заметят. Этим и пользуются архитекторы предприятия: они описывают предприятие, а потом потихоньку меняют деятельность, "софт" и "железо", поддерживая предоставление критически важных сервисов. Это и называется сервис-ориентированным подходом: разделять (разные уровни работы сервисами) и властвовать. Предприятие склеено сервисами, а для архитектора оно этими сервисами разделено .
Стремление разделять и властвовать у архитекторов так велико, что они разделяют сервисами и работы даже одного и того же уровня. Например, легко представить себе программы, оказывающие сервис не людям, а другим программам. Или "железо", смысл существования которого -- служить (оказывать сервис, т.е. "работать для") другому оборудованию.
Для предоставления внешне видимой работы-сервиса нужно выполнить много-много извне невидимой внутренней работы -- изменения объектов работы выполнителями работ. Наличие этой границы внутреннего и внешнего рассмотрения ("черного ящика" с невидимыми внутренними выполнителями, работами и объектами против "прозрачного ящика", когда они отлично видны) -- это наличие границы системы . Архимейт моделирует системы , разделяя части/уровни предприятия сервисами (хотя про "системы" в спецификации Архимейта и не сказано явно ни слова, только намёки).
