Виктор Галактионов, 20.05.2002
Журнал "Директор ИС", #05, 2002 год // Издательство "Открытые Системы" (http://www.osp.ru/)

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

Я — географ, а не путешественник. Мне ужасно не хватает путешественников. Ведь не географы ведут счет городам, рекам, горам, морям, океанам и пустыням. Географ — слишком важное лицо, ему некогда разгуливать. Он не выходит из своего кабинета. Но он принимает у себя путешественников и записывает их рассказы.

Антуан де Сент-Экзюпери. «Маленький принц». Глава 15. Географ

Известно, что бизнес любой современной компании все больше и больше становится зависим от информационных технологий. Развитие отдельных направлений бизнеса, например развитие «карточного бизнеса» в банках, стало возможным исключительно благодаря появлению современных ИТ. Конечно, это справедливо и для предприятий других отраслей. Потому можно надеяться, что излагаемый опыт без значительных усилий по адаптации может быть использован в бизнесе любой другой, небанковской компании.
Особенности сегодняшнего уровня развития банковских информационных технологий заключается в том, что во многих банках, которые смогли сохранить свой бизнес после кризиса 1998 года и сегодня продолжают его активно развивать и наращивать, высокотехнологичные банковские решения внедряются на фоне продолжающейся эксплуатации программных систем и комплексов предыдущих поколений, зачастую морально устаревших. С другой стороны, остановка банковского бизнеса даже на несколько часов, тем более остановка на один или несколько дней для вывода из эксплуатации устаревшего программного обеспечения и ввода в эксплуатацию нового, в большинстве случаев будет равносильна утрате бизнеса. В этой ситуации в каждый момент времени необходимо иметь четкое представление о текущем статусе всех внедряемых и эксплуатируемых информационных систем, а также не менее четкое понимание их дальнейшего развития с учетом перспектив развития банка, его архитектуры как архитектуры предприятия . (В англоязычной литературе — методиках, статьях, стандартах — этому соответствует термин enterprise architecture .)
Следует отметить, что архитектура предприятия существует независимо как от нашего сознания, так и от размера этого предприятия — будь то глобальная корпорация, небольшой завод, малое торговое предприятие и т. п. У малого предприятия архитектура есть так же, как и у крупного, при этом они не слишком сильно различаются по составу компонентов. Однако одни руководители это понимают и могут себе позволить уделять внимание всем аспектам устройства своего же предприятия (это, как правило, руководители крупных компаний), а другие — нет. Иное дело, что у малого предприятия могут быть всего два-три продукта, миссия и стратегия в явной форме не зафиксированы (эта беда, кстати, встречается часто и в крупных компаниях), количество сотрудников составляет 30 человек и в производстве используется два компьютера с MS Word 97. Но и в таком случае это все и составляет архитектуру данного предприятия.
В статье представлен достаточно развернутый и одновременно прагматичный подход к организации работ по анализу архитектуры предприятия в целом и планированию системной архитектуры, в том числе к ее документированию. Основными целями документирования знаний о бизнесе (разработки архитектуры предприятия) являются обеспечение сохранности инвестиций в бизнес и прозрачности бизнеса на всех уровнях.
Прозрачность бизнеса начинается с прозрачности понимания архитектуры предприятия, с четкого разделения ее на три взаимозависимых уровня: стратегический уровень, уровень бизнес-архитектуры, уровень системной архитектуры. Системная архитектура определяется бизнес-архитектурой, и ее проектирование может осуществляться только на основании бизнес-архитектуры, которая в свою очередь зависит от стратегии предприятия. Этот подход позволяет, на наш взгляд, не только правильно организовать сами работы и произвести корректное разделение функций и ответственности бизнес-архитектора («бизнес-девелопера»), отвечающего за развитие бизнеса, то есть бизнес-архитектуры предприятия, и системного архитектора, но и, самое главное, выстраивать сбалансированную архитектуру предприятия, адекватно соответствующую его миссии и стратегии.
В начале статьи приведены основные определения. Затем рассмотрен состав и содержание системной архитектуры, проанализированы взаимосвязи сущностей бизнес-архитектуры и системной архитектуры. Достаточно детально рассмотрены фазы и участники жизненного цикла системной архитектуры, в частности функции участников. Наконец, в сокращенном виде представлена структура знаний, лежащих в основе системной архитектуры, и сделаны заключительные выводы.

Базовые понятия

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

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

Рассматриваемая в статике архитектура предприятия состоит из следующих элементов:

• миссия и стратегия, стратегические цели и задачи;
• бизнес-архитектура;
• системная архитектура.

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

Рис. 2.

Таким образом, архитектура предприятия в общем случае описывается следующими последовательно зависимыми разделами (см. рис. 1 и рис. 2):

• сформулированные миссия и стратегия банка, стратегические цели и задачи;
• бизнес-архитектура в текущем (as is) и планируемом (to be) состоянии,
• системная архитектура в текущем (as is) и планируемом (to be) состоянии;
• планы мероприятий и проектов по переходу из текущего состояния в планируемое.

На рис. 1 показано, что выполнение плана миграции не означает замораживания развития бизнес- и системной архитектуры. Таким образом, планируемая системная архитектура является архитектурой «to be» только на определенном витке развития предприятия. Одновременно возврат к стратегическому уровню миссии и стратегических целей и задач не означает необходимость пересмотра миссии и стратегии. Но в конце каждого цикла обязательно проводится анализ эффективности разработанных и осуществленных мероприятий, при необходимости при второй итерации корректируются бизнес-архитектура, системная архитектура, реализуются новые планы миграции. В каждый момент времени может быть несколько циклов, каждый такой цикл не обязательно затрагивает все предприятие в целом, цикл может затрагивать отдельные направления, отдельные вопросы бизнеса и может быть зафиксирован в виде отдельного проекта.
При поэтапном плане миграции для фиксации достигнутых результатов возможно построение промежуточных (миграционных) одной или нескольких архитектур.
Миссия, стратегия и бизнес-цели определяют направления развития банка и ставят долгосрочные цели и задачи.
Бизнес-архитектура на основании миссии, стратегии развития и долгосрочных бизнес-целей определяет необходимые организационную структуру, структуру каналов продаж и функциональную модель банка, документы, используемые в процессе разработки и реализации продуктов. Функциональная модель описывает бизнес-процессы, направленные на реализацию текущих задач и перспективных целей.
Бизнес-архитектура включает в себя:

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

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

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

Системная архитектура

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

Рис. 3.

Компоненты системной архитектуры

Прикладная архитектура включает в себя:

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

Архитектура данных включает в себя:

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

Техническая архитектура состоит из сетевой архитектуры и архитектуры платформ.
Сетевая архитектура включает в себя:

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

Архитектура платформ включает в себя:

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

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

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

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

Взаимосвязи системной архитектуры и бизнес-архитектуры

Архитектура предприятия полностью описывается следующими сущностями (см. рис. 4):

1. Миссия и стратегия банка, стратегические цели и задачи.
2. Продукты и бизнес-процессы.
3. Документы.
4. Организационная структура.
5. Приложения.
6. Данные.
7. Оборудование.
8. Планы мероприятий и проектов по переходу из текущего состояния в планируемое.

Рис. 4. Взаимосвязь сущностей верхнего уровня архитектуры предприятия

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

Рис. 5. Архитектура предприятия и место в ней системной архитектуры

На рис. 5 дано укрупненное графическое отображение архитектуры предприятия и определяющих ее компонентов.
Пример ключевых взаимосвязей между основными элементами бизнес-архитектуры и системной архитектуры показан на рис. 6 в форме ER-диаграммы.

Рис. 6.

Сущности и взаимосвязи двух архитектур

Жизненный цикл системной архитектуры

Для регламентации жизненных циклов (ЖЦ) систем в целом (в том числе предприятий), а также их информационных систем и программных средств (ПС), в частности, существует ряд стандартов. Они предусматривают возможности приспособления моделей ЖЦ, в том числе фаз (стадий) к особенностям конкретного предприятия и проекта. Таким образом, описанные в данном и следующем разделах фазы ЖЦ не противоречат нормативным и не являются догмой. Их преимуществом в смысле использования в данной статье является простота и опыт практического применения.

Рис. 7.

Жизненный цикл системной архитектуры состоит из следующих фаз: (см. рис. 7):

• начальное документирование;
• использование;
• проектирование;
• миграция.

ПРИМЕЧАНИЕ. После завершения фазы миграции процесс повторяется, очередная итерация начинается с фазы использования. Фаза начального документирования при разработке новых ИС может отсутствовать. Разработка системной архитектуры начинается с фазы проектирования.
На фазе использования осуществляется эволюционное развитие системной архитектуры в соответствии с ранее сформулированными принципами и без изменения основных технических и технологических решений.
ПРИМЕР. Пусть на фазе проектирования была разработана системная архитектура программы ведения бухгалтерского учета в центральном офисе и филиалах и осуществлено ее внедрение (фаза миграции). Знания о системной архитектуре этого решения переходят в стадию использования до момента возникновения новых бизнес-требований на доработку/модернизацию построенной системы. Знания системной архитектуры созданного решения используются компанией для построения хранилища данных с целью консолидации информации и последующего получения управленческой отчетности. Но основе этих знаний проектируется системная архитектура хранилища данных и затем системы управленческой отчетности, которые в последующем, пройдя свои стадии миграций, входят в фазы использования. Таким образом, можно говорить о многослойной модели системной архитектуры, в которой системная архитектура в различных слоях может находиться на различных стадиях жизненного цикла (см. рис. 8).

Рис. 8.

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

• анализ осуществимости;
• разработка технического задания;
• разработка технического проекта;
• разработка и документирование ПС;
• тестирование ПС;
• внедрение ПС;
• эксплуатация ПС;
• вывод ПС из эксплуатации.

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

Начальное документирование

Фазе жизненного цикла системной архитектуры «Начальное документирование» нет прямого соответствия в фазах ЖЦ программных средств. Содержательно эта фаза представлена функциями ее активных участников (см. табл. 1).

Таблица 1.

Использование

Фазе жизненного цикла системной архитектуры «Использование» соответствуют следующие фазы ЖЦ программных средств:

• Разработка технического задания на ПС.
• Разработка технического проекта ПС.
• Тестирование ПС.

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

Таблица 2.

Проектирование

Здесь может возникнуть вопрос: а куда делась разработка постановки задачи? И нужна ли она вообще? Фазе жизненного цикла системной архитектуры «Проектирование» соответствуют следующие фазы ЖЦ программных средств:

• Подготовка технического задания на ПС.
• Подготовка технического проекта ПС.

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

1. изменениями миссии или стратегии;
2. изменениями рыночной ситуации;
3. регулирующими органами.

После осознания этой потребности производится формулирование бизнес-требований, но все это происходит, когда мы еще находимся в слое бизнес-архитектуры (см. рис. 4). Стрелки от сущностей «Продукты» и «Документы», направленные к сущностям «Оборудование», «Программы» и «Данные», соответствуют постановке задачи (бизнес-требованиям). Вернемся к нашему примеру, из которого мы видим, что разработка ТЗ, ТП, тестирование и внедрение хранилища данных используют знания о системной архитектуре системы бухгалтерского учета, которая уже находится в промышленной эксплуатации, а ее системная архитектура в настоящий момент находится в фазе использования. Системная же архитектура хранилища данных в настоящий момент находится в фазе проектирования (см. рис. 8).
Функции активных участников фазы «Проектирование» представлены в табл. 3 .

Таблица 3.

Миграция

Фазе жизненного цикла системной архитектуры «Миграция» соответствуют следующие фазы ЖЦ программных средств:

• Тестирование программных средств.
• Внедрение программных средств.

Функции активных участников фазы «Миграция» представлены в табл. 4 .

Таблица 4.

Таким образом, системная архитектура реально затрагивается на следующих фазах ЖЦ программных средств:

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

Состав базы знаний по системной архитектуре

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

1. Текущая системная архитектура.
2. Перспективная (планируемая) системная архитектура.
3. Планы миграции.

Разделы «Текущая системная архитектура» и «Перспективная системная архитектура» имеют одинаковую структуру и состоят из следующих подразделов:

1. Принципы построения системной архитектуры.
2. Основные технические и технологические решения.
3. Требования и стандарты.
4. Прикладная архитектура.
5. Техническая архитектура.
6. Архитектура данных.

Принципы построения

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

Основные решения

Описываются главные технические и технологические решения, составляющие основу системной архитектуры. Например, это может быть решение об использовании ЭВМ AS/400 в качестве основной аппаратной платформы информационной системы банка или решение об использовании СУБД DB2 в качестве основного инструмента управления информационными ресурсами банка.
Каждое решение снабжается комментарием, поясняющим, каким образом данное решение соответствует сформулированным выше принципам построения системной архитектуры.
Главные решения, принимаемые в ходе проектирования системной архитектуры, оформляются отдельными документами, с кратким изложением предыстории, сути проблемы и принятого принципиального решения проблемы, обязательного в последующем при проектировании, разработке и внедрении информационной системы.

Требования и стандарты

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

Прикладная архитектура

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

Техническая архитектура

Сетевая архитектура

Содержит описания территориальной коммуникационной инфраструктуры и локальных вычислительных сетей (ЛВС).

Архитектура платформ

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

Архитектура данных

Базы и хранилища данных

Содержит описание баз данных и иным способом организованных информационных массивов.

Системы управления базами данных

Содержит описание используемых систем управления базами данных.

План миграции

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

Заключение

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

• Кто в банке выполняет ту или иную бизнес-функцию, насколько регулярно выполняет, какое событие вызывает выполнение этой бизнес-функции, автоматизировано или нет автоматизировано или выполнение этой бизнес-функции?
• Какая информация является входящей для той или иной бизнес-функции, кто является поставщиком этой информации, в каком виде она поступает?
• Какие программные средства используются для выполнения той или иной бизнес-функции, какие еще ИТ-функции выполняют эти программы, какие базы данных и справочники используются, какие экраны и какие отчеты формируются программой?
• Какая информация является входящей и выходящей для той или иной программы, в каком виде поступает входящая информация и формируется исходящая?
• Каким образом организовано информационное взаимодействие двух программ: через формирование/чтение файла, непосредственно через API, через электронную почту, через системы уровня middleware, какова структура информационного обмена, какова периодичность?
• Какие подразделения используют ту или иную программу, кого нужно уведомить при изменении программы или какого-либо регламента?
• Используется ли в настоящий момент та или иная ИТ-функция программы, кем используется, насколько часто?

Конечно, возникает также множество других вопросов, так или иначе связанных с системной и бизнес-архитектурой.
В силу ограниченного размера журнальной статьи разбор этих вопросов выходит за ее пределы. Отметим только, что для структуризации и документирования этих знаний возможностями программ MS Word или MS Excel не обойтись. Необходимо использование более развитых программных комплексов, но еще важнее использование соответствующих методик или даже методологий. Одним из таких руководств, которое, по опыту автора, удовлетворяет нужным требованиям, является «методология ARIS» (ARchitecture of Integrated Information System). Однако это совершенно другая тема, возможно, для другой статьи.

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

Поделитесь работой в социальных сетях

Если эта работа Вам не подошла внизу страницы есть список похожих работ. Так же Вы можете воспользоваться кнопкой поиск

Введение

1.3. Слои в архитектуре

Список литературы

Введение

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

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

1. Теоретические аспекты архитектуры предприятия

1.1. Ключевые элементы архитектуры предприятия

Управление архитектурой предприятия (Enterprise Architecture) создает основу для синхронизации объектов внутри предприятия и в то же время обеспечивает их непрерывное изменение для целей оптимизации бизнеса.

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

С одной стороны, детальность создаваемого описания означает более глубокую проработку, а с другой – появляются излишние трудозатраты, как на создание самого описания, так и на поддержку его в актуальном состоянии. Как говорится, «лучшее враг хорошего», и поэтому слишком подробное описание элементов архитектуры не приносит пользы. На этом этапе важно установить ключевые элементы архитектуры предприятия из всех возможных и сосредоточиться именно на их описании и анализе.

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

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

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

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

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

Для построения архитектуры данных необходимо выделить основные сущности и агрегировать на них все «кванты» информации, собранные из описания бизнес-процессов. Практика показывает, что для решения данной задачи следует использовать стандартную методологию описания данных – модель «сущность–связь» (Entity-Relationship Model – ERM), в рамках которой можно четко структурировать всю информацию. Следующий этап формализации ИТ-архитектуры – переход от архитектуры бизнес-процессов и архитектуры данных к созданию архитектуры приложений. На этом этапе важно определить классы информационных систем, необходимых для автоматизации, а также модули для каждой информационной системы. Основой для проектирования архитектуры приложений и ее синхронизации с бизнес-архитектурой является карта процессов (обобщенное представление всех бизнес-процессов предприятия). На модели архитектуры приложений располагаются основные типы информационных систем, которые далее детализируются на модели модулей информационных систем и далее до уровня отдельных экранных форм – транзакций.

Еще одним ключевым элементом архитектуры с точки зрения взаимосвязи бизнес-архитектуры и ИТ-архитектуры являются требования к информационной системе. Фактически модели требований – это целевой функционал ИТ-решения, который структурируется по бизнес-процессам или по подразделениям. На основании этих требований и существующих моделей бизнес-процессов, а также с учетом построенных моделей данных проектируется новая (целевая) архитектура приложений. При этом помимо методологий управления архитектурой предприятия для решения поставленных задач необходимо использовать и отраслевые стандарты. Например, в случае телекоммуникационных компаний в качестве основы можно использовать материалы методологии New Generation Operation System and Software (NGOSS), которая была создана в 2001 г. TeleManagement Forum и содержит следующие модели:

1. модель операций телекоммуникационной компании eTOM (Enhanced Telecom Operations Map – eTOM);
2. информационная модель телекоммуникационного предприятия (Enterprise-wide Information Framework Shared Information and Data Model – SID);
3. структура приложений телекоммуникационной компании ( Applications Framework – Telecom Applications Map – TAM ).

1.2. Модели и инструменты архитектуры приложений

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

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

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

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

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

1.3. Слои в архитектуре

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

Слои легко формализуются. Интуитивно понятно, что если система разбита на ряд слоев, то слой n – это компонент или набор компонентов системы, которые используют только компоненты слоя n-1 и могут быть использованы только компонентами слоя n+1.

Слои обладают простой и наглядной семантикой. Как правило, в архитектуре программной системы слои представляют уровни абстракции. Слой n+1 использует слой n, следовательно, абстракция понятий слоя n+1, по меньшей мере, не ниже чем у слоя n, а в идеале – если архитектура системы эффективна, его уровень абстракции должен быть выше. Соответственно, слой n скрывает (инкапсулирует) логику работы с понятиями определенными на этом слое, позволяя, таким образом, слою n+1 реализовать работу с более сложными понятиями, организовать более сложную логику, используя выразительные средства нижележащего слоя.

Слои широко распространены. Действительно, достаточно большое количество программных систем, особенно если речь идет о программных системах масштаба предприятия (enterprise systems), имеют именно слоистую структуру. Конечно, достаточно часто встречается ситуация, когда строгая послойная структура системы нарушается – как правило, это является следствием эрозии архитектуры (архитектурным дефектом) и ее устранение в большинстве случаев способно принести ощутимые выгоды (эти аспекты рассматриваются далее).

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

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

Схема архитектурных слоев обладает и определенными недостатками:

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

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

Для целей системного анализа архитектура предприятия может рассматриваться в двух аспектах:

1. статическом - по состоянию банка в некоторый фиксированный момент времени;
2. динамическом - как процесс перехода (миграции) банка от текущего состояния к некоторому желаемому состоянию в будущем.

Рассматриваемая в статике архитектура предприятия состоит из следующих элементов:

1. миссия и стратегия, стратегические цели и задачи;
2. бизнес-архитектура ;
3. системная архитектура .

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

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

1. сформулированные миссия и стратегия банка, стратегические цели и задачи;
2. бизнес-архитектура в текущем (as is) и планируемом (to be) состоянии,
3. системная архитектура в текущем (as is) и планируемом (to be) состоянии;
4. планы мероприятий и проектов по переходу из текущего состояния в планируемое.

Таким образом, планируемая системная архитектура является архитектурой «to be» только на определенном витке развития предприятия.

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

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

В архитектуре предприятия следует выделять следующие слои:

1. Фронт-офис (Front-Office)

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

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

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

1. Мидл-офис (Middle-office)

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

Примеры подразделений мидл-офиса:

Подразделение проверки заемщиков в службе безопасности,

Подразделение управления рисками.

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

Примеры информационных систем мидл-офиса:

Система ведения позиционного учета,

Система проверки заемщика в бюро кредитных историй,

Система расчета скорингового балла по кредитной заявке.

1. Бэк-Офис (Back-Office)

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

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

1. Учёт (Accounting)

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

1. Информационное хранилище (DWH)
2. Отчётность (Reporting)

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

Примеры систем отчётности:

Система управленческой отчётности,

Система аналитической отчётности,

Система ключевых показателей эффективности подразделений предприятия,

Система формирования показателей для расчёта скорингового балла по кредитной заявке.

Список литературы

1. Васильев Р. Б., Калянов Г. Н., Левочкин Г. А., Лукинова О. В. Стратегическое управление информационными системами; Интернет-университет информационных технологий, Бином. Лаборатория знаний - Москва, 2013 . - 512 c.
2. Гриценко Ю. Б. Архитектура предприятия: Учебное пособие / Гриценко Ю. Б. – 2011. 256 с.
3. Данилин А.В., СлюсаренкоА.И., Учебный курс – Архитектура предприятия [Электронный ресурс] - Режим доступа: http://www.intuit.ru/department/itmngt/entarc/
4. Калянов Г.Н. Моделирование, анализ, реорганизация и автоматизация бизнес-процессов. Учебное пособие: М.: Финансы и статистика, 2006.

PAGE 17

Другие похожие работы, которые могут вас заинтересовать.вшм>
803.		Архитектура гостиничного предприятия	36.04 KB
	Архитектурные аспекты построения и размещения гостиниц. Роль интерьера и дизайна гостиниц на гостиничное предложение. Введение Специфика гостиниц заключается в многообразии функций этих объектов. Благоприятные условия жизнедеятельности человека в гостиницах обеспечиваются благодаря созданию комфорта как в самом здании гостиницы так и на территории прилегающей к ней.
17390.		Архитектура Великого Новгорода	324.25 KB
	Преобладает точка зрения что старый город это так называемое Городище находящееся на правом берегу Волхова в двух километрах от современного города. Чтобы более глубоко познакомится с архитектурой этого города была работы выбрана тема Архитектура Новгорода XI-XV веков. Техника подобных произведений заключалась в том что по зачерненным медным листам резцом наносился рисунок и в его канавки вплавлялась золотая проволока. Ее можно отнести к древнейшим: доска на которой она написана очень старая по ряду признаков и характеру...
19556.		Сталинский вертикализм и архитектура	24.72 KB
	Для того чтобы уяснить специфику собственно советского пути и формообразования и содержания советской архитектуры нужно изучать ограничения и предписания которые накладывались общегосударственной организацией профессиональной деятельности на образ мыслей конкретных мастеров. и с другой - планы квартир сталинского ампира содержащих террасы гостиные комнаты для домработниц и проч.: Неоклассицизм неоклассика термин принятый в советском искусствознании для обозначения различных по социальной направленности и идеологическому...
17255.		Храмовая архитектура Москвы	595.99 KB
	Яркая окраска кирпичных стен церкви Троицы расчлененных нарядной декоративной отделкой из белого резного камня и цветных поливных изразцов покрытие из белого немецкого железа золотые кресты на зеленых черепичных главках все вместе взятое создавало неотразимое впечатление...
13405.		Архитектура Старовавилонского царства	528.04 KB
	Центром ее был город Вавилон Бабили означает Ворота бога цари которого во II тыс. Расцвет Старовавилонского царства пришелся на время правления шестого царя I Вавилонской династии Хаммурапи. При нем Вавилон из небольшого города превратился в крупнейший экономический политический и культурный центр Передней Азии.
7046.		Архитектура и структура ПК. Принцип фон Неймана	9.14 KB
	ПК называют относительно недорогой универсальный микрокомпьютер, рассчитанный на одного пользователя. Современные ПК проектируются на основе принципа открытой архитектуры.
6695.		Архитектура базы данных. Физическая и логическая независимость	106.36 KB
	Там приводятся следующие определения банка данных базы данных и СУБД: Банк данных БнД это система специальным образом организованных данных баз данных программных технических языковых организационно-методических средств предназначенных для обеспечения централизованного накопления и коллективного многоцелевого использования данных. База данных БД именованная совокупность данных отражающая состояние объектов и их отношений в рассматриваемой предметной области. Система управления базами данных СУБД совокупность языковых и...
18392.		Разработка учебно-методического комплекса по дисциплине «Архитектура ЭВМ»	606.23 KB
	Потом круг пользователей расширился в первую очередь за счет ученых использовавших вычислительные машины для проведения машинных экспериментов. Электронным учебником называется продукт образовательного характера который может быть воспроизведен только с помощью средств информатики в том числе и компьютера соответствующий утвержденной программе обучения или программе разработанной автором для предложенного курса и имеющий принципиально новые черты по сравнению с обычным учебником.п Электронный учебник может быть предназначен для...
9225.		АРХИТЕКТУРА И ЭЛЕМЕНТНАЯ БАЗА ЛОКАЛЬНЫЕ ВЫЧИСЛИТЕЛЬНЫХ СЕТЕЙ ЛА	150.96 KB
	Наступившие XXI столетие и третье тысячелетие все настойчивее ставят вопрос: какие летательные аппараты (ЛА) истребительной авиации обеспечат превосходство в воздухе? На поставленный вопрос следует однозначный ответ - ими станут истребители следующего, 5-го поколения, реактивной эры авиации. Провести четкую грань между поколениями ЛА трудно и не всегда возможно. Да и сама смена поколений процесс довольно медленный.
21769.		Процессоры Intel, архитектура процессоров, чипсеты и их характеристики	95.27 KB
	Центральный процессор (Микропроцессор, ЦП) - часть аппаратного обеспечения компьютера, отвечающая за выполнение арифметических операций, заданных программами, и координирующая работу всех устройств компьютера. Процессор представляет собой специально выращенный полупроводниковый кристалл, на котором располагаются транзисторы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Данный текст является ознакомительным фрагментом. Из книги Все о счетах-фактурах автора Клокова Анна Валентиновна

3.4. Счет-фактуру требуется исправить В предыдущих разделах анализировались ошибки, которые допускаются при заполнении счетов-фактур и возникновение последствий при предъявлении НДС к вычету по таким счетам-фактурам. Согласно пункту 1 статьи 169 НК РФ документом, служащим

Из книги Управление дебиторской задолженностью автора Брунгильд Светлана Геннадьевна

3. ЧТО ТРЕБУЕТСЯ ЗНАТЬ О КОНТРАКТАХ И ДОГОВОРАХ Надлежит законы и указы писать явно, чтоб их не перетолковывать. Правды в людях мало, а коварства много. Под них такие же подкопы чинят, как и под фортецию. Петр

Из книги Управление салоном красоты автора Шамкуть Ольга Владимировна

Что требуется 1. Документы о регистрации фирмы (форма собственности и устав).2. Договор аренды с регистрацией.3. Заключение СЭС.4. Заключение пожарной инспекции.5. Разрешение на деятельность от районной Управы (выдается бесплатно).6. Разрешение на торговлю сопутствующими

Из книги Новая эпоха - старые тревоги: Политическая экономия автора Ясин Евгений Григорьевич

Требуется политическая организация Итак, нужна демократия. Это сегодня уже не красивое слово, а жизненная потребность для страны. Но она должна опираться на какие-то социальные и политические силы, которые стали бы за демократию бороться. А что же наши демократы? Увы, они

Из книги Покажите мне деньги! [Полное руководство по управлению бизнесом для предпринимателя-лидера] автора Рэмси Дэйв

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

автора

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

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

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

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

Требуется переводчик Проблему дополнительно усложняет то, что каждый из четырех (PAEI) – типов вкладывает разный смысл в слова «быть», «хотеть» и «требоваться» исходя из своеобразия собственной картины мира.Предприниматель, как правило, принимает решения, воспринимая

Из книги Самое главное в PR автора Олт Филип Г.

Требуется: знание экономики Готовя себя к карьере специалиста по связям с общественностью, человек должен получить солидное образование в области экономики. Будучи принятым на работу в качестве профессионала, ему придется иметь дело с финансовыми аспектами

автора Джестон Джон

Шаг 6. Применение архитектуры Любая организация, желающая использовать архитектуру процессов, должна наладить необходимую дисциплину. Это означает, что все соответствующие проекты должны учитывать архитектуру и выявлять, где они отклоняются от согласованных

Из книги Управление бизнес-процессами. Практическое руководство по успешной реализации проектов автора Джестон Джон

Образец типовой архитектуры Обобщенные целевые показатели: в следующие три года обеспечить рост выручки от реализации на 200 %; обеспечить рост прибыли на 150 % в следующие три года.Общие принципы: наши корпоративные ценности: лучшая ценность за уплаченную

Из книги Теория ограничений Голдратта. Системный подход к непрерывному совершенствованию автора Детмер Уильям

Зачем нужно понятие «утверждение»? Для чего мы пользуемся понятием «утверждение»? Если говорится, что «пропущено какое-то утверждение», значит, в логическом дереве не упомянут некий важный элемент (причина, следствие, промежуточная цель или задача и т. д.). Используя

Из книги Истинный профессионализм автора Майстер Дэвид

Что для этого требуется? Если будет желание, то совсем не трудно создать внесенные в список преимущества. Возьмем, к примеру, совместного использования навыков и опыта в подразделении. Для этого требуется эффективно функционирующее подразделение, обладающее потенциалом

Из книги Практика и проблематика моделирования бизнес-процессов автора Всяких Е И

Глава 1 Зачем нужна модель бизнес-архитектуры: стандартные постановки задач по моделированию бизнес-процессов Во многом обоснование необходимости разработки модели бизнес-архитектуры связано с пониманием факторов, подталкивающих предприятие к поиску оптимизационных

Из книги Легко не будет [Как построить бизнес, когда вопросов больше, чем ответов] автора Хоровиц Бен

Требуется некоторый опыт Эти предпринимательские планы заставили вспомнить о собственном первом опыте работы с венчурными инвесторами.В 1999 году, получив первый транш финансирования для Loudcloud, мы с партнерами отправились к нашему новому инвестору – венчурному

Из книги Метод Сильвы. Искусство управления автора Сильва Хосе

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

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

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.