Архитектура предприятия

 

Лекция 1

Тема лекции: «Стратегические компоненты архитектуры предприятия»

1.      Роль и место информационных технологий в управлении предприятием.

2.      Применение архитектурных подходов в сфере информационных технологий.

3.      Компоненты архитектуры предприятия.

1.      РОЛЬ И МЕСТО ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ В УПРАВЛЕНИИ ПРЕДПРИЯТИЕМ.

 

1.1.            Моделирование бизнес-процессов.

 

В современной практике моделирования управленческой и производственной  деятельности для обозначения объектов моделирования принято использовать термин «бизнес-процесс».

 

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

 

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

 

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

 

-  руководителей (владельцев бизнес-процессов);

 

- контроля эффективности и качества бизнес-процессов;

 

- управления несоответствующей продукцией;

 

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

 

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

 

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

 

- прием на работу и обучение персонала происходит сам собой; 

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

- результат процессов всегда положительный — брака не бывает;

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

 

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

 

- TQM (Total Quality Management) — система всеобщего управления  качеством;

 

- PIQS (Process Integrated Quality System) — система менеджмента качества, интегрированная с бизнес-процессами;

 

- WFMS (Work Flow Management System) — система управления  потоками работ;

 

- ERP (Enterprise Resource Planning) — комплексная система планирования и управления ресурсами организации.

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

 

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

 

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

 

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

 

Характерным примером являются программные продукты класса ERP.

 

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

 

В системе R/3 (компания SAP) процессы описаны по определенной методике и существует программное средство (ARIS for R/3), позволяющее просматривать и редактировать поддерживаемые системой  процессы.

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

2.      Второй элемент бизнес-процесса – собственно выполнение работы (например, изготовление продукции).

 

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

 

3.      Третий элемент бизнес-процесса – группа функций по регистрации фактической информации по выполнению процесса.

 

На практике, как правило, — это функции учета: производственного, управленческого, бухгалтерского и т.п.

 

4.      Четвертым элементом бизнес-процесса являются функции по контролю и анализу  исполнения плановых показателей.

 

5.      Пятый элемент бизнес-процесса – функции принятия управленческих решений в рамках  процесса.

 

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

 

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

 

1. 2.  Методы управления с использованием информационных технологий.

 

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

 

1. Планирование потребности в материалах (Material Requirement Planning - MRP I).

 

2. Планирование потребности в производственных мощностях (Capacity Resource Planning — CRP).

 

3. Замкнутый цикл планирования материальных ресурсов (CL MPR).

 

4. Планирование ресурсов производства (Manufacturing Resource Planning - MRP II).

5. Производство на мировом уровне (World Class Manufacturing — WCM).

 

6. Планирование ресурсов предприятия (MRP II & FRP (Finance Resource Planning), Enterprise Resource Planning — ERP I).

 

7. Оптимизации управления ресурсами (ERP II).

 

8. Менеджмент как сотрудничество (Customer Relationship Management — CRM, Customer Synchronized Relationship Management — CSRM).

1.3.  Методологии описания бизнес-процессов.

 

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

 

1. Теоретическая база;

 

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

 

3. Рекомендации по использованию как отдельно, так и в составе группы методик.

 

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

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

 

Коротко рассмотрим историю развития методологий моделирования бизнес-процессов.

 

Основой методологий IDEF0 и IDEF3, широко используемых в настоящее время для моделирования бизнес-процессов, явились методология SADT и  алгоритмические языки, использовавшиеся для разработки программного  обеспечения. Методология SADT была разработана частной американской корпорацией и затем в рамках программы Министерства обороны США была преобразована в методологию IDEF0, утвержденную как федеральный стандарт США.  Появление методологии IDEF0 было предопределено тенденциями развития  вычислительных средств — мощных машин (Mainframe) и появлением подходов MRP.

 

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

 

Использование подхода MRP, попытки автоматизации производства при помощи вычислительных машин привели к необходимости описывать деятельность  организаций еще на стадии проектирования систем. Кроме того, задачи создания сложных систем управления (в том числе военного назначения) требовали  соответствующих инструментов разработки. Необходимость создания методологий моделирования процессов была обусловлена практической необходимостью. Для моделирования деятельности организаций на верхнем уровне использовалась  методология SADT, затем IDEF0. Подход UML (Unified Modeling Language — универсальный язык моделирования) предназначен для моделирования работы объектно-ориентированного программного обеспечения, а не бизнес-процессов организации.

 

После появления персональных компьютеров стали разрабатываться  различные инструментальные средства (программные продукты) для моделирования бизнес-процессов. Кроме средств моделирования процессов, активно  развивалось направление моделирования данных. Появлялись программные средства, в основном ориентированные на разработку моделей данных организаций и настройку промышленных баз данных. Такие программные продукты  получили название CASE-систем. Среди наиболее известных продуктов для  моделирования бизнес-процессов можно назвать Design/IDEF, BPWin, CASE-аналитик (в России), Silverrun, Designer-2000 и т.д.

 

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

 

1. Методологии ведения проекта;

 

2. Методологии моделирования и анализа бизнес-процессов;

 

3. Методологии использования программных продуктов для моделирования бизнес- процессов в проекте.

 

Последовательно рассмотрим каждую из трех групп методологий.

 

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

 

 

Кроме методологии Хаммера и Чампи, существуют и другие методологии, не имеющие однозначного авторства, но принадлежащие отдельным компаниям, например, методологии выполнения проектов по внедрению систем  автоматизации Oracle, SAPR/3, BAAN, RUP компании Rational и др.

 

 

Ко второй группе методологий относятся методологии моделирования и  анализа бизнес-процессов. В настоящее время существует несколько базовых способов описания процессов, основанных как на стандартах (IDEF0), так и на  общепринятых подходах (DFD). Кроме того, существует ряд нотаций (методологий)  описания процессов, предложенных отдельными компаниями — разработчиками программных продуктов. К числу последних относятся методологии ARIS (еЕРС) компании IDS Scheer AG, Германия.

 

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

 

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

 

Можно ввести  следующее определение термина «моделирование бизнес-процессов» организации:

 

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

 

Модель «как есть» (от «as is» — англ.) — это модель бизнес-процесса,  построенная на основе субъективного видения бизнес-процесса, существующего в  организации. При построении модели «как есть» важно помнить, во-первых, о субъективности, во-вторых, об актуальности модели. Дело в том, что в крупных организациях постоянно происходят изменения. Модель процессов может стать  неактуальной (несоответствующей) уже через несколько месяцев после ее создания.  Поэтому описание процесса должно использоваться в рабочих документах по процессу, постоянно подвергаться корректировке с целью обеспечения  соответствия реальной деятельности

 

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

 

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

 

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

 

2.   ПРИМЕНЕНИЕ АРХИТЕКТУРНЫХ ПОДХОДОВ В СФЕРЕ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ.

 

2.1. Понятие и общее представление об архитектуре предприятия.

 

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

 

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

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

 

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

 

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

 

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

 

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

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

 

Задачи курса «Архитектура предприятия»:

 

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

 

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

 

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

 

- уметь пользоваться основными методическими приемами различных архитектурных подходов (модель FEAF, TOGAF, FEA, методики IBM и Microsoft и т.д.);

 

- получить навыки разработки архитектуры предприятия на основе построения ее «снизу-вверх» от бизнес-архитектуры до технологической архитектуры.

 

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

 

С одной стороны, представление о нем имеет свои корни в дисциплине, которая получила название «системное мышление». Основным объектом изучения этой дисциплины является система, когда «целое составляет нечто большее, чем механическая сумма составляющих, то есть система обладает свойствами, которые отсутствуют у составляющих ее элементов» [(Rechtin, 1991)].

 

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

 

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

 

Архитектура предприятия (Enterprise Architecture, EA) является одним из инструментов организационных изменений как для всего предприятия в целом (в том числе с использованием ИТ), и так и той части организации, которая отвечает за информационные технологии.

 

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

 

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

 

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

 

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

Требования к стандартным архитектурам предприятия и методологиям  установлены национальным стандартом Российской Федерации  ГОСТ Р ИСО 15704-2008 «Промышленные автоматизированные системы. Требования к стандартным архитектурам предприятия и методологиям».

 

Настоящий стандарт идентичен международному стандарту ИСО 15704:2000 «Промышленные автоматизированные системы. Требования к стандартным архитектурам предприятия и методологиям» (ISO 15704:2000 «Industrial automation systems - Requirements for enterprise-reference architectures and methodologies (IDT)).

В настоящем стандарте применены следующие термины с соответствующими определениями:

 

(3.1.) ДЕЯТЕЛЬНОСТЬ.

 

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

 

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

 

(3.2.)  АРХИТЕКТУРА.

 

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

 

Примечание. Существует только два типа архитектур, имеющих отношение к интеграции предприятия, а именно:

 

a) системные архитектуры (называемые иногда архитектурами «типа 1»), действие которых распространяется на проектирование системы, например, на компьютеризированную, являющуюся частью системы интеграции предприятия;

 

b) стандартные проекты предприятия (называемые иногда архитектурами «типа 2»), действие которых распространяется на организацию разработки и выполнения проекта, например, интеграцию предприятия или другую программу развития предприятия.

 

(3.3.) ПРИЗНАК (АТРИБУТ).

 

Признак (атрибут) – часть информации, устанавливающей свойство сущности (объекта).

 

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

 

(3.4.) ПОВЕДЕНИЕ.

 

Поведение – реакция или действие всей системы или ее частей.

 

(3.5.)  БИЗНЕС-ПРОЦЕСС.

 

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

 

(3.6.) ПРЕДПРИЯТИЕ.

 

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

 

Примечание.  Этот термин включает в себя такие связанные понятия, как «расширенное предприятие» или «виртуальное предприятие».

 

(3.7.) ИНЖИНИРИНГ ПРЕДПРИЯТИЯ.

 

Инжиниринг предприятия – дисциплина, применяемая для выполнения любых работ по созданию, изменению или реорганизации любого предприятия.

 

(3.8.) МОДЕЛЬ ПРЕДПРИЯТИЯ.

 

Модель предприятия – представление о том, чего предприятие планирует достичь и как оно работает.

 

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

 

(3.9.) СРЕДА, СТРУКТУРА, ОСНОВА.

 

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

 

Примечание. Ни рассматриваемая структура, ни увязка частей друг с другом не имеют жизненного цикла или временной связи в отличие от стандартной архитектуры предприятия («тип 2»).

 

(3.10.) ОБЩНОСТЬ.

 

Общность – степень, до которой понятие является общим.

 

(3.11.) ЖИЗНЕННЫЙ ЦИКЛ.

 

Жизненный цикл – конечный набор общих фаз и этапов, через которые система может проходить в течение своей истории жизни.

 

(3.12.) ИСТОРИЯ ЖИЗНИ.

 

История жизни – фактическая последовательность этапов, через которые прошла система в течение своей жизни.

 

(3.13.) ГЕНЕРАЛЬНЫЙ ПЛАН.

 

Генеральный план – документация по планированию основных работ по инжинирингу и операциям, подготавливаемым до проведения любой крупной интеграции предприятия или другого системного проекта по инжинирингу.

 

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

 

(3.14.) МЕТОДОЛОГИЯ.

 

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

 

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

 

(3.15.) МИССИЯ.

 

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

 

(3.16.) МОДЕЛЬ.

 

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

 

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

 

(3.17.) ОРГАНИЗАЦИЯ.

 

Организация – структура предприятия и распределение обязанностей и полномочий на предприятии.

 

(3.18.) РЕСУРС.

 

Ресурс – сущность (объект) предприятия, обеспечивающая определенную или всю способность, необходимую для выполнения деятельности предприятия и/или бизнес-процесса.

 

(3.19.) СТРУКТУРА.

 

Структура – определение связей между составными частями организации.

 

(3.20.) СИСТЕМА.

 

Система – совокупность предметов реального мира для установленной цели.

 

Примечание. Система характеризуется структурой и ее поведением.

 

2.2.  Базовая модель архитектуры предприятия.

 

Архитектура системы (предприятия) представляет стратегическую информационную основу, которая определяет:

- структуру бизнеса;

- информацию, необходимую для проведения этого бизнеса;

- технологии, применяемые для поддержания деловых операций;

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

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

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

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

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

Приведенное определение качественно описывает базовое понятие архитектуры.

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

В качестве исходной для представления базовой схемы можно использовать модель архитектуры предприятия (Enterprise Architecture Model), предложенную национальным институтом стандартов и технологий США (National Institute of Standards and Technology - NIST), представленную на рисунке 1.

 

Бизнес-архитектура

(Управляет)→

Информационная архитектура

(Предписывает)→

 

Архитектура информационных систем

(Идентифицирует)→

 

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

(Поддерживается посредством) →

 

Архитектура систем доставки HW, SW, коммуникации.

↑Обратная связь

Рисунок 1. Схема архитектуры компьютеризированного предприятия по NIST.

 

(HW – hardware – аппаратное обеспечение; SW – software –  программное обеспечение).

 

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

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

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

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

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

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

2.3. Основные цели создания архитектуры предприятия.

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

 

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

- сохранение взгляда на целое в стратегической перспективе;

- исключение провалов в устройстве системы и при ее эксплуатации;

- создание основы и критериев для оценки частных архитектур;

- оптимальное планирование инвестиций предприятия.

3.  КОМПОНЕНТЫ АРХИТЕКТУРЫ ПРЕДПРИЯТИЯ.

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

 

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

 

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

 

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

 

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

 

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

 

С одной стороны, можно достаточно быстро сформулировать интуитивное определение, которое после анализа окажется вполне применимым. С другой стороны, при формальном подходе известных определений архитектуры существует несколько сотен. Для этого достаточно зайти на сайт Института Проектирования Программного Обеспечения Карнеги-Меллона (SEI – Carnegie Mellon Software Епgineering Institute) http://www.sei.cmu.edu/architecture/ и просмотреть представленные там трактовки. Из самых простых (словарь Уэбстера) заключается в том, что ИТ-архитектура   – это «способ, который используется для организации и интеграции компонент компьютерной системы».

 

Более полное и объемное определение [(Monin)] заключается в том, что «Архитектура системы состоит из нескольких компонент, внешних свойств и интерфейсов, связей и накладываемых ограничений, а также архитектуры этих внутренних компонент». Такая широкая трактовка удобна тем, что является достаточно общей, применимой практически к любой системе, а не обязательно только к системе, использующей информационные технологии, и при этом позволяет ограничить степень детализации на нужном уровне. Упоминание внутренних компонент специально перенесено в конец определения - для отражения того факта, что «хорошая», четко построенная архитектура позволяет обеспечить повторное использование или модернизацию/замену таких внутренних компонент без изменения внешней охватывающей системы. Итеративное, иерархическое построение архитектуры позволяет решить и еще одну важную задачу - облегчить ее восприятие человеком.

 

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

 

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

 

Прежде чем привести полное определение Архитектуры ИТ, обратим внимание на еще одну немаловажную деталь. В соответствии с тезисом, сформулированным Giga Group [(The Pillars of Enterprise Architecture Terminology, 2002)] «в индустрии ИТ нет одного, единственно правильного стандарта на определение Архитектуры ИТ, поэтому общие соглашения внутри организации важнее теоретической точности». Итак, важна не столько академическая точность определения того, что такое Архитектура ИТ, сколько то, насколько на практике в реальности будут воплощены архитектурные принципы. Организация может и сама сформулировать и принять для себя определение данного понятия, лишь бы оно было полным, целостным и понятным всем участникам проекта по разработке архитектуры.

 

Проанализировав большое количество рекомендаций, материалов аналитических компаний, таких как Gartner и Giga Group, теоретических и практических наработок в области архитектурных подходов в сфере ИТ можно сделать следующий вывод: их трактовки имеют больше общего, чем отличий, и значит есть возможность сформулировать некоторый общий подход.

 

В соответствии с определениями Gartner [(Defining Architecture for IT: А Framework of Frameworks, 2002)],     архитектура  –  это 

 

- «общий план или концепция, используемая для создания системы, такой как здание или информационная система, или «абстрактное описание системы, ее структуры, компонентов и их взаимосвязей»;

 

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

 

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

 

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

 

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

 

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

 

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

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

 

Согласно ISO 15704 («Industrial Automation Systems - Requirements for Enterprise-Reference Architectures and Methodologies. 1999») архитектура предприятия должна включать роль людей, описание процессов (функции и поведение) и представление всех вспомогательных технологий на протяжении всего жизненного цикла предприятия.

 

В соответствии с документом «Federal Enterprise Architecture Framework. Dev. by: The Chief Information Officers Council (USA)» архитектура является стратегической информационной основой, которая определяет:

 

- структуру бизнеса;

 

- информацию, необходимую для ведения бизнеса;

 

- технологии, применяемые для поддержания бизнес-операций;

 

- процессы преобразования, развития и перехода, необходимые для реализации новых технологий в ответ на изменение/появление новых бизнес-потребностей.

 

Надо отметить, что кроме вышеперечисленных общих трактовок данного понятия, в данной области существуют и разработки крупных компаний. Например, в исследовании Технологической академии IBM архитектура EA определяется следующим образом:

 

«Дисциплина EA определяет и обслуживает архитектурные модели, механизм управление и инициативы по переходу, необходимые для эффективной координации частично автономных групп для решения бизнес-задач- и/или ИТ-задач (М. Ибрагим, 2008)».

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

описание архитектуры (architecture description) - отражение объективной или планируемой реальности в какой-либо документированной форме.

 

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

 

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

 

В дальнейшем термин «архитектура» будет использоваться в зависимости от контекста, обозначая как существующую реальность, так и соответствующее ей описание.

 

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

 

Однако этот стандарт не определяет структуру, собственно, «Архитектуры предприятия». Например, говорится о том, что необходимо иметь различные представления архитектуры, но при этом не указывается, какие это должны быть представления.

 

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

 

В частности, можно выделять такие подмножества, как системная архитектура (архитектура систем - System Architecture) и программная архитектура (архитектура программного обеспечения - Software Architecture). На практике, в зависимости от контекста, термин «системная архитектура» может относиться либо к архитектуре ИТ-системы предприятия (в дополнение к бизнес-архитектуре) или даже в еще более узком смысле к технологической инфраструктуре информационной системы, либо - к архитектуре сложного продукта или семейства продуктов, выпускаемых предприятием.

 

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

 

Так, для программной архитектуры традиционными являются следующие перспективы или уровни описания архитектуры:

                      

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

 

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

 

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

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

 

В частности, хорошее введение в предмет программной архитектуры и в специфику профессии программного архитектора представляет собой работа [(Monin, 2007)]. Другим интересным примером анализа различных аспектов деятельности Программного архитектора являются публикации Д. Бредемейера (http://www.bredemeyer.com/).

3.1. Компоненты архитектуры предприятия.

Выделяют следующий набор компонентов архитектуры.

Двигатели архитектуры (Architecture Drivers) отражают внешние стимулы изменения архитектуры: бизнес-стимулы и технические стимулы.

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

В роли технических двигателей могут выступать новое и улучшенное программное обеспечение, аппаратные средства ЭВМ и их комбинации.

Стратегическое направление (Strategic Direction) - руководство для разработки целевой архитектуры, которое содержит видение миссии предприятия, принципы его построения, цели и объекты предприятия.

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

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

Переходные процессы (Transitional Processes) поддерживают переход от текущей архитектуры к целевой архитектуре. Критические переходные процессы для предприятия включают планирование инвестиций в сферу ИТ, планирование перехода, управление конфигурацией, контроль и управление проектом.

Архитектурные сегменты (Architectural Segments) отражают ориентацию отдельных частей общей архитектуры на главные бизнес - области.

Архитектурные модели (Architectural Models) определяют бизнес - модели и конструкторские (технические) модели, которые отражают все необходимые сегменты для полного описания предприятия.

Стандарты (Standards) включают все стандарты, руководящие принципы (руководящие материалы), а также передовой опыт. Примерами стандартов являются:

- стандарты безопасности;

- стандарты данных (относятся к данным, метаданным и другим связанным структурам);

- стандарты приложений (относятся к прикладному ПО);

- стандарты технологий (относятся к операционным системам и аппаратным платформам).

 

СПИСОК РЕКОМЕНДУЕМОЙ ЛИТЕРАТУРЫ.

 

 

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

 

[2] Калянов Г. Н. Консалтинг: от бизнес-стратегии к корпоративной информационно-управляющей системе. Учебник для вузов. 2-е изд., доп. – Горячая линия-Телеком М., 2014. –  210 с. 

[3] Кудрявцев Д.В., Арзуманян М.Ю.,  Григорьев Л.Ю. Технологии бизнес-инжиниринга.  Учебное  пособие / под редакцией Д.В. Кудрявцева. — СПб.:  Изд-во Политехн. ун-та, 2014.

 

[4] Информационные системы и технологии в экономике и  управлении: Учебник  /под ред. проф. В.В. Трофимова. — М.: Высшее  образование, 2006. –  480 с.

[5] Репин В.В., Елиферов В.Г. Процессный подход к управлению. Моделирование бизнес-процессов. – М.: РИА «Стандарты и качество», 2004 – 408 с. (Серия «Практический менеджмент»).