Зачем нужно описывать архитектуру предприятия. Понятие архитектуры предприятия
1. Архитектурное описание предприятия: как сделать видимой организацию работ
Архитектура предприятия -- это то, как оно организовано. Как организовано (архитектура) -- это кто над чем работает, и кому эта работа нужна. Предприятие всегда как-то организовано, хорошо или плохо. Организация (архитектура) предприятия невидима, но можно сделать вполне видимое архитектурное описание. Если есть архитектурное описание, то можно его использовать для обсуждения организации предприятия всеми заинтересованными в этой организации сторонами (включая компетентных в вопросах организации людей) -- и тогда есть шанс, что организацию удастся улучшить. Если документированного на каком-нибудь отчуждаемом из головы носителе информации архитектурного описания нет, то каждый имеет какое-то (не спрашивайте, какое) описание в каком-то (не спрашивайте, в каком) виде в собственной голове, и даже в ходе одного разговора это описание может у одного человека меняться три-четыре раза. При обсуждении организации работ предприятия у всех гарантированно будут разные представления о договоренностях, а результат работ по таким договоренностям описан в басне Крылова про лебедя, рака и щуку.
Архитектурное описание состоит из ряда диаграмм, по которым люди водят пальчиком, чтобы понять устройство организации и затем договориться, что нужно в организации поменять. Архитектурное описание прежде всего -- это инструмент для заключения договорок важных людей (заинтересованных сторон) по поводу важных аспектов организации работ. Не нужно путать организационные регламенты (в которых написано и важное, и не очень важное, и вообще много слов) с архитектурным описанием, в котором есть только самое-самое важное, зато выраженное максимально формально с целью избежать ошибок.
Для описания архитектуры предприятия используется специальный язык Архимейт. Этот язык позволяет записать самое важное, что есть в организации предприятия -- и проигнорировать мелкие детали.
Сразу оговоримся, что в Архимейте можно описывать только организацию работ для офисного планктона. Никаких объектов реального материального производства в Архимейте описать нельзя, описывается только информация об этих объектах. Никакой варки картофеля, никаких переносов чушки со станка на станок -- только и исключительно информация обо всём этом. Архимейт идеален для банков и страховых компаний, штаб-квартир (из которых реальных цехов не видно), проектных бюро (где тяжёлые балки есть только в компьютерных моделях и бумажных распечатках) и даже штабов строек (где занимаются раздачей поручений и учётом сделанного, но сами руками ничего не делают). А вот те части предприятия, которые занимаются не учётом закручивания гаек, но реально закручивают ржавые гайки, получив их со склада, описать Архимейтом нельзя. Зато складской учёт изобразить, или проектирование и учёт работ -- пожалуйста.
Архитектор -- это тот, кто придумывает такую архитектуру, которая удовлетворит все заинтересованные стороны. Эту архитектуру он придумывает, описывает в виде Архимейт-диаграмм, и согласовывает её с разными важными людьми. Сам момент описания архитектуры на Архимейте неважен. Те, кто просто пишут на Архимейте (испанском, суахили) под диктовку, не могут называться архитекторами, они просто писари (писцы). Ну ладно, архиписари (архиписцы).
Для многих людей, назначенных архитекторами, оказывается полной неожиданностью неминуемый переход от изображения на Архимейте результатов разных интервью в качестве "архитектурного описания as is" к сочинению "архитектурного описания to be" и немедленно следующему плотному общению с начальством по поводу превращения свежесочиненных диаграмм Архимейта в организационную реальность предприятия. Архимейт поможет вам в вашем деле не больше, чем спеллчекер Ворда в получении нобелевской премии по литературе.
Вы предупреждены.
2. Люди, программы, оборудование
Самым-самым важным в предприятии Архимейт считает наличие трёх уровней работ , на каждом из которых уменьшается человеческое начало: людей , программ и оборудования . Люди без программ беспомощны, программы без оборудования мертвы. Оборудование без работы программ -- бесполезный кусок железа, программы без работы людей тоже не нужны. Так что в архитектуре предприятия обязаны быть представлены все три уровня выполнения работ в их взаимосвязи.
На каждом уровне есть свои выполнители работ , и свои объекты работ работы. Собственно, работа заключается в том, что выполнители изменяют как-то объекты работ. Выполнители работ и объекты работ обычно представлены существительными, работы -- глаголами и отглагольными существительными. Важно, что объекты работ сами ничего выполнять не умеют, они пассивны. А вот выполнители активны, они-то и трудятся над объектами и с использованием объектов.
Уровень людей содержательный. Люди за информацией видят те объекты окружающего мира, которые эта информация изображает. Смотрят на прогноз погоды и видят завтрашнюю погоду (а не описание погоды), смотрят на отчёт о стройке и видят количество реальных этажей (а не собственно отчёт), смотрят на отчёт о прибылях и убытках и видят ту самую прибыль. У людей есть цели, полномочия (могут выдавать некоторым другим людям поручения на выполнение работ) и ответственность (должны обещать, что выполнят поручения некоторых других людей). Целенаправленная деятельность есть только на этом уровне.
Уровень программ -- это обработка информации, заключенной в данных. Из одних данных программы делают другие данные, отличающиеся как форматом, так и содержанием. Никто никому ничего не обещает (обещать программы не могут, это могут только люди) и не даёт поручений (поручать могут только люди), не преследует никаких целей (цели есть только у людей). На этом уровне известно, что означают данные в реальном мире: ведь опасно к килограммам прибавлять километры. Главная задача уровня программ -- чтобы нужным способом обработанные данные оказались в нужный момент у нужных людей.
Уровень оборудования -- это бездушный мир, в котором никакой обработки данных уже нет, а есть только хранение и пересылка данных. Конечно, на уровне оборудования тоже есть программы, но они уже другого рода -- тут уже никто не знает, что означают эти данные в реальном мире. Задача оборудования -- хранить адресуемые как-то байты, не вдаваясь в их смысл, пересылать эти байты по запросам программ, а также хранить сами программы и давать им возможность выполняться.
3. Элементы и отношения
Предприятие в Архимейте описывается в виде элементов (изображаются разными фигурами), находящихся друг с другом в каких-то отношениях (отношения изображаются в виде соединительных линий между фигурками элементов). Архимейт ценен тем, что предлагает для описания работы предприятия всего
-- 16 типов элементов для уровня людей,
-- 7 типов элементов для уровня программ,
-- 9 типов элементов для уровня оборудования,
-- 11 типов отношений, в которых элементы могут находиться друг с другом, и показ развилок для этих отношений.
Если вы собираетесь как-то менять архитектуру предприятия в реальной жизни (а иначе зачем вы вообще стали рисовать диаграммы Архимейта?), то для этого можно использовать ещё:
-- 7 типов элементов для целеполагания и обоснования изменений в организации
-- 4 типа элементов для проектирования перехода к новой архитектуре
Еще есть комментарий и отношение связи комментария с какими-то другими элементами, а также рамочка для группировки элементов.
Вот и весь Архимейт. Но не нужно обольщаться его простотой. В Великом и Могучем тоже всего 33 буквы.
4. Нужен не ты, нужен твой сервис.
Важно, что никакие работы на предприятии не делаются просто так, они все кому-то зачем-то нужны. Сервисы -- это полезные для каких-то других выполнителей (точнее, полезные для работ этих выполнителей) работы. Для потребителей сервисов абсолютно неважно, как организовано выполнение этих работ: кто с чем работает, чтобы выставить сервис для внешнего потребления. Для них важно только, по каким каналам (электронная почта, окошечко с девушкой, телефонный звонок и т.д.) и интерфейсам (если это программы) будут предоставлены эти сервисы.
Есть сервисы оборудования, предоставляемые программам, и сервисы программ, предоставляемые людям. Три уровня предприятия склеены именно этими сервисами -- из каждого уровня главным образом видны только сервисы других уровней.
То есть можно заменить всё оборудование, и программы этого не заметят, если сервисы оборудования остались прежними. Так же и с программами: замени их все, но если сервисы останутся теми же, то люди это вполне переживут. В принципе, это относится и к самому предприятию: если сервисы людей, которые предприятие оказывает окружающему миру (а объединение таких сервисов и связывающего их контракта называется продуктом ) будут выполняться совсем по-другому организованными людьми, которые пользуются совсем другими программами, которые работают на совсем другом оборудовании, то клиенты этого не заметят. Этим и пользуются архитекторы предприятия: они описывают предприятие, а потом потихоньку меняют программы и оборудование, поддерживая предоставление критически важных сервисов. Это и называется сервис-ориентированным подходом: разделять (разные уровни работы сервисами) и властвовать. Так что это ещё как посмотреть: предприятие склеено сервисами, а для архитектора оно этими сервисами разделено.
Стремление разделять и властвовать у архитекторов так велико, что они разделяют сервисами и работы даже одного и того же уровня. Например, легко представить себе программы, оказывающие сервис не людям, а другим программам. Или оборудование, смысл существования которого -- служить (оказывать сервис, т.е. "работать для") другому оборудованию.
Для предоставления внешне видимой работы-сервиса нужно выполнить много-много извне невидимой внутренней работы -- изменения объектов работы выполнителями работ. Наличие этой границы внутреннего и внешнего рассмотрения ("черного ящика" с невидимыми внутренними выполнителями, работами и объектами против "прозрачного ящика", когда они отлично видны) -- это наличие границы системы . Архимейт моделирует системы , разделяя части/уровни предприятия сервисами (хотя про "системы" в спецификации Архимейта и не сказано ни слова).
5. Люди
Напомним пункт три: для описания уровня организации работы людей Архимейт имеет столько же типов элементов (17), сколько для уровней программ и оборудования вместе взятых (7+9) -- и это совсем не случайно.
Сами люди в Архимейте представлены не своими личностями. В Архимейте не человек красит место, а место красит человека. В Архимейте выполнителем является живой человек, но только занимающий организационное место. Поэтому Архимейт "людьми" называет эти самые места, кто бы их в данный момент ни заполнял -- один человек, целая группа людей из организационного звена (от сектора и отдела до филиала в другом государстве или даже всей компании целиком), временные работники, случайные граждане-клиенты, партнерские фирмы. Архимейт понимает, что это все эти оргместа занимают живые люди, но называет этих людей именно по наименованиям оргмест. Разнорабочий, зам.нач.отдела доставки, отдел доставки, филиал в Мытищах, клиент, аудитор -- это и есть "люди", кто бы ни были те сотрудники, которым доведется занимать эти организационные позиции. Архитектор, как водится, заботится о вечном: если разнорабочий или президент заболели, и один человек подменил другого на время болезни, диаграмма останется верна: организация труда не изменится.
Люди Архимейта более разнообразны, чем те люди, которых можно найти в "оргструктуре" (органиграмме): отнюдь не все отношения между людьми Архимейта сводятся к начальствованию-подчинению. Так, партнеры и клиенты обычно в оргструктуре не упоминаются, а в Архимейте их показ -- обычное дело.
6. Роли
Архитекторы настолько коварны, что работают и с частями людей, называя их "роли". Ролью называется та выделенная во времени часть людей, которая выполняет определенный ряд работ, требующих какой-то особой квалификации. Так, если разнорабочий в театре вынужден то петь, то танцевать, у него есть две роли: когда он поёт, то роль -- певец, а когда танцует -- роль танцор.
Люди назначаются на роли, а роли назначаются на работы. Особо нужно отметить факт, что архитекторы организации занимаются организацией работ, а не лидерством (leadership). Распределение людей по ролям, а ролей по работам -- это забота архитектора организации. А забота лидера -- это а) назначение на места "людей" живых "человеков" с фамилиями, именами и отчествами, вредными и полезными привычками, определенными умениями и б) убалтывание кнутом и пряником человеков на местах "людей" выполнять назначенные им работы. Так что фамилий на диаграммах Архимейта не увидишь: только должности, роли, подразделения, фирмы, "люди при исполнении", "представители", коллегиальные органы, временные группы и объединения и т.д..
В жизни назначение на роли и на работы обычно отражается приказами, распоряжениями, положениями и прочими "распорядительными документами". Такая система дробления людей нужна не только, чтобы показать многогранность занятий людей (напомню: и отдельных людей, и целых подразделений -- когда большая компания из 1000 сотрудников выступает как в роли поставщика по отношению к одним фирмам, так и в роли заказчика по отношению к другим фирмам), но и чтобы свои диаграммы архитекторы меняли поменьше, а устанавливающие организацию работ приказы издавались пореже.
Типичный пример: в организации начинают заниматься посадкой петрушки, но пока непонятно, кто будет эту петрушку сажать -- начальство говорит, "вы покажите, что там нужно будет делать, а я уж тогда назначу подходящую кандидатуру". Пишут "Положение о петрушке", где вводят роль "главного по петрушке" и "старшего по петрушке" и прописывают все их работы. Заметим, что Положение -- это еще не приказ, и не распоряжение. Это констатация факта, что какие-то организационные места (главного и старшего по петрушке) нужно заполнить, чтобы работы (по посадке петрушки) пошли. Начальник изучает этот проект положения, и заключает, что посадкой петрушки у него должны заниматься инженеры и юристы. Далее он пишет приказ, в котором он а) утверждает положение и б) прописывает, что роль главного по петрушке будет занимать инженер, а старшего по петрушке -- юрист. Вот как это выглядит:
Соединительные линии с точечками -- это и есть "отношение назначения" между элементами. Отношения есть, конечно, и между людьми и работами непосредственно (если опустить упоминание роли). Такое отношение будет называться производным, но оно всё равно есть -- можно говорить, что в данном случае инженер назначен на обеспечение всходов, а юрист на пригляд за посадкой.
Обратите внимание, что эта конструкция будет работать, даже когда инженер Иванов уйдёт на пенсию, а вместо него на это место будет принят Сидоров. В этой конструкции легко поменять инженера на агронома, или на Дирекцию по петрушке (когда деятельность разрастётся) -- этот механизм назначения ролей на работы (например, Положением), а людей на роли (например, Распоряжением) работает и в случае, когда "люди" -- это целая толпа людей, т.п. речь идет об организационном звене. Все эти Положения и Приказы на диаграмме обычно не отмечаются: на диаграммах договариваются, как будут организованы работы, а не какими документами эти договоры будут оформлены.
Подсказка: я знаю несколько организаций, где альбомы архитектурных описаний предприятия утверждались директором вместо толстой пачки регламентов. Ибо архитектурные диаграммы оказывались точнее и выразительнее многочисленных текстовых описаний, которые потом пытались по ним составить.
Понятно, что на посадке петрушки в конечном итоге работают самые живые Иванов и Сидоров (или сотрудники, которые числятся в Дирекции по петрушке). Но на предприятие они будут тратить только часть своего времени и талантов (и только эта часть времени отражается элементом "люди" в архитектуре предприятия), а остальное время спать, есть, гулять, учиться и развлекаться. На их роль в работах по посадке петрушки они будут тратить только часть времени, которое потратят на предприятие -- ибо у них наверняка много разных ролей, они выполняют много разных работ. Да и на одну и ту же роль вполне могут быть назначено и некоторое количество людей -- отдельных человек или даже несколько подразделений.
И людей, и ролей можно дробить на любое число частей, если нужно показать какие-то детали занятости людей-выполнителей.
Для выполнения какой-то работы разные люди могут на время объединиться (это обычно никак не отражается в оргструктуре), и такое временное объединение называют коллегиальной ролью .
7. Работы людей
Работы людей бывают такие:
- уже случившиеся -- события . Называют обычно события глаголом совершенной формы прошедшего времени: "петрушка посажена". Эти работы могут быть выполнены непреднамеренно ("случилась ошибка"), людьми не из предприятия (клиентами, конкурентами, партнёрами), да и не вообще эта работа могла быть выполнена не людьми (а, например, программами, оборудованием, или даже силами природы -- "солнце зашло").
- направленные на достижение результата, и исполняемые в развертке времени (часто -- друг за дружкой) --процессы. Их называют глаголом в неопределенной форме -- "копать", "посадить", "разработать". Процессы обычно запускаются событием, и запускают события, а также запускают друг друга, образуя цепочку от начального события до события-результата.
- полученные в результате работы временного коллектива, объединённого коллегиальной ролью -- коллегиальные процессы. Их тоже называют глаголом в неопределенной форме.
- отобранные по какому-то иному, чем развертка во времени для получения результата (например, требующие назначения на них ролей с определенной квалификацией или потребляющие какой-то специфичный вид ресурсов) -- практики . Практики не столько сами выполняются, сколько в разные моменты выполняются те или иные объединённые ими процессы (или фрагменты процессов, до которых дело на диаграмме так и не дошло, поэтому их изобразили без развертки во времени, чохом, "в мешке" -- то есть обозначили "что практикуется", а не указали на выполнение в какое-то определенное время). Поэтому практики обозначаются не глаголами, а отглагольными существительными: "посадка петрушки" это именно практика.
- предоставляемые кому-то вовне работы, как они значимы и видятся снаружи -- сервисы . Сервисы реализованы внутренними работами, выполняемыми внутренними ролями, и используется в ходе внешних работ, выполняемых внешними ролями. В принципе, любые работы людей выполняются только для того, чтобыреализовать какой-то сервис -- то есть для того, чтобы кто-то другой (например, клиент, или смежники) смогли воспользоваться этими работами.
В принципе, все предприятие разбито на какие-то части, и эти части выставляют наружу (для других частей предприятия, или за границы предприятия, или для другого уровня) сервисы, чтобы оправдать своё существование. Если есть трудности в понимании, кто в каких работах использует те или иные сервисы, или какие сервисы реализуют те или иные работы -- значит, вы что-то не знаете, или не продумали.
Для уточнения того, чем же именно ценен сервис, в Архимейте даже есть специальный элемент: внешняя польза , которая связана с сервисом.
* * *
В принципе, уже видно, что рассказ в таких терминах вполне получается -- он не выглядит слишком абстрактным и заумен ровно в той мере, в какой заумен сам Архимейт. Дальше можно уже не писать новые тексты из серии "Архимейт по-русски", а просто подкорректировать ранее написанные. Ну, и продолжить локализацию программы.
Вторая статья про мифологическое сознание тоже будет короткой. Сегодня я расскажу, к каким проблемам приводит мифологическое сознание при моделировании архитектуры предприятия.
Известная модель Захмана пытается ответить на вопрос, что такое архитектура предприятия, и рассказывает о том, как она должна моделироваться. Основой этой модели являются вопросы, на которые предлагается ответить: кто, когда, где, почему и как совершает что-то над чем-то. Кажется, что это логичный фреймворк для описания архитектуры предприятия, и многие думают, что так оно и есть.
Однако, даже беглый взгляд на этот фреймворк оставляет чувство неудовлетворенности, потому что не понятно, как ответить на вопрос: кто и почему выточил деталь? Кто: Иван Иванович, или токарь, роль которого исполнял Иван Иванович? Почему: потому что токарь получил задание, или потому что Иван Иванович заключил контракт, в соответствии с которым он обязуется выполнять роль токаря в обмен на еду? Почему: потому что Иван Иванович хочет покушать, или затем, что деталь нужна в сборочном цехе?
Более глубокое изучение этого фреймворка заставляет задуматься над его применимостью к описанию технологических процессов. Например, пусть кукуруза растет в поле. Применяя модель Захмана, я должен ответить на вопросы. Кто? Кукуруза. Что делает? Растет. Почему? Потому что так устроен мир. Зачем? Да кто же его знает, зачем растет кукуруза?!
Читатель, натренированный в описании архитектур предприятий, быстро меня поправит. Он скажет, что я неправильно ставлю вопросы. Надо спрашивать: кто выращивает, почему он выращивает, что выращивает. Но тогда получается, что я могу описать деятельность субъекта, который выращивает кукурузу, но не могу описать сам рост. Смирившись с тем, что я не могу описать процесс роста, у меня все равно остаются неразрешенные вопросы: кто и почему выращивает кукурузу (см. выше)?
Получается, что, задавая вроде бы логичные вопросы, я в лучшем случае получаю несколько ответов, а в худшем, не получаю их вообще. Если взять предельный случай, когда у нас есть полностью роботизированное предприятие, на котором вообще нет людей, то ответом на вопрос «кто?» будет - «никто». В результате мы вообще ничего не можем сказать об этом предприятии! Правда, есть один выход из этой ситуации, немного лукавый, – надо лишь воспользоваться мифическим сознанием и одушевить роботов. Тогда, одушевив неодушевленное, мы сможем ответить на вопрос: кто? Робот. Почему? Потому что так устроен этот робот, или потому что программист его так запрограммировал. На второй вопрос мы снова получаем странные ответы. Почему же так получилось, и какие вопросы на самом деле стоит задавать? Я попытаюсь кратко изложить свое мнение на этот счет, рассказав о тех логических ошибках, которые я нашел в модели Захмана.
Если посмотреть на вопросы, которые задаются в модели Захмана, можно убедиться, что они в точности соответствуют теории деятельности. Деятельность – это психическая функция субъекта (группы субъектов). Поэтому, отвечая на вопросы Захмана, мы строим модель психической функции субъекта (субъектов). Наука, изучающая психические функции субъектов, называется психология. Получается, что Захман отвечает на вопросы, которыми задаются психологи: зачем субъект делает то или иное действие? Или как мотивировать субъекта на выполнение тех или иных действий? Эти вопросы, безусловно, интересные и важные, но являются ли ответы на них описанием архитектуры предприятия? Чтобы ответить на этот вопрос, надо понять, что же такое предприятие?
Как же на самом деле происходит проектирование предприятия и какие артефакты при этом возникают? Прежде чем проектировать предприятие, строится модель требований к нему. Модель требований формируется на основе требований, которые предъявлены к этому предприятию со стороны всех его участников, контрагентов и стейкхолдеров. Аналог в ИТ - требования к программному продукту. Далее на основе этих требований строится модель процессов предприятия с необходимой степенью детализации. Аналогом в ИТ будет перечень функций программного продукта. Далее строится модель функциональных объектов, или, говоря специализированным языком, технических мест, которые должны участвовать в перечисленных ранее процессах. Аналогом в ИТ будет описание процедур, и объяснение какие процедуры в каких функциях участвуют. Далее подбираются те единицы оборудования, которые могут выполнять роли перечисленных технических мест. Аналог в ИТ - это программный код.
Предприятие – это функциональный объект, который создан удовлетворяющим определенным требованиям. В этом смысле предприятие ничем не отличается от такого объекта, как часы, или производственная линия. Часто вместо термина функциональный объект можно услышать термин техническое место. Техническое место отличается от единицы оборудования тем, что единица оборудования выполняет роль технического места. Например, трансформатор выполняет роль преобразователя напряжения, при этом в разное время разные трансформаторы могут выполнять роль одного и того же преобразователя. Еще одним примером технического места является должность, отдел, подразделение, штат. Например, токарь участвует в функции изготовления деталей. Это - техническое место, роль которого в разное время могут выполнять разные единицы оборудования (физические лица). О сложностях моделирования технических мест и единиц оборудования я кратко написал в статье .
При моделировании технических мест, мы описываем процессы и участников этих процессов. Замечу, что именно участников, а не исполнителей, - трансформатор не может преобразовывать напряжение, потому что он не является одушевленным существом. Об этом я писал в прошлой статье . Если все же сказать, что трансформатор «преобразует» напряжение, то это – метонимия, которая раскрывается так: трансформатор, исполняет роль преобразователя напряжения, который (преобразователь) участвует в процессе преобразования напряжения. О метонимии можно прочитать в книге «Метафоры, которыми мы живем», авторы: Джордж Лакофф, Марк Джонсон. Другой распространенной метонимией будет высказывание: «компьютер решает задачи». Те же, кто действительно считают, что трансформатор, или компьютер что-то делает на самом деле, одушевляют неодушевленное, пользуясь мифическим сознанием.
Заметим, что до сего момента мы ни слова не сказали о целях, об исполнителях и причинно-следственных связях. Мы лишь говорили о требованиях, о функциях и участниках этих функций – технических местах. Цели остались на этапе формирования требований к предприятию и далее они не пошли. Мы можем знать эти цели, а можем не знать, - для модели предприятия это не имеет никакого значения. Модель предприятия отвечает на вопрос: как мы удовлетворяем требования, а не то, откуда взялись эти требования. Исполнителей тоже нет, потому что нам не надо пользоваться теорией деятельности, чтобы описать участников активности. Мы не строим причинно-следственные связи. Если же надо построить модель причинно-следственных связей, то это еще одна дополнительная модель. Это знания, которыми пользуются технологи при проектировании предприятия, и я не видел, чтобы кто-то строил такие модели. Это - отраслевые знания, и учат им в институтах по много лет. Смоделировать, почему летит самолет – нереально трудно, и никто этого не делает. Просто моделируют полет самолета.
Итак, модель Захмана не включает в себя требования к предприятию, включает в себя модель процессов, но довольно специфическим способом - с указанием на исполнителей процесса, которых, как я уже сказал можно найти только в теории деятельности, и не разделяет модель технических мест и модель единиц оборудования.
Как я сказал ранее, модель Захмана скорее про деятельность. При этом было бы неплохо, если бы модель Захмана использовалась по назначению, - как способ описания деятельности. Это давало бы возможность анализировать мотивы и заинтересованность людей в их работе, но беда в том, что эта модель используется неверно. Например, на вопрос «почему токарь точит деталь?» можно получить ответ: «она нужна в сборочном цехе». Но необходимость ее в сборочном цехе не отвечает на вопрос, почему токарь точит деталь. Ответ был не на поставленный вопрос, а на какой-то другой. Например, для такого ответа правильным был бы вопрос: в каком процессе, или в какой операции должна участвовать выточенная деталь? Или на каком рабочем месте она нужна? Вы видите, что это совсем не вопрос «почему?». Кроме того, меня сильно смущает наделение Захманом компьютера или информационной системы способностью что-то делать. Скорее всего, он не одушевляет их, но использует метонимию в моделировании, что на мой взгляд, недопустимо.
Правильными вопросами будут: Какие существуют требования к предприятию? Какие процессы протекают на предприятии? Какие технические места в каких процессах участвуют? Какие единицы оборудования выполняют роли каких технических мест и когда?
Собственно, все. С наступающим, и до новых встреч!
Программное обеспечение 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.
Современные информационные технологии (ИТ) становятся неотъемлемой составляющей любого предприятия. Сегодня они для многих предприятий - не просто способ автоматизации рутинныхопераций (технологическая подложка), а эффективный инструмент в конкурентной борьбе. Современные ИТ – системы призваны быстро адаптироваться к новым потребностям бизнеса (его целям задачам) и полностью соответствовать архитектуре предприятия (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).
Число изменений во внешней среде нарастает с высокой скоростью, и поэтому требования к адаптивности компаний повышаются год от года. В статье рассматриваются основные принципы управления архитектурой предприятия, наиболее известные методы в данной области и преимущества их применения.
Изменения и адаптивность компании
Число изменений во внешней среде нарастает с безумной скоростью, и поэтому требования к адаптивности компаний возрастают год от года. По различным аналитическим исследованиям топ-менеджеры большинства международных компаний больше всего напуганы тем фактом, что их компании не успевают адаптироваться к происходящим изменениям, при этом тренд в этой области отрицательный Во многих случаях основная проблема в обеспечении адаптивности компании – это согласование и контроль требуемых изменений в рамках всей организации. При изменении целей, меняется стратегия, что в свою очередь требует изменений в бизнес-процессах и приоритетах проектов, а также в организационной структуре.
Все это косвенным образом влияет на знания и полномочия внутри компании, а это в свою очередь может привести к изменениям в информационных потоках, которые в свою очередь потребуют изменений в существующих информационных системах. В качестве решения вышеозначенной проблемы, необходимо анализировать все элементы предприятия в целом, при этом такая совокупность элементов называется архитектурой предприятия. Управление архитектурой предприятия (Enterprise Architecture), создает основу для синхронизации всех вышеперечисленных объектов внутри организации, и в тоже время запускает цикл их непрерывного изменения для целей оптимизации бизнеса.
«Архитектура предприятия устанавливает путь к достижению миссии организации благодаря оптимальному функционированию ее ключевых бизнес-процессов внутри эффективного ИТ- окружения.” Jaab Schekkerman, Institute For Enterprise Architecture Development (IFEAD).
Прослеживаемость изменений и согласованность всех элементов архитектуры внутри компании увеличивает ее адаптивность, что в настоящее время является наиболее важным фактором в конкурентной борьбе. При этом, фактором сдерживающим изменения, часто могут стать информационные системы, что требует особого внимания при синхронизации элементов бизнес -архитектуры и ИТ-архитектуры.
Для используется стандартный цикл, состоящий из следующих шагов: описание существующей архитектуры, проектирование целевого состояния архитектуры, формирование плана перехода от существующей к целевой архитектуре. При этом на первом шаге основной сложностью является определение того, какие элементы архитектуры и в каком объеме нужно описывать.
С одной стороны детальность создаваемого описания означает более глубокую проработку отдельного, а с другой стороны излишние появляются излишние трудозатраты как на создание самого описания, так и на поддержку его в актуальном состоянии. Как говорится «лучшее враг хорошего», и поэтому слишком полное и подробное описание элементов архитектуры не приносит пользы. Именно поэтому «в начале пути» так важно определение ключевых элементов архитектуры предприятия из всех возможных и концентрация именно на их описании и анализе. Практика показывает, что первое рассогласование в архитектуре предприятия , как правило, возникает между целями, бизнес-процессами и организационной структурой. Во многих случаях множество целей не поддержаны необходимыми ресурсами и бизнес-процессами.
Поэтому уже на этом этапе анализа архитектуры предприятия можно определить план работ по оптимизации деятельности компании в этой части. Если проанализировать существующие в компании информационные технологии, то они также часто несогласованны с существующими, а тем более целевыми бизнес-процессами. И здесь тоже появляется обширное поле для оптимизации деятельности. Помимо несогласованности между ключевыми элементами архитектуры предприятия часто можно увидеть проблемы и внутри отдельного элемента, в первую очередь это дублирование, а также организационные и информационные разрывы и т.д.
Однако не только числом изменений и требованием к адаптивности компании вызвано столь серьезное внимание к вопросам управления архитектурой . Сложность технологических систем возрастает, что означает снижение их надежности. И здесь формализация архитектуры предприятия становится базой для обеспечения процедур управления операционными рисками и в компании. Ведь если основные элементы архитектуры предприятия формализованы, то определить риски и проанализировать эффективность процедур контроля уже не представляет особой сложности. Именно поэтому наиболее критично управление архитектурой в крупных компаниях, использующих сложные технологии, которые сопряжены с множеством операционных и технологических рисков.
Управление архитектурой предприятия
Сейчас можно отметить, что российские компании начали использовать архитектурный подход при совершенствовании своей деятельности и при внедрении ИТ- приложений, хотя нам еще далеко до таких лидеров в этой области как США. Архитектура предприятия должна стать основой для определения структуры компании (цели, ключевые показатели результативности, бизнес-процессы, организационная структура и т.д.), информации необходимой для ведения бизнеса (данные, документы, информация и т.д.) и информационных технологий используемых для поддержки бизнес-процессов.
Фактически можно выделить бизнес-архитектуру и ИТ- архитектуру компании. Согласованность всех элементов архитектуры между собой позволит «навести порядок», при этом для обеспечения адаптивности необходимо не только построение архитектуры, но и создание процесса управления изменениями в целях обеспечения соответствия существующей архитектуры предприятия изменяющейся внешней среде.
Для решения задач построения архитектуры предприятия создано множество методологий (Frameworks):
Модель Захмана (Framework for Information Systems Architecture) — методика описания архитектуры информационных систем;
DoDAF – Department of Defense Architecture Framework – методика описания архитектуры Министерства обороны США, ранее известная под названием C4ISR AF;
FEAF – Federal Enterprise Architecture Framework — Федеральная Архитектура Государственных организаций США;
TEAF - Treasury Enterprise Architecture Framework — методика описания архитектуры казначейства США;
TOGAF – The Open Group Architecture Framework — методика описания архитектуры разработанная Open Group;
NASCIO - National Association of State Chief Information Officers – методика, разработанная Национальной ассоциацией CIO США;
NATO Architecture Framework — методика описания архитектуры НАТО;
Enterprise Architecture Desk Reference — документ компании META Group;
Самой первой считается модель Захмана, созданная в 1987 году, на ее основе были разработаны многие существующие модели и методики в области управления архитектурой предприятия. Все эти наработки в той или иной степени задают классификацию основных элементов архитектуры и единые принципы для их описания во взаимной увязке друг с другом, а также используемые правила и модели, которые применяются для формализации элементов архитектуры на разных уровнях детализации. В качестве примера одной из методологий можно привести элементы архитектуры TOGAF, которая предложена некоммерческим объединением Open Group, в которое входит ряд ведущих производителей в области. При этом нужно отметить, что данная архитектура не является эталонной моделью, а скорее является методологией разработки архитектуры предприятия.
От бизнес- архитектуре к архитектуре ИТ
Согласование требований бизнеса и возможностей информационных технологий является одним из ключевых преимуществ от управления архитектурой предприятия . Сейчас развитие современного бизнеса трудно представить без применения информационных технологий, ведь результативность существующих бизнес-процессов зависит от качества их информационной поддержки. Часто в крупных компаниях каждое подразделение использует в работе «собственные» информационные системы, начиная от электронных таблиц и заканчивая «тяжелыми» ERP – системами. Однако во многих случаях отсутствует единый взгляд на использование информационных систем в рамках «сквозного» процесса компании.
При этом если автоматизацией бизнеса заниматься несистемно и без применения архитектурных подходов, то в скором времени компания столкнется с серьезными проблемами, связанными с использованием информационных технологий и их соответствию требованиям бизнеса. В начале развития компании использование множества различных информационных систем, иногда дублирующих друг друга, кажется не очень страшным. Однако, по мере увеличения размера компании «зоопарк» информационных систем увеличивается, и в какой-то момент, при попытке сделать требуемые изменение в бизнес-процессе, затрагивающем множество подразделений и информационных систем, придется изменять большое число различных ИТ- решений, что потребует серьезных ресурсов. К сожалению, эта проблема возникает от пренебрежения архитектурным подходом при планировании развития информационных технологий. Еще одной проблемой большинства компаний является отсутствие качественного документирования существующих ИТ — решений. Внедренные информационные системы должны быть документированы на требуемом уровне, иначе компания через некоторое время столкнется с «черным ящиком», работа которого непонятна никому.
В российской практике существует множество случаев, когда компании отказывались от внедренной информационной системы, из-за некачественного документирования и начинали внедрение новой системы. Это происходит по причине невозможности внесения изменений в такую систему, что делает ее неудобной для бизнеса. Таким образом, управление архитектурой предприятия может решить основную проблему автоматизации бизнес-процессов сократить «разрыв» между существующими бизнес-процессами и средствами их автоматизации. В большинстве случаев причиной такого разрыва является неформализованность бизнес-процессов и требований к информационной системе, а также сложность внесения изменений в существующие ИТ-решения. И если не предпринимать специальных действий, то этот «разрыв» будет только увеличиваться со временем, пока не произойдет отказ бизнеса от использования информационной системы, а значит потери сделанных инвестиций в развитие информационных технологий.
В настоящее время на ИТ- рынке окончилась «ERP-эйфория» – вера в возможность полной автоматизации бизнеса одной монолитной информационной системой. Множество компаний, вложив миллионы долларов в автоматизацию, так и не получили требуемых преимуществ. И теперь понятно, что «зоопарк» информационных систем в компании неизбежен. Именно поэтому сегодня необходимо описывать и анализировать существующую ИТ- архитектуру компании и синхронизировать ее с бизнес- архитектурой, а не надеяться на полномасштабную автоматизацию с помощью одной информационной системой. Сложность взаимодействия бизнеса и ИТ усугубляется масштабностью бизнеса в глобальных холдингах, а также наследованием бизнес-процессов и информационных систем в результате слияний и поглощений. При увеличении уровня использования информационных технологий, растет зависимость бизнеса от качества и надежности поддерживающих его информационных систем и ИТ- инфраструктуры, что в свою очередь требует четкости и прозрачности взаимосвязи бизнес-процессов с ИТ- архитектурой и ИТ- инфраструктурой.
Именно поэтому сейчас основными требованиями к существующей ИТ -архитектуре и ИТ – инфраструктуре компании является надежность поддержки бизнес-процессов, а также гибкость существующих информационных систем, заключающаяся в способности быстрой адаптации к изменяющимся бизнес- процессам. Все эти требования можно выполнить, только если начать системно заниматься автоматизацией бизнес-процессов, уделяя внимание вопросам построения как ИТ – архитектуры, так и архитектуры бизнеса в целом, что делает применение архитектурных подходов строго необходимым для обеспечения выживаемости бизнеса в сегодняшних условиях.
Ключевые элементы архитектуры предприятия
Несмотря на присутствие большого числа методологий в области создания и управления архитектурой предприятия , на практике большинство компаний ограничиваются следующими элементами архитектуры предприятия : цели бизнеса; организационная структура; ключевые показатели результативности; бизнес-процессы; портфель проектов; документы; информационные системы; знания персонала. Это тот необходимый минимум, который позволяет согласовать основные элементы архитектуры между собой. При этом если цели, показатели, организационная структура и бизнес-процессы часто уже как-то взаимосвязаны между собой, то между процессами и информационными системами такой взаимосвязи часто нет. Поэтому, одной из первоочередных задач, для многих компаний является переход от моделей и регламентов бизнес-архитектуры к вопросам определения требований к информационным технологиям и построения соответствующей им ИТ- архитектуры.
Информационный разрыв вызван передачей информации от бизнес-аналитиков к ИТ – специалистам, и в этот момент формализация таких элементов архитектуры, как требования, ИТ- функции, транзакции, структуры данных вместе с бизнес-процессами позволяет этот разрыв сократить. На этом этапе наиболее правильно использовать рекомендации, содержащиеся в вышеозначенных методологиях описания архитектуры предприятия, например в TOGAF. Таким образом для устранения «информационного разрыва» между бизнесом и ИТ необходимо расширять описание существующей архитектуры предприятия и, в частности архитектуру бизнеса, в направлении ИТ- архитектуры с учетом единства используемой методологии описания как для бизнес- аналитиков, так и для ИТ –специалистов. При таком переход от описания архитектуры бизнес-процессов к описанию ИТ- архитектуры необходимо формализовать несколько дополнительных элементов архитектуры. В первую очередь необходимо описать архитектуру данных, которая строится на основании той информации и документов, которые используются в бизнес-процессах, после чего необходимо сформировать архитектуру приложений и ИТ- инфраструктуру.
Переход от бизнес- архитектуры к ИТ — архитектуре (приложения, информация, инфраструктура)
Для построения архитектуры данных необходимо выделить основные сущности и агрегировать на них все «кванты» информации собранные из описания бизнес-процессов. Практика показывает, что для решения данной задачи можно использовать стандартную методологию описания данных — модель «сущность-связь» (Entity-Relationship Model – ERM), в рамках которой можно четко структурировать всю информацию.
Следующим этапом формализации ИТ-архитектуры является переход от архитектуры бизнес-процессов и архитектуры данных к созданию архитектуры приложений. На этом этапе необходимо определить классы информационных систем, необходимых для автоматизации, после чего определить необходимые модули для каждой информационной системы. Здесь, основой для проектирования архитектуры приложений и ее синхронизации с бизнес -архитектурой является карта процессов (обобщенное представление всех бизнес-процессов предприятия). На модели архитектуры приложений располагаются основные типы информационных систем, которые далее детализируются на модели модулей информационных систем, и далее до уровня отдельных экранных форм — транзакций. Еще одним ключевым элементом архитектуры с точки зрения взаимосвязи бизнеса и ИТ являются требования к информационной системе.
Фактически модели требований — это целевой функционал ИТ — решения, который структурируется по бизнес-процессам или по подразделениям. На основании этих требований и существующих моделей бизнес-процессов, а также с учетом построенных моделей данных проектируется новая (целевая) архитектура приложений. При этом помимо методологий управления архитектурой предприятия для решения поставленных задач необходимо использовать и отраслевые стандарты. Например, в случае телекоммуникационных компаний в качестве основы можно использовать материалы методологии New Generation Operation System and Software (NGOSS), которая была создана в 2001 году TeleManagement Forum, и содержит следующие модели: ·
информационная модель телекоммуникационного предприятия (Enterprise-wide information framework Shared Information and Data Model — SID);
структура приложений телекоммуникационной компании (Applications framework – Telecom Applications Map — TAM).
Заключение
В заключение можно отметить, что основной задачей при управлении архитектурой предприятия является синхронизация всех элементов архитектуры между собой. При этом одной из ключевых задач является взаимосвязь бизнес- архитектуры и архитектуры ИТ с одной стороны через документирование, совершенствование и стандартизацию бизнес-процессов, а с другой через описание элементов ИТ- архитектуры на логическом уровне, во взаимосвязи с бизнес-процессами. При этом концентрация в управлении архитектурой предприятия должна происходить лишь на ключевых элементах, что позволит получить максимальный результат с минимальными ресурсами.
Распыление ресурсов на описание всех элементов архитектуры часто дает отрицательный результат с точки зрения бизнеса, поскольку отодвигает горизонт решения существующих проблем на очень длительный период. Цели, показатели, процессы, проекты, организационная структура, документы, данные, приложения – вот тот необходимый минимум, который позволит начать внедрение архитектурных подходов в деятельность компании. В части глубины описания рекомендация может быть одна – если есть возможность обойтись существующим уровнем описания – нет смысла создавать еще один.
Такой подход позволит сэкономить много ресурсов, при этом получив значимый для бизнеса результат. В части ИТ-архитектуры, имея картину существующего положения и разработав модель целевой ИТ – архитектуры, можно создать программу унификации и стандартизации ИТ- решений в компании, что позволит сократить затраты на ИТ в коротком промежутке времени.
Андрей Коптелов, Проблемы теории и практики управления. Выпуск № 01 2010 года