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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для многих людей, назначенных архитекторами (особенно для тех, кто пришёл "из программистов" или "из сисадминов"), оказывается полной неожиданностью неминуемый переход от изображения на Архимейте результатов разных интервью в качестве "архитектурного описания 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.

Информационные технологии и управление предприятием Баронов Владимир Владимирович

Зачем требуется понятие архитектуры

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

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

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

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

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

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

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

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

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

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

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

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

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

Облегчение управления изменениями в любых аспектах предприятия:

– конвергенция – использование стандартных информационных технологий;

– улучшение связи между основными подразделениями и подразделениями информационных технологий в пределах всего предприятия на основе использования стандартизированного словаря;

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

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

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

Совершенствование процессов планирования капиталовложений и инвестиционного управления;

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

Достижение экономии на основе совместного использования услуг в масштабах всего предприятия;

Упрощенная интеграция наследуемых, перемещаемых и новых систем.