Remkomplekty.ru

IT Новости из мира ПК
0 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Статистика использования архитектурного подхода

Архитектурный подход к развитию ИТ-комплекса предприятия

Евтюшкин А.В.
доцент кафедры
«Системы управления бизнес-процессами».
Школа IT-менеджмента
РАНХиГС при Президенте РФ

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

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

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

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

Рис. 1. Архитектурный подход.

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

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

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

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

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

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

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

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

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

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

Ниже предлагается упрощенная методика описания двух верхних уровней: архитектуры деятельности и архитектуры прикладных систем предприятия. Учитывая, что технологическая архитектура определяется архитектурой прикладных систем, этого достаточно для начала.

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

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

В Табл. 1 левая колонка «Деятельность» представляет собой примерный перечень видов деятельности предприятия. Приведенная структура видов деятельности относится к производственному предприятию. Инвариантным является перечень категорий деятельности:

  • Производство.
  • Логистика.
  • НИОКР.
  • Снабжение.
  • Сбыт.
  • Финансы.
  • Управление.
  • Обеспечивающая деятельность.

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

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

Для сервисных предприятий к категории “Производство” должны относиться те виды деятельности, которые формируют добавленную стоимость. У торговых или финансовых предприятий категория “Производство” может отсутствовать полностью.

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

Прежде всего необходимо заполнить колонку «Текущее состояние». В каждой из ячеек колонки должны быть перечислены все информационные системы, которые используются при осуществлении соответствующего вида деятельности. Если какая-то информационная система используется в нескольких видах деятельности, она должна упоминаться во всех этих видах. Не рекомендуется указывать инфраструктурные и общесистемные элементы (“локальная вычислительная сеть”, “СУБД Oracle”, “Операционная система Linux”, “Электронная почта” и т.п.), а также офисные программы общего назначения. Исключение – Excel, если при осуществлении какого-либо вида деятельности этот табличный процессор используется вместо полноценной информационной системы (часто в этих случаях применяется специальное приложение на базе Excel).

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

Читать еще:  Архитектура открытых систем

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

Таблица 1. МАТРИЦА ПОДДЕРЖКИ ДЕЯТЕЛЬНОСТИ ПРЕДПРИЯТИЯ
ИНФОРМАЦИОННЫМИ СИСТЕМАМИ

Основные понятия архитектурного подхода

Рассмотрим основные определения, которые формируют фундамент архитектурного подхода (табл. 1.2).

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

  • — ISO/IEC 15288:2008 (IEEE Std 15288-2008) Systems and software engineeringSystem life cycle processes («Системная и программная инженерия. Процессы жизненного цикла системы»);
  • — ISO/IEC/IEEE 42010:2011(E) — Systems and software engineeringArchitecture description («Системная и программная инженерия»);
  • — ISO 15704-2000 Industrial automation systemsRequirements for enterprise-reference architectures and methodologies («Системы промышленной автоматизации. Требования к эталонным архитектурам предприятия и методологиям»).
  • — ISO 9000:2005. Системы менеджмента качества. Основные положения и словарь.

Определения стандарта IS0/IEC 42010:2007

Архитектура — фундаментальная организация системы, воплощенная в ее компонентах, их взаимосвязях друг с другом и со средой, а также руководящие принципы проектирования и развития системы (ISO/IEC 42010:2007). Описание (модель) основного устройства (структуры) и связей частей системы (физического или концептуального объекта или сущности) (.ISO 15704:2000)

Architecture — the fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution (ISO/IEC 42010:2007).

A description (model) of the basic arrangement and connectivity of parts of a system (either a physical or a conceptual object or entity) (ISO 15704:2000)

Архитектура предприятия (АП):

(1) Фундаментальная организация предприятия либо как целого, либо вместе

с партнерами, поставщиками и/или покупателями («расширенное предприятие»), либо части (например, бизнес- направление, департамент), а также

(2) руководящие принципы его проектирования и развития

Enterprise architecture (EA):

(1) the fundamental organization

of a government agency or a corporation, either as a whole, or together with partners, suppliers and / or customers («extended enterprise»), or in part (e.g. a division, a department, etc.) as well as

(2) the principles governing its design and evolution (The Open Group, TOGAF 2003)

деятельность по осмыслению, определению, выражению, документированию, сертификации надлежащей реализации, поддержке, совершенствованию архитектуры на протяжении всего жизненного цикла системы (ISO/ IEC/IEEE 42010:2011(E))

Architecting — process of conceiving, defining, expressing, documenting, communicating, certifying proper implementation of maintaining and improving an architecture throughout a system’s life cycle (ISO/IEC/IEEE 42010:2011(E))

Архитектурное описание — рабочий продукт, используемый для выражения архитектуры (ISO/IEC/IEEE 42010:2011 (Е))

Architecture description — work product used to express an architecture (ISO/IEC/IEEE 42010:2011(E))

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

Предприятие — одна или несколько организаций, разделяющих определенную миссию, цели и задачи для получения выхода (результата) в виде продукции и услуг (ISO 15704:200с)) [1] .

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

В табл. 1.3 перечислены основные определения стандарта ISO/IEC/ IEEE 42010:2011(Е).

Определения стандарта ISO/IEC/IEEE 42010:2011(E)

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

Stakeholder — an individual or organization having a right, share, claim, or interest in a system or in its possession of characteristics that meet their needs and expectations

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

Concern — interest in a system relevant to one or more of its stakeholders

Группа описанийпредставление системы в целом с точки зрения связанного набора интересов (INCOSE Ru).

Представлениеописание системы в целом с точки зрения связанного набора интересов (В. К. Батоврин)

View — a representation of a whole system from the perspective of a related set of concerns;

— work product expressing the architecture of a system from the perspective of specific system concerns

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

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

Viewpoint — work product establishing the conventions for the construction, interpretation and use of architecture views to frame

Окончание табл. 1.3

установления назначений и [целевой] аудитории для группы описаний, а также приемы их создания и анализа (INCOSE Ru).

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

specific system concerns (версия 2007 г. — a specification of the conventions for constructing and using a view. A pattern or template from which to develop individual views by establishing the purposes and audience for a view and the techniques for its creation and analysis)

Артефакт — результат архитектурной работы, отражающий один из аспектов архитектуры

Artifact — an architectural work product that describes an aspect of the architecture (TOGAF glossary)

Рассмотренные в табл.1.2 и 1.3 понятия представлены на рис. 1.6.

Рис. 1.6. Концептуальная схема архитектурного описания

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

Пример многоаспектного архитектурного описания предприятия

Точка зрения / Метод описания / Ракурс (Viewpoints)

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

Общая картина («ландшафт») процессов, возможно, в индивидуальном формате.

Политики, карты стратегий, дерево целей и показателей. Матрицы ответственности

Четкое понимание правил игры, ожиданий руководства, последовательности действий, распределения ответственности

Регламенты процесса (текст или таблица).

Должностные инструкции. Карты операций и технологические инструкции

Аналитики, сотрудники — владельцы процессов

Оптимизация структур и процессов

Стандартные нотации представления процессов (нотации IDEFO, IDEF3, BPMN, ЕРС и т. д.), возможно, специальные отчеты. Процесс во взаимосвязи с другими процессами и объектами управления (цели, показатели, структуры. )

Специалисты по IT

Постановка задач для ИТ-решений в рамках подготовки к внедрению информационных систем

Стандартные нотации представления процессов (IDEF3, DFD и т. д.).

Таблицы информационных структур

Создание партнерств, совместных предприятий, аутсорсинг

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

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

Контролирующие и сертифицирующие организации. Система внутреннего контроля

Проверка соответствия управления компанией требованиям стандартов (IS09000, 14000, отраслевые стандарты по безопасности труда, закон Sarbanes-Oxley, внутренние стандарты и т. п.)

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

Специальные таблицы соответствия требований и фактической организации

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

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

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

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

Читать еще:  События в архитектуре

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

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

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

  • [1] Адаптировано из ISO 9000:2005.

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

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

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

1.Комплексный метод проектирования

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

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

Комплексное проектирование предусматривает:

а) творческое применение познаний о человеке, природе и обществе в их глубоком взаимопроникновении;

б) соединение теории и типологии архитектуры с проектированием;

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

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

Комплексное проектирование как информационный метод

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

2.Метод структурного анализа

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

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

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

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

Комплексный метод предусматривает проведение структурного анализа системы на каждом этапе ее разработки.

Конечная цель процесса — создание целостной композиции проектируемого объекта.

3.Содержание и форма объекта

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

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

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

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

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

Внешняя форма объекта выражает внутреннее построение и создается во взаимосвязи с другими объектами пространственной среды, в которых объект розміщається.

Специфическое ориентирование объекта к окружающему пространству выступает как качественное своеобразие его построения.

4.Взаимодействие внешнего и внутреннего

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

Проектирование объекта как системы дает понимание связи объекта с внешней средой. Градостроительный подход определяет каждый архитектурный объект как систему, которая входит в состав другой, более сложной пространственной системы; относительно нее первая система выступает как компонент. Да, жилой дом — система относительно его компонентов — секции и квартир, в то же время он один из компонентов пространственной системы — группы домов или ансамбля. Внешняя и внутренняя структура всегда находятся в единстве и взаимопроникновении.

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

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

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

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

Функциональный метод раскрывает внутренние связки, обусловленные назначением здания, технологическими процессами, которые происходят в данной материальной оболочке. Принцип целесообразности, «пользы» архитектурного произведения раскрывается в стремлении наилучше удовлетворить материальные и духовные потребности общества при умном минимуме расходов. На функциональные требования влияют уровень развития техники и экономики, особенности быта и культуры, климатические и топографические условия. Приступая к проектированию, архитектор определяет обязательные (закономерные) и необязательные (желаемые) функциональные связки. Этой цели служит методика составления функционально оперативных схем для записи информации о состоянии объекта, используя аппарат теории графов [124, стор.11 — 21].

Разработка объемно планировочной структуры, композиции шире функционального решения. Функциональная схема не может использоваться в качестве реальной эстетичной структуры. «Форма определяется функцией, но превосходит ее, поскольку художественное воображение может ее сопровождать без убытка для нее» [Ф. — Л. Райт, 184, стор.245].

Существенно для методики комплексного проектирования введения понятия «поведения» объекта, который определяет взаимодействие компонентов внутри системы во времени. Процессы, которые происходят в объекте, показывают динамику, вместе с тем пространственная структура здания дает им статическое выражение. Преодоление этого противоречия находит свое отображение в идее гибкого пространственного решения как жилищных, так и общественных зданий. «Одного функционирования для искусства недостаточно — вместе с тем. не найдется никого, кто стал бы утверждать, что красивому разрешено плохо функционировать» [Г.Б. Бархин, 62, стор.37].

Проектирование архитектуры предприятия: выбираем ИТ-инструменты

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

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


Информационные технологии являются неотъемлемым атрибутом любого предприятия

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

Читать еще:  Разработка архитектуры по

Цикл развития архитектуры предприятия

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

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

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

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

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

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

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

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

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

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

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

EA tools (Enterprise Architecture tools) — это набор инструментов, ориентированный на моделирование архитектуры предприятия. Инструменты этой группы должны позволить связывать различные разрозненные типы данных в единое целое. Одной из основных особенностей продуктов класса Enterprise Architecture Tools является возможность не только моделировать различные элементы деятельности компании (программно-аппаратные средства, бизнес-процессы, приложения, интерфейсы, организационная структура, стратегические цели), но и интегрировать их.

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

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

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

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

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

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

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

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

В создании архитектурной модели обычно участвуют четыре процесса: вычеркивание — отбор опыта; конструирование — композиция модели из отдельных элементов; искажение — отбрасывание несущественных элементов; обобщение — выделение относительно устойчивых свойств предприятия.

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

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

Разделив компанию на части,
Не найти ни истины, ни счастья.
Только построение системы
Позволяет нам раздвинуть стены.

Ссылка на основную публикацию
Adblock
detector