1.3. Понятие архитектуры ис
Современные ИТ и ИС достигли такого уровня развития, когда на первый план выходит бизнес-оценка проектов, а не личные пристрастия разработчиков или заказчиков. В связи с этим большое внимание в настоящее время уделяется архитектуре ИС.
Термин "архитектура" в применении к ИС уже давно стал привычным, так как грамотное построение ИС, эффективно и надежно функционирующей, является не менее сложной задачей, чем проектирование и возведение современного многофункционального здания.
Архитекту́ра (лат. architectura ) - искусство проектировать и строить здания и другие сооружения (также их комплексы), создающие материально организованную среду, необходимую людям для их жизни и деятельности, в соответствии с современными техническими возможностями и эстетическими воззрениями общества. Постепенно классическое определение архитектуры трансформировалось в применении к техническим системам, как принципиальное устройство чего-либо сложного, общий вид, без указания конкретных инженерных расчетов.
Когда речь заходит об архитектуре ИС, то, прежде всего, следует задаться вопросом, зачем нужно само понятии архитектура и какую пользу можно извлечь из его существования. Ответ на этот вопрос применительно к программным системам можно найти, в частности, в [10], где ответ формулируется следующим образом.
Программная архитектура – это абстракция или модель, а точнее одна из ряда моделей, описывающих ИС, которая обычно создаются на этапе архитектурного проектирования, при этом ИС ставится в соответствие архитектурное описание, которое может быть полезным для решения, по крайней мере, 3 важных задач проектирования ИС.
1. Архитектурное описание, выполненное в соответствии с определенными правилами, может использоваться как язык общения между заинтересованными сторонами (архитектор, аналитик, программист, покупатель, пользователь) в процессе, как проектирования, так и эксплуатации.
2. Архитектурное описание, наряду с другими, более детализированными описаниями, может использоваться для генерации кода приложения. Такой подход называют проектированием с помощью моделей. Этот подход более подробно будет рассмотрен ниже.
3. Архитектурное описание может быть полезно при проектировании линеек или семейств продуктов, которые могут строиться на базе одной и той же архитектуры, что позволяет уменьшить стоимость разработки и уменьшает риски. Следует заметить, никогда не возникало недостатка в определениях понятия архитектура. На сайте SEI (Software Engineering Institute) имелся даже специальный раздел, посвященный определениям архитектуры, где их собрано более ста [11].
Рассмотрим несколько вариантов определения понятия "Архитектура ИС" [10]:
Архитектура – это организационная структура системы.
Архитектура ИС – концепция, определяющая модель, структуру, выполняемые функции и взаимосвязь компонентов информационной системы.
Архитектура – это базовая организация системы, воплощенная в ее компонентах, их отношениях между собой и с окружением, а также принципы, определяющие проектирование и развитие системы.
Архитектура – это набор значимых решений по поводу организации системы программного обеспечения, набор структурных элементов и их интерфейсов, при помощи которых компонуется система, вместе с их поведением, определяемым во взаимодействии между этими элементами, компоновка элементов в постепенно укрупняющиеся подсистемы, а также стиль архитектуры, который направляет эту организацию – элементы и их интерфейсы, взаимодействия и компоновку.
Архитектура программы или компьютерной системы – это структура или структуры системы, которые включают элементы программы, видимые извне свойства этих элементов и связи между ними.
Архитектура – это структура организации и связанное с ней поведение системы. Архитектуру можно рекурсивно разобрать на части, взаимодействующие посредством интерфейсов, связи, которые соединяют части, и условия сборки частей. Части, которые взаимодействуют через интерфейсы, включают классы, компоненты и подсистемы.
Архитектура программного обеспечения системы или набора систем состоит из всех важных проектных решений по поводу структур программы и взаимодействий между этими структурами, которые составляют системы. Проектные решения обеспечивают желаемый набор свойств, которые должна поддерживать система, чтобы быть успешной. Проектные решения предоставляют концептуальную основу для разработки системы, ее поддержки и обслуживания.
Для того чтобы разобраться в этом многообразии определений, выделим наиболее существенные стороны архитектуры ИС.
Основным критерием выбора архитектуры и инфраструктуры ИС в условиях рыночной экономики является минимизация совокупной стоимости владения системой. Из этого следует два основных тезиса.
В проектах построения ИС, для которых важен экономический эффект, должна выбираться архитектура системы с минимальной совокупной стоимостью владения.
Совокупная стоимость владения информационной системой состоит из плановых затрат и стоимости рисков. Стоимость рисков определяется стоимостью бизнес-рисков, вероятностями технических рисков и матрицей соответствия между ними. Матрица соответствия определяется архитектурой информационной системы.
Термин «Архитектура ИС» обычно довольно согласованно понимаются специалистами на уровне подсознания, и столь же несогласованно определяются.
Два основных класса определений архитектур — определения «конструктивные» и «идеологические».
Основные идеологические определения архитектуры ИС таковы:
«Архитектура ИС — это набор решений, наиболее существенным образом влияющих на совокупную стоимость владения системой».
«Архитектура ИС — это набор ключевых решений, неизменных при изменении бизнес-технологии в рамках бизнес-видения».
Оба эти определения согласованы в том смысле, что если ключевое решение приходится изменять при изменении бизнес-технологии в рамках бизнес-видения, то резко возрастает стоимость владения системой. Следствием этих определений является понимание важности принятия архитектуры системы как стандарта предприятия, ввиду значимости архитектурных решений и их устойчивости по отношению к изменениям бизнес-технологии. Еще одно важное следствие первого определения — архитектура системы на самом деле должна строиться еще на стадии технико-экономического обоснования системы.
Выделим несколько наиболее значимых и принципиально различных типов рисков:
проектные риски при создании системы;
технические риски, состоящие в простоях, отказах, потере или искажении данных и т. п.;
риски бизнес-потерь, связанные с эксплуатацией системы (возникающие, в конечном счете, из-за технических рисков). Такие риски бизнес-потерь назовем бизнес-рисками. Каждый бизнес-риск принадлежит, по крайней мере, одному из вариантов бизнес-использования (business use case) системы. Например, для интернет-магазина бизнес-риски «Покупатель не может сделать заказ и уходит» и «Покупатель делает заказ, но уходит рассерженный функционированием системы» принадлежат вариантам бизнес-использования «Сделать заказ».
риски бизнес-потерь, связанные с вариативностью бизнес-процессов. При этом потери происходят оттого, что:
а) бизнес-процессы надо изменять, а информационная система не готова к этому, и потери связаны с неоптимальным функционированием бизнеса;
б) приходится платить за модификацию системы.
Такие риски бизнес-потерь назовем неопределенностями (RUP упоминает аналогичные по смыслу «варианты изменения», change cases).
Затраты на создание и эксплуатацию системы с некоторой точностью оцениваются достаточно стандартно. Динамические же бизнес-риски количественно учесть невозможно, и их следует оценивать исключительно качественно (на уровне понимания, насколько бизнес-процессы в организации являются определенными/застывшими/неустоявшимися). Наиболее интересная часть совокупной стоимости владения системой — статические бизнес-риски и риски разработки.
Каждый вариант бизнес-использования реализуется с помощью набора операций соответствующих бизнес-процессов, а бизнес-риск возникает по причине неисполнения одной или нескольких операций. Такие риски мы называем операционными. Таким образом, операционные риски являются источниками бизнес-рисков.
Например, источниками риска «Покупатель не может сделать заказ и уходит» могут быть операционный риск «Информация о заказе не может быть передана для обработки в систему».
В свою очередь операционные риски для автоматизированных операций могут возникать по причине технических рисков. Например, операционный риск «Информация о заказе не может быть передана для обработки в систему» может возникнуть по причине реализации технического риска «Обрыв канала связи».
С другой стороны, бизнес-риск может быть парирован соответствующей организацией процесса и/или архитектурным решением.
Конструктивно архитектура обычно определяется как набор ответов на следующие вопросы:
что делает система;
на какие части она разделяется;
как эти части взаимодействуют;
где эти части размещены.
Таким образом архитектура ИС является логическим построением, или моделью, и влияет на совокупную стоимость владения через набор связанных с ней решений по выбору средств реализации, СУБД, операционной платформы, телекоммуникационных средств и т. п. — то есть через то, что мы называем инфраструктурой ИС. Еще раз подчеркнем, что инфраструктура включает решения не только по программному обеспечению, но и по аппаратному комплексу и организационному обеспечению. Это вполне соответствует пониманию системы в наиболее современных стандартах типа ISO/IEC 15288 [12].
В результате длительных обсуждений, которые происходили в течение 90-х годов прошлого века были выпущены 2 стандарта [5] и [6]. Первый стандарт назывался «Рекомендации по архитектурному описанию программных систем (IEEE Recommended Practice for Architectural Description of Software-Intensive Systems) появился в 2000 году, а второй появился в 2011 году и называется «Системная и программная инженерия – архитектурное описание». Второй стандарт является новой редакцией первого. В нем архитектура системная и программные архитектуры определяются следующим образом. Стандарт [6] определяет архитектуру как принципы организации системы, в терминах основных компонентов, их взаимосвязей, окружения и принципов проектирования и эволюции, а архитектурное описание как набор артифактов, составляющих описание архитектуры. Появление стандартов фактически положило конец дискуссиям о том, что такое системная и программная архитектура. Однако использовать данное определение применительно к корпоративным ИС затруднительно, поскольку корпоративные системы – это, прежде всего, многоуровневые системы. Кроме того, они имеют очень длительный жизненный цикл, длительность которого может измеряться десятилетиями. На протяжении всего жизненного цикли они постоянно развиваются.
Остановимся более подробно на КИС. С КИС обычно связывают такие понятия как корпоративная архитектура, корпоративная информационная система.
Корпоративная архитектура (Enterprise architecture (EA)) – эта методология для формирования проактивной холлистической реакции организации на внешние деструктивные воздействия посредством идентификации, анализа и формирования реакции с целью получения желаемого состояния бизнеса и результатов его функционирования. ЕА должна представлять руководству и, в частности, ИТ менеджерам, готовую информацию для принятия решений, выработку политик и формирование политик, направленных достижение максимальной эффективности функционирования организации [13].
Корпоративная информационная система (Enterprise Information System (EIS)) (КИС) – любая ИС, предназначенная для совершенствования реализуемых в организации бизнес-процессов посредствам их интеграции. КИС может работать на любых уровнях. Термин «корпоративная» (enterprise) в данном случае используется в самом широком смысле. Это может быть либо транснациональная корпорация, небольшая коммерческая фирма, образовательное учреждение, больница, некоммерческая организация и т.д. Особо следует отметить, что речь идет не только об организации в классическом понимании, но это может быть и виртуальная организация.
Корпоративная информационная архитектура (Enterprise information architecture (EIA)) (КИА) – это часть корпоративного архитектурного процесса. КИА предназначена для описания текущего состояния и прогнозировать изменение состояния с целью повышения качества функционирования системы. КИА оперирует такими понятиями требования, принципы, модели [14].
Из приведенных определений видно, что термин «корпоративная архитектура» определяется как система поддержки принятия решений, КИС – это, прежде всего, интеграционная система, а КИА – это элемент архитектурного процесса.
Приведенные определения фактически отражают только требования, но не дают никакой информации о принципах организации и функционирования КИС. Эта информация содержится в документе, который называется Корпоративный архитектурный фреймворк (Enterprise Architecture framework) [14]. В данном случае под термином фреймворк понимается эталонная реализация. Эта модель восходит к предложенной еще в 1988 году модели NIST Enterprise Architecture Model (Национальный институт стандартов и технологий - одного из агентств Министерства торговли США), в соответствии с которой модель описывается как 5 уровневая модель, в которой определяются следующие уровни (рис. 1.1).
бизнес архитектура (Business architecture);
ИТ архитектура (Information Technology Architecture) или информационная архитектура (Information Architecture),
архитектура данных (Data Architecture),
архитектура приложения (Application Architecture) или программная архитектура (Software Architecture),
техническая архитектура (Hardware Architecture). Совокупность данных архитектур и является архитектурой ИС
Бизнес архитектура или архитектура уровня бизнес процессов определяет бизнес стратегии, управление, организацию, ключевые бизнес процессы в масштабе предприятия, причем не все бизнес процессы реализуются средствами ИТ технологий. Бизнес архитектура отображается на ИТ архитектуру.
Рис. 1.1. Архитектурные уровни
ИТ архитектура рассматривается в трех аспектах:
обеспечивает достижение бизнес целей посредством использования программной инфраструктуры, ориентированной на реализацию наиболее важных бизнес приложений;
среда, обеспечивающая реализацию бизнес приложений;
совокупность программных и аппаратных средств, составляющая информационную систему организации и включающая, в частности, базы данных и промежуточное программное обеспечение.
Архитектура данных организации включает логические и физические хранилища данных и средства управления данными. Архитектура данных должна быть поддержана ИТ архитектурой. В современных ИТ системах, ориентированных на работу со знаниями, иногда выделяют отдельный тип архитектуры – архитектуру знаний (Knowledge Architecture).
Программная архитектура отображает совокупность программных приложений. Программное приложение – это компьютерная программа, ориентированная на решение задач конечного пользователя. Архитектура приложений – это описание отдельного приложения, работающего в составе ИТ системы, включая его программные интерфейсы. Архитектура приложения базируется на ИТ архитектуре и использует сервисы, предоставляемые ИТ архитектурой.
Техническая архитектура характеризует аппаратные средства, системное ПО и включает такие элементы, ОС, процессор, память, жесткие диски, периферийные устройства, элементы, используемые для их соединения, а также сетевые средства.
Часто нельзя провести четкой границы между ИТ архитектурой и архитектурой отдельного приложения. В частности, в случае, когда некоторую функцию требуется реализовать в нескольких приложений, то она может быть перенесена на уровень ИТ архитектуры. Обычно приложения интегрируются средствами ИТ архитектуры.