Зачем нужна архитектура предприятия. IT для бизнеса: Что владельцу нужно знать про описание архитектуры компании

Мы уже отмечали, что нет единственно правильного определения того, что такое архитектура предприятия. Различные консалтинговые компании, индустриальные ассоциации, профессиональные объединения используют несколько отличающиеся друг от друга концепции и методики для описания этого понятия. Более того, эти концепции и методики находятся в процессе постоянного изменения, поэтому попытка дать точное описание того, что такое архитектура предприятия, отражающее сегодняшние представления, является "стрельбой по движущейся цели".

Вообще говоря, при разработке и использовании архитектуры предприятия, конечно же, целесообразно придерживаться какой-либо одной методики, которая обеспечивала бы единство в подходах и соответствующие наборы инструментов для описания архитектуры. Мы кратко рассмотрим наиболее известные методики в "Методики описания архитектур. Модели Захмана и Gartner, методики META Group и TOGAF" и "NASCIO. Модели "4+1" и SAM. Методики Microsoft и другие. Выбор "оптимальной" методики" . Здесь же мы детализируем наше общее представление о понятии " архитектура предприятия".

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

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

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

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

Архитектура предприятия – это скорее процесс, чем некоторый статический предмет. Мы не будем говорить, что ее создание – это легкая веселая прогулка. Но тем не менее, это может быть притягательным и в каком-то смысле завораживающим занятием. Архитектура предприятия не является простым предметом, но в последующем изложении мы постараемся его сделать менее "устрашающим и приводящим в уныние". Существующие уже сегодня методики описания архитектуры предприятия позволяют организовать соответствующий процесс при наличии даже минимального количества первоначальной информации в интуитивной и естественной манере. При этом полнота описания архитектуры может наращиваться постепенно, по мере того как растет понимание объекта описания архитектуры – структуры и функций предприятия, а также обеспечивающих информационных технологиях.

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

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

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

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

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

• использование для анализа множества точек зрения на объект изучения (предприятие и его информационные системы) для того, чтобы "разделять и властвовать" в процессе борьбы с объективной сложностью реального мира. Важно понимать, что ни одна отдельно взятая точка зрения не является достаточной для понимания всего целого;
• для того чтобы обеспечить процесс синтеза, все модели, которые включены в архитектуру, связываются с другими моделями. Они являются либо более детальной декомпозицией, либо связанными между собой представлениями. Это богатство взаимосвязей между моделями напрямую определяет качество архитектуры.

Итак, прежде чем продолжить, приведем еще одно определение архитектуры предприятия, которое дано на сайте www.geao.org "Всемирной Организации Корпоративной Архитектуры" (GEAO – Global Enterprise Architecture Organization):

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

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

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

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

1. Архитектурное описание предприятия: как сделать видимой организацию работ

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

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

Для описания архитектуры предприятия используется специальный язык Архимейт. Этот язык позволяет записать самое важное, что есть в организации предприятия -- и проигнорировать мелкие детали.

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

Архитектор -- это тот, кто придумывает такую архитектуру, которая удовлетворит все заинтересованные стороны. Эту архитектуру он придумывает, описывает в виде Архимейт-диаграмм, и согласовывает её с разными важными людьми. Сам момент описания архитектуры на Архимейте неважен. Те, кто просто пишут на Архимейте (испанском, суахили) под диктовку, не могут называться архитекторами, они просто писари (писцы). Ну ладно, архиписари (архиписцы).

Для многих людей, назначенных архитекторами, оказывается полной неожиданностью неминуемый переход от изображения на Архимейте результатов разных интервью в качестве "архитектурного описания as is" к сочинению "архитектурного описания to be" и немедленно следующему плотному общению с начальством по поводу превращения свежесочиненных диаграмм Архимейта в организационную реальность предприятия. Архимейт поможет вам в вашем деле не больше, чем спеллчекер Ворда в получении нобелевской премии по литературе.

Вы предупреждены.

2. Люди, программы, оборудование

Самым-самым важным в предприятии Архимейт считает наличие трёх уровней работ , на каждом из которых уменьшается человеческое начало: людей , программ и оборудования . Люди без программ беспомощны, программы без оборудования мертвы. Оборудование без работы программ -- бесполезный кусок железа, программы без работы людей тоже не нужны. Так что в архитектуре предприятия обязаны быть представлены все три уровня выполнения работ в их взаимосвязи.

На каждом уровне есть свои выполнители работ , и свои объекты работ работы. Собственно, работа заключается в том, что выполнители изменяют как-то объекты работ. Выполнители работ и объекты работ обычно представлены существительными, работы -- глаголами и отглагольными существительными. Важно, что объекты работ сами ничего выполнять не умеют, они пассивны. А вот выполнители активны, они-то и трудятся над объектами и с использованием объектов.

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

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

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

3. Элементы и отношения
Предприятие в Архимейте описывается в виде элементов (изображаются разными фигурами), находящихся друг с другом в каких-то отношениях (отношения изображаются в виде соединительных линий между фигурками элементов). Архимейт ценен тем, что предлагает для описания работы предприятия всего
-- 16 типов элементов для уровня людей,
-- 7 типов элементов для уровня программ,
-- 9 типов элементов для уровня оборудования,
-- 11 типов отношений, в которых элементы могут находиться друг с другом, и показ развилок для этих отношений.

Если вы собираетесь как-то менять архитектуру предприятия в реальной жизни (а иначе зачем вы вообще стали рисовать диаграммы Архимейта?), то для этого можно использовать ещё:
-- 7 типов элементов для целеполагания и обоснования изменений в организации
-- 4 типа элементов для проектирования перехода к новой архитектуре

Еще есть комментарий и отношение связи комментария с какими-то другими элементами, а также рамочка для группировки элементов.

Вот и весь Архимейт. Но не нужно обольщаться его простотой. В Великом и Могучем тоже всего 33 буквы.

4. Нужен не ты, нужен твой сервис.

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

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

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

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

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

5. Люди

Напомним пункт три: для описания уровня организации работы людей Архимейт имеет столько же типов элементов (17), сколько для уровней программ и оборудования вместе взятых (7+9) -- и это совсем не случайно.

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

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

6. Роли

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

Люди назначаются на роли, а роли назначаются на работы. Особо нужно отметить факт, что архитекторы организации занимаются организацией работ, а не лидерством (leadership). Распределение людей по ролям, а ролей по работам -- это забота архитектора организации. А забота лидера -- это а) назначение на места "людей" живых "человеков" с фамилиями, именами и отчествами, вредными и полезными привычками, определенными умениями и б) убалтывание кнутом и пряником человеков на местах "людей" выполнять назначенные им работы. Так что фамилий на диаграммах Архимейта не увидишь: только должности, роли, подразделения, фирмы, "люди при исполнении", "представители", коллегиальные органы, временные группы и объединения и т.д..

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

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

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

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

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

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

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

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

7. Работы людей

Работы людей бывают такие:

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


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

Архитектура предприятия -- это то, как оно организовано. Как организовано (архитектура) -- это кто над чем работает (кто за что ответственный ), и кому эта работа нужна. Предприятие всегда как-то организовано, хорошо или плохо. Организация (архитектура) предприятия невидима (она -- "логический объект"), но можно сделать вполне видимое архитектурное описание. Если есть архитектурное описание, то можно его использовать для обсуждения организации предприятия всеми заинтересованными в этой организации сторонами (включая компетентных в вопросах организации людей) -- и тогда есть шанс, что организацию удастся улучшить. Если документированного на каком-нибудь отчуждаемом из головы носителе информации архитектурного описания нет, то каждый имеет какое-то (не спрашивайте, какое) описание в каком-то (не спрашивайте, в каком) виде в собственной голове, и даже в ходе одного разговора это описание может у одного человека меняться три-четыре раза. При обсуждении организации работ предприятия у всех гарантированно будут разные представления о договоренностях, а результат работ по таким договоренностям описан в басне Крылова про лебедя, рака и щуку. Даже если договорились об "оргструктуре" (единственное, что обычно документируют при таких разговорах), это только маленький кусочек того, о чём правильно было бы договариваться.

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

Для описания архитектуры предприятия используется специальный язык Архимейт. Этот язык позволяет записать самое важное, что есть в организации предприятия -- и проигнорировать мелкие детали.

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

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

Для многих людей, назначенных архитекторами (особенно для тех, кто пришёл "из программистов" или "из сисадминов"), оказывается полной неожиданностью неминуемый переход от изображения на Архимейте результатов разных интервью в качестве "архитектурного описания as is" к сочинению "архитектурного описания to be" и немедленно следующему плотному общению с начальством по поводу превращения свежесочиненных диаграмм Архимейта в организационную реальность предприятия. Архимейт поможет вам в вашем деле не больше, чем спеллчекер и умение управляться со стилями Ворда в получении нобелевской премии по литературе.

Вы предупреждены.

2. Деятельность, "софт", "железо"

Самым-самым важным в предприятии Архимейт считает наличие трёх уровней работ , на каждом из которых уменьшается человеческое начало: деятельности , "софта" и "железа" . Деятельность без "софта" архаична и беспомощна, "софт" без "железа" мёртв. "Железо" без работы программ -- бесполезное железо, а программы без использования их в деятельности людей тоже никому не нужны. Так что в архитектуре предприятия обязаны быть представлены все три уровня выполнения работ в их взаимосвязи.

На каждом уровне есть свои выполнители работ , и свои объекты работ. Собственно, работа заключается в том, что выполнители изменяют как-то объекты работ. Выполнители работ и объекты работ обычно представлены существительными, работы -- глаголами и отглагольными существительными. Важно, что объекты работ сами ничего выполнять не умеют, они пассивны. А вот выполнители активны, они-то и трудятся над объектами. "Кто-то" (выполнитель работы) что-то делает (работа) с чем-то (объект работы).

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

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

Уровень "железа" -- это бездушный мир, в котором никакой обработки данных уже нет, а есть только хранение и пересылка данных. Конечно, на уровне "железа" тоже есть программы (системный софт), но они уже другого рода -- тут уже никто не знает, что означают эти данные в реальном мире. Задача "железа", как и любого оборудования -- хранить адресуемые как-то байты, не вдаваясь в их смысл, пересылать эти байты по запросам прикладных программ, а также хранить сами программы и давать им возможность выполняться.

3. Элементы и отношения
Предприятие в Архимейте описывается в виде элементов (изображаются разными значками), находящихся друг с другом в каких-то отношениях (разные отношения изображаются в виде по-разному рисуемых соединительных линий между значками элементов). Архимейт ценен тем, что предлагает для описания работы предприятия всего
-- 16 типов элементов для уровня деятельности,
-- 7 типов элементов для уровня программ,
-- 9 типов элементов для уровня оборудования,
-- 11 типов отношений, в которых элементы могут находиться друг с другом, и показ развилок (вида "и" и "или") для этих отношений.

Если вы собираетесь как-то менять предприятие в реальной жизни (а иначе зачем вы вообще стали рисовать диаграммы Архимейта, отражающие его архитектуру?), то для этого можно использовать ещё:
-- 7 типов элементов для целеполагания и обоснования изменений в организации
-- 4 типа элементов для проектирования перехода к новой архитектуре

Еще есть комментарий и отношение связи комментария с какими-то другими элементами, а также рамочка для группировки элементов.

Вот и весь Архимейт, 54 понятия. Но не нужно обольщаться его простотой. В Великом и Могучем тоже всего 33 буквы.

4. Нужен не ты, нужен твой сервис.

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

Есть сервисы "железа", предоставляемые "софту", и программные сервисы, предоставляемые деятельности. Три уровня предприятия склеены именно этими сервисами -- из каждого уровня главным образом видны только сервисы других уровней. Можно просто не показывать ничего, кроме сервиса: именно сервисы позволяют абстрагироваться от подробностей устройства предприятия, именно сервисы реализуют системный подход и делят всю систему на части. Современные архитектуры сервис-ориентированы.

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

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

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

Современные информационные технологии (ИТ) становятся неотъемлемой составляющей любого предприятия. Сегодня они для многих предприятий - не просто способ автоматизации рутинныхопераций (технологическая подложка), а эффективный инструмент в конкурентной борьбе. Современные ИТ – системы призваны быстро адаптироваться к новым потребностям бизнеса (его целям задачам) и полностью соответствовать архитектуре предприятия (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).

Программное обеспечение TSF вне ядра состоит из доверяемых приложений, которые используются, чтобы реализовать функции безопасности. Обратите внимание на то, что совместно используемые библиотеки, включая модули PAM в некоторых случаях, используются доверяемыми приложениями. Однако, не существует экземпляра, где сама совместно используемая библиотека рассматривается как доверяемый объект. Доверяемые команды могут быть сгруппированы следующим образом.

• Системная инициализация
• Идентификация и аутентификация
• Сетевые приложения
• Пакетная обработка
• Управление системой
• Аудит пользовательского уровня
• Криптографическая поддержка
• Поддержка виртуальной машины

Компоненты исполнения ядра могут быть разделены на три составляющие части: основное ядро, потоки ядра и модули ядра, в зависимости от того, как они будут выполняться.

• Основное ядро включает код, который выполняется, чтобы предоставить услугу, такую как обслуживание системного вызова пользователя или обслуживание события исключения, или прерывание. Большинство скомпилированного кода ядра подпадает под эту категорию.
• Потоки ядра. Чтобы выполнить определенные стандартные задачи, такие как очистка дисковых кэшей или освобождение памяти, путем выгрузки неиспользованных страничных блоков, ядро создает внутренние процессы или потоки. Потоки запланированы точно так же, как обычные процессы, но у них нет контекста в непривилегированном режиме. Потоки ядра выполняют определенные функции языка C ядра. Потоки ядра размещены в пространстве ядра, и работают только в привилегированном режиме.
• Модуль ядра и модуль ядра драйверов устройств — фрагменты кода, которые могут быть загружены и выгружены в и из ядра по мере необходимости. Они расширяют функциональные возможности ядра без необходимости перезагружать систему. После загрузки объектный код модуля ядра может получить доступ к другому коду ядра и данным таким же образом, как статически скомпонованный код объекта ядра.

Ядро состоит из логических подсистем, которые обеспечивают различные функциональные возможности. Даже при том, что ядро — единственная исполняемая программа, различные сервисы, которые оно предоставляет, могут быть разделены и объединены в разные логические компоненты. Эти компоненты взаимодействуют, чтобы обеспечить определенные функции. Ядро состоит из следующих логических подсистем:

• Файловая подсистема и подсистема ввода-вывода : Эта подсистема реализует функции, связанные с объектами файловой системы. Реализованные функции включают те, которые позволяют процессу создавать, поддерживать, взаимодействовать и удалять объекты файловой системы. К этим объектам относятся регулярные файлы, каталоги, символьные ссылки, жесткие ссылки, файлы, специфичные для определенных типов устройств, именованные каналы и сокеты.
• Подсистема процессов : Эта подсистема реализует функции, связанные с управлением процессами и управлением потоками. Реализованные функции позволяют создавать, планировать, исполнять и удалять процессы и субъекты потоков.
• Подсистема памяти : Эта подсистема реализует функции, связанные с управлением ресурсами памяти системы. Реализованные функции включают в себя те, которые создают и управляют виртуальной памятью, включая управление алгоритмами разбивки на страницы и таблицами страниц.
• Сетевая подсистема : Эта подсистема реализует сокеты UNIX и Интернет-домена, а также алгоритмы, используемые для планирования сетевых пакетов.
• Подсистема IPC : Эта подсистема реализует функции, связанные с механизмами IPC. Реализованные функции включают в себя те, которые упрощают управляемый обмен информацией между процессами, позволяя им совместно использовать данные и синхронизировать их выполнение при взаимодействии с общим ресурсом.
• Подсистема модулей ядра : Эта подсистема реализует инфраструктуру, позволяющую поддерживать загружаемые модули. Реализованные функции включают загрузку, инициализацию и выгрузку модулей ядра.
• Расширения безопасности Linux : Расширения безопасности Linux реализуют различные аспекты безопасности, которые обеспечиваются для всего ядра, включая каркас Модуля безопасности Linux (Linux Security Module, LSM). Каркас LSM служит основой для модулей, позволяющей реализовать различные политики безопасности, включая SELinux. SELinux — важная логическая подсистема. Эта подсистема реализует функции мандатного управления доступом, чтобы добиться доступа между всеми предметами и объектами.
• Подсистема драйвера устройства : Эта подсистема реализует поддержку различных аппаратных и программных устройств через общий, не зависящий от устройств интерфейс.
• Подсистема аудита : Эта подсистема реализует функции, связанные с записью критических по отношению к безопасности событий в системе. Реализованные функции включают в себя те, которые захватывают каждый системный вызов, чтобы записать критические по отношению к безопасности события и те, которые реализуют набор и запись контрольных данных.
• Подсистема KVM : Эта подсистема реализует сопровождение жизненного цикла виртуальной машины. Она выполняет завершение инструкции, используемое для инструкций, требующих только небольших проверок. Для любого другого завершения инструкции KVM вызывает компонент пространства пользователя QEMU.
• Крипто API : Эта подсистема предоставляет внутреннюю по отношению к ядру криптографическую библиотеку для всех компонентов ядра. Она обеспечивает криптографические примитивы для вызывающих сторон.

Ядро — это основная часть операционной системы. Оно взаимодействует непосредственно с аппаратными средствами, реализует совместное использование ресурсов, предоставляет общие сервисы для приложений, и предотвращает прямой доступ приложений к аппаратно-зависимым функциям. К числу сервисов, предоставляемых ядром, относятся:

1. У правление выполнением процессов, включая операции их создания, завершения или приостановки и межпроцессоного обмена данными. Они включают:

• Равнозначное планирование процессов для выполнения на ЦП.
• Разделение процессов в ЦП с использованием режима разделения по времени.
• Выполнение процесса в ЦП.
• Приостановка ядра по истечениии отведенного ему кванта времени.
• Выделение времени ядра для выполнения другого процесса.
• Перепланирование времени ядра для выполнения приостановленного процесса.
• Управление метаданными, связанными с безопасностью процесса, такими как идентификаторы UID, GID, метки SELinux, идентификаторы функциональных возможностей.

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

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

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