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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Более глубокое изучение этого фреймворка заставляет задуматься над его применимостью к описанию технологических процессов. Например, пусть кукуруза растет в поле. Применяя модель Захмана, я должен ответить на вопросы. Кто? Кукуруза. Что делает? Растет. Почему? Потому что так устроен мир. Зачем? Да кто же его знает, зачем растет кукуруза?!

Читатель, натренированный в описании архитектур предприятий, быстро меня поправит. Он скажет, что я неправильно ставлю вопросы. Надо спрашивать: кто выращивает, почему он выращивает, что выращивает. Но тогда получается, что я могу описать деятельность субъекта, который выращивает кукурузу, но не могу описать сам рост. Смирившись с тем, что я не могу описать процесс роста, у меня все равно остаются неразрешенные вопросы: кто и почему выращивает кукурузу (см. выше)?

Получается, что, задавая вроде бы логичные вопросы, я в лучшем случае получаю несколько ответов, а в худшем, не получаю их вообще. Если взять предельный случай, когда у нас есть полностью роботизированное предприятие, на котором вообще нет людей, то ответом на вопрос «кто?» будет - «никто». В результате мы вообще ничего не можем сказать об этом предприятии! Правда, есть один выход из этой ситуации, немного лукавый, – надо лишь воспользоваться мифическим сознанием и одушевить роботов. Тогда, одушевив неодушевленное, мы сможем ответить на вопрос: кто? Робот. Почему? Потому что так устроен этот робот, или потому что программист его так запрограммировал. На второй вопрос мы снова получаем странные ответы. Почему же так получилось, и какие вопросы на самом деле стоит задавать? Я попытаюсь кратко изложить свое мнение на этот счет, рассказав о тех логических ошибках, которые я нашел в модели Захмана.

Если посмотреть на вопросы, которые задаются в модели Захмана, можно убедиться, что они в точности соответствуют теории деятельности. Деятельность – это психическая функция субъекта (группы субъектов). Поэтому, отвечая на вопросы Захмана, мы строим модель психической функции субъекта (субъектов). Наука, изучающая психические функции субъектов, называется психология. Получается, что Захман отвечает на вопросы, которыми задаются психологи: зачем субъект делает то или иное действие? Или как мотивировать субъекта на выполнение тех или иных действий? Эти вопросы, безусловно, интересные и важные, но являются ли ответы на них описанием архитектуры предприятия? Чтобы ответить на этот вопрос, надо понять, что же такое предприятие?

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

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

При моделировании технических мест, мы описываем процессы и участников этих процессов. Замечу, что именно участников, а не исполнителей, - трансформатор не может преобразовывать напряжение, потому что он не является одушевленным существом. Об этом я писал в прошлой статье . Если все же сказать, что трансформатор «преобразует» напряжение, то это – метонимия, которая раскрывается так: трансформатор, исполняет роль преобразователя напряжения, который (преобразователь) участвует в процессе преобразования напряжения. О метонимии можно прочитать в книге «Метафоры, которыми мы живем», авторы: Джордж Лакофф, Марк Джонсон. Другой распространенной метонимией будет высказывание: «компьютер решает задачи». Те же, кто действительно считают, что трансформатор, или компьютер что-то делает на самом деле, одушевляют неодушевленное, пользуясь мифическим сознанием.

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

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

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

Правильными вопросами будут: Какие существуют требования к предприятию? Какие процессы протекают на предприятии? Какие технические места в каких процессах участвуют? Какие единицы оборудования выполняют роли каких технических мест и когда?

Собственно, все. С наступающим, и до новых встреч!

Кому и зачем нужна «Архитектура предприятия»?

Copyright © 2009 Забегалин Е.В.

1 Современное состояние архитектурных методологий и практик

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

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

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

«Enterprise Architecture», по-русски «Архитектура предприятия» (АП), сложилась в общую дисциплину как ступень исторического развития множества методологий, относящихся к архитектуре автоматизированных информационных систем - это методологии Дж. Захмана, Ст. Спивака, CIMOSA, GERAM, TOGAF и др. Анализ этого исторического процесса достаточно содержательно представлен в .

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

The Zachman Framework for Enterprise Architecture ;

стандарт ISO 19439:2006 «Enterprise integration - Framework for enterprise modelling»;

стандарт ISO 15704:2000. Industrial automation systems - Requirements for enterprise-reference architectures and methodologies;

«Federal Enterprise Architecture» (FEA), практикуемая и развиваемая правительством США ;

«Extended Enterprise Architecture Framework» (E2AF), развиваемая независимой организацией «Institute For Enterprise Architecture Developments» ;

The Open Group Architecture Framework (TOGAF) .

Наряду с этим в России в 2000 году была разработана и опубликована концептуальная архитектурная схема «3D-Предприятия», в которой матричные идеи Дж. Захмана были дополнены третьим – временным – измерением для отражения трансформации структуры предприятия .

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

Рисунок 1 - У руководителей и аналитиков есть практическая необходимость всегда иметь достаточно содержательные знания об устройстве организации (предприятия)

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

В интересах практического приложения дисциплины АП преодоление указанной искусственности может быть начато с поиска ответа на вопрос: кому и зачем на предприятии может быть нужна «Архитектура предприятия»?

2 Назначение «Архитектуры предприятия»

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

Этот вывод следует из того, что все указанные на схеме объекты менеджмента являются одновременно объектами для отражения в модели АП, которая в будущем станет также объектом менеджмента (архитектурная модель предприятия показана на схеме как его компонент).

Рисунок 2 - Обобщенная структура предприятия

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

Рисунок 3 - «Архитектура предприятия» может быть использована для поддержки основных функций менеджмента

Из роли АП, как инструмента менеджмента, могут быть выведены, по меньшей мере, две основные функции «Архитектуры предприятия»:

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

в контуре стратегического управления предприятием - это формализация и предоставление

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

Рисунок 4 - Основные функции «Архитектуры предприятия»

АП может использоваться с этими функциями на всех уровнях менеджмента: от уровня руководства предприятия до цехового уровня. Это (явно, либо неявно) предусматривается известными методологиями -

"Zachman Framework for Enterprise Architecture", "Extended Enterprise Architecture Framework", "TOGAF",

"GERAM", стандартом ISO 19439-2006 (уровни "Generic", "Partial", "Particular").

После Дж. Захмана наиболее конкретно и последовательно управленческие уровни использования АП предложены в схеме «3D-Предприятия» - «Главные потребности, цели, планы, ограничения», «Бизнес-модель», «Логическая модель», «Техническая архитектура», «Детальная реализация», «Практика использования» .

3 Состав «Архитектуры предприятия»

Все архитектурные методологии сходятся в том, что для достаточно содержательного описания устройства предприятия (организации) необходимо использовать множество различных точек зрения (views) на это устройство. Эти точки зрения могут называться также архитектурными доменами, содержательными аспектами и т.п. Описание (и моделирование) структуры предприятия во множестве различных точек зрения и дает в итоге «Архитектуру предприятия».

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

в Zachman Framework for Enterprise Architecture - это "Data", "Function", "Network", "People", "Time", "Motivation";

в Extended Enterprise Architecture Framework (E2AF) - это "Business", "Information", "Information

Systems", "Technology Infrastructure";

в GERAM и в ISO 19439-2006 - это "Function", "Information", "Resource", "Organization";

в TOGAF - это "Business", "Information", "Application", "Technology".

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

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

1) Строительный аспект - предприятие строится из множества различных физических и информационных компонентов, в числе которых: основные средства и другое имущество, потребляемая и производимая энергия, персонал, бумажные документы, электронная информация, средства автоматизации и автоматического управления, то есть - это те «строительные кирпичи», из которых физически складывается предприятие. К этому аспекту можно применить также термин-синоним - конструкционный аспект.

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

3) Логический аспект - деятельность предприятия носит целенаправленный характер, в соответствии с целями предприятия определяются его строительная и функциональная структуры. Этот аспект выделяет бизнессмысл создания и деятельности предприятия.

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

В «Матрице Захмана» этот аспект обозначается наименованием первой строки "Scope" ("The purpose of the Row 1 are to define the boundaries of the Enterprise, what is being included …" ).

В Federal Enterprise Architecture (FEA) - это "Performance Reference Model".

В E2AF и в GERAM логический аспект в явном виде не выделен и включен в аспект "Business". Однако в основных принципах E2AF утверждается: "No strategy, no enterprise architecture ... No Scope - No enterprise architecture

The Scope and the Goals & Objectives sets the level of abstraction of the enterprise architecture ... Business Drivers, Goals & Objectives are leading ..." .

В TOGAF логическому аспекту соответствует "Architecture Vision" ("... key elements of the "Architecture Vision" - ...

enterprise mission, vision, strategy, and goals ..., include architecture principles, define breadth of coverage of enterprise, the specific architecture domains …" ).

Подводя итог обзору логического аспекта и пользуясь философским языком, можно утверждать необходимость логического аспекта структуры предприятия для представления "Интегральной идеи предприятия", "Интегрального замысла предприятия", "Интегрального понятия предприятия", по-английски можно предложить - "The Notion of the Enterprise".

4) Хронологический аспект - предприятие создается, функционирует и изменяется с течением времени. Прошедшие, текущее и планируемые структурные состояния предприятия должны фиксироваться, т. е. - это «История жизни».

В GERAM, в ISO 15704-2000, ISO 19439-2006 для структурирования временного аспекта предложено множество стадий жизненного цикла: "Identification", "Concept", "Requirements", "Design", "Implementation", "Operation", "Decommission".

В методологии TOGAF - Architecture Development Method (ADM) - временной аспект отражается последовательностью стадий разработки, внедрения и изменения самой «Архитектуры предприятия».

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

Рисунок 5 - Основные точки зрения на структуру предприятия

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

Компонентами строительной архитектуры предприятия могут рассматриваться:

организационная архитектура - это организационная структура предприятия;

имущественная архитектура - это структура собственности предприятия;

информационная архитектура - это структура множества документов (организационных, регламентных, технических и др.) и информационных баз данных предприятия;

производственно-технологическая архитектура - это структура производственных и энергетических мощностей предприятия, а также структура комплексов КИПиА и комплексов средств автоматизации.

К компонентам функциональной архитектуры предприятия могут быть отнесены:

структура функциональных систем и подсистем предприятия;

структура бизнес-функций и бизнес-процессов предприятия;

структуры потоков материалов и информации на предприятии.

Рисунок 6 - Комплексное представление «Архитектуры предприятия»

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

ИТ-архитектура - это структура множества автоматизированных информационных систем (информационных технологий) предприятия;

Бизнес-архитектура - это архитектура предприятия, рассматриваемая без его ИТ-архитектуры.

4 Как получить и использовать «Архитектуру предприятия»

Менеджмент предприятия может получить АП двумя путями: первый - это разработать АП силами штатных сотрудников предприятия, второй - обратиться к внешним консультантам.

Первый путь потребует от менеджмента предприятия:

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

выбора и приобретения готовой специализированной компьютерной программы для электронного моделирования АП и обучения специалистов предприятия ее пользованию;

самостоятельной разработки и документирования методического обеспечения АП;

самостоятельной разработки АП.

Разработка АП внешними консультантами потребует от менеджмента предприятия заключения контракта на выполнение работ:

по непосредственной разработке АП;

по разработке и документированию методического обеспечения АП;

по созданию архитектурной службы предприятия.

Существующие на рынке компьютерной программы электронного моделирования бизнес-процессов и структур систем позволяют конвертировать базы электронных моделей из их специализированных форматов в www-формат и затем публиковать их на внутреннем (интранет) сайте предприятия. Это позволяет реализовать

удобный и не требующий лицензирования доступ менеджеров и специалистов предприятия к электронной модели АП.

Впоследствии сформированная и подготовленная архитектурная служба предприятия может самостоятельно решать задачи по моделированию вариантов будущего состояния АП в интересах принятия менеджментом стратегических решений по развитию предприятия.

Список использованных источников

1. Зиндер Е. «3D-предприятие» – модель стратегии трансформирующейся системы. «Директор информационной службы», №4, 2000. http://www.sept2000.ru/articles/2008/03/03/1/ .

2. Зиндер Е. Архитектура предприятия в контексте бизнес-реинжиниринга. «Intelligent Enterprise/Корпоративные системы», №4, №7, 2008.

3. Галактионов В. Системная архитектура и ее место в архитектуре предприятия. «Директор информационной службы», №5, 2002.

4. Данилин А., Слюсаренко А. Архитектура и стратегия. «Инь» и «Янь» информационных технологий предприятия. М. Интернет-Университет Информационных технологий, 2005.

5. Дрожжинов В., Штрик А. Стандартизация архитектуры государственных ведомств США. PC Week/RE. №28, №31, 2005.

6. Zachman John A. The Zachman Framework. http://www.zachmaninternational.com/

7. The Office of Management and Budget. Federal Enterprise Architecture (FEA). http://www.whitehouse.gov/omb/e-gov/fea/

8. Schekkerman J. Extended Enterprise Architecture Framework Essentials Guide. Institute For Enterprise Architecture Developments, 2006. http://www.enterprise-architecture.info/

9. The Open Group Architecture Framework (TOGAF). http://www.opengroup.org/architecture/togaf8doc/arch/toc.html

10. Generalized Enterprise Reference Architecture and Methodology (GERAM). IFIP–IFAC, 1999.

11. Иванова И.А. Менеджмент: Учебное пособие. - М.: Издательство РИОР, 2004.

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

Сталкиваясь с технологическими новинками, бизнес в лице владельца решает две задачи:

• Что может дать технологическая новинка бизнесу?
• Как и когда (при каких условиях) следует ее использовать?

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

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

Концепция архитектуры систем проста. Архитектура – это взаимосвязь структур, описывающих объект. Структура, в свою очередь, – это взаимосвязь однородных элементов, составляющих объект. Так что архитектура есть у каждого предприятия. Другими словами, АП – это писаные и неписаные правила появления, изменения, удаления и взаимодействия составляющих элементов предприятия. Получается, что и описание АП есть практически у каждого предприятия. За исключением, естественно, «неписаных правил». В чем же тогда особенный интерес к использованию IT для описания АП именно сейчас? Назову три особенности:

1) Компьютерные технологии сами по себе стали элементами АП. Их много и связей между ними достаточно много;

2) Компьютерные технологии связаны со многими другими элементами АП;

3) Изменяются компьютерные технологии очень быстро, следовательно – быстро изменяется и АП.

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

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

По мере усложнения бизнеса все больше менеджеров попадает под определение пользователей АП, а их решения и ошибки становятся все дороже.

Как формировать описание архитектуры предприятия

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

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

• Инициировать работы по описанию АП: назначить ответственного исполнителя или создать подразделение. Открыть проект, установить сроки, выделить ресурсы, выбрать инструментарий (программное обеспечение).
• Определить элементы, их характеристики и взаимосвязи для включения в описание АП.
• Определить источники данных для описания элементов архитектуры и регламент их предоставления.
• Выгрузить, очистить и агрегировать отобранные данные в хранилище.
• Визуализировать описание архитектуры.

Этапы №2-5 повторяются регулярно.

Циклы формирования описания архитектуры предприятия

Ключевым в этом процессе является этап №1, на котором создается и пересматривается общая модель описания АП. То есть выделяются элементы, их характеристики и связи, данные о которых будут собираться, а также формируются правила, по которым их можно выявить, что говорится, в «реальной жизни».

Все элементы АП описать невозможно, да и не нужно. В каждом цикле следует в первую очередь выбирать те элементы АП, информацию о которых вы считаете недостаточной. Большую помощь в выборе элементов может оказать знакомство с многочисленными моделями и методологиями построения архитектуры предприятия: TOGAF, Модель Захмана, DoDAF и другими.

1) Не пытайтесь сразу описать сложные элементы архитектуры полностью. Выбранная модель представления АП должна позволять фиксировать неполноту описания. Например, лучше не оставлять значения описываемых элементов пустыми. Если какая-то из характеристик отсутствует – просто указывайте «N/A» (not applicable). Если значение характеристики необходимо выяснить – пишите «TBD» (to be defined). Можете расширить эту классификацию собственными категориями: «будет выявлено на этапе Х», «неважно на настоящий момент», «полное описание см. в системе Y» и т. п. Когда вы понимаете, какой именно информацией не располагаете и тем более почему – это тоже информация для принятия решений.

2) Отделите описание АП от ее проектирования (разработки). Описание АП – это документирование всех осуществленных изменений на предприятии согласно решениям, положенным в основу модели. Проектирование АП – подготовка любых изменений на предприятия. Эти две активности используют разные методы. Общее у них только документирование. Технически, можно объединить в общем описании АП и описание «как есть» (as is) и описания «как будет» (to be). Но необходимо учитывать, что это разные задачи, разные компетенции, разные проекты.

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

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

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

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

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

7) Начинайте задумываться об описании АП тогда, когда почувствуете неуверенность в правильной расстановке приоритетов своих задач.

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

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

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

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

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

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

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

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

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

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

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

2. Выделение оперативной памяти для исполняемого процесса. Данная операция включает в себя:

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

3. Обслуживание жизненного цикла виртуальных машин, которое включает:

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

4. Обслуживание файловой системы. Это включает в себя:

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

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