Remkomplekty.ru

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

Что такое архитектура системы

Архитектура ИС, типы архитектур. Классификация ИС

Основным критерием выбора архитектуры и инфраструктуры ИС в услових рыночной экономики является минимизация совокупной стоимости владения системой.

Из этого следуют два основных тезиса:

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

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

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

Основные идеологические определения архитектуры ИС таковы:

— Архитектура ИС — набор решений, наиболее существенным образом влияющих на совокупную стоимость владения системой;

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

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

Архитектура ИС – концептуальное описание структуры, определяющее модель, выполняемые функции и взаимосвязь ее компонентов, которое предусматривает наличие 3 компонент:

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

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

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

Управление информационными системами предусматривает выполнение следующих функций:

Управление качеством включает в себя: разработку корпоративных стандартов информационных систем, разработку соглашения об уровне обслуживания (Service Level Agreement — SLA), контроль качества сервисов, проектов.

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

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

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

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

Финансовое управление включает в себя: управление бюджетом, управление закупками, управление контрактами, управление основными средствами.

Виды архитектур:

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

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

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

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

Применительно к организации обычно используют понятие корпоративная архитектура (enterprise architecture), при этом выделяются следующие типы архитектур: бизнес-архитектура (Business architecture), ИТ-архитектура (Information Technology Architecture), архитектура данных (Data Architecture), архитектура приложения (Application Architecture) или программная архитектура (Software Architecture), техническая архитектура (Hardware Architecture). Совокупность данных архитектур и является архитектурой ИС (рис. 18.1).

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

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

ИТ-архитектура рассматривается в трех аспектах:

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

— среда, обеспечивающая реализацию бизнес- приложений;

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

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

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

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

Доменную архитектуру можно рассматривать как метамодель, описывающую множество решений.

Схемы классификации архитектур ИС, основанные на доменном подходе, показаны на рис. 1.2 и 1.3. На верхнем уровне выделяются два типа доменов: домены задач (Problem domains) (рис. 18.2) и домены решений (Solution Domains) (рис. 18.3).

Рис. 18.2. Классификация архитектур ИС, основанная на домене задач

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

Рис. 18.3. Классификация архитектур ИС, основанная на домене решений

В таблице 18.2 приведены требования, предъявляемые к отдельным характеристикам рассматриваемых типов ИС.

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

В стандарте ANSI/IEEE 1471-2000is дается следующее определение архитектуры: «фундаментальная организация системы, реализованная в ее компонентах, связях этих компонентов друг с другом и внешней средой и принципах, определяющих структуру и развитие системы».

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

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

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

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

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

Статический срез системной архитектуры на определённый момент времени включает:

  • архитектуру приложений — функциональный и компонентный состав информационной системы
  • архитектуру данных — способы взаимодействия систем и хранения данных
  • архитектуру оборудования — используемые технические средства/решения

Другими аспектами системной архитектуры являются:

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

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

Содержание

Архитектура приложений

Для каждой информационной системы, входящей в состав КИС, дает ответы на следующие вопросы:

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

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

Для каждой сущности, обрабатываемой/хранимой в КИС, дает ответы на следующие вопросы:

  • Какие таблицы
  • Какие информационные системы формируют, изменяют данные, используют данные
  • Кто владелец
  • Кто отвечает
  • Кто и как использует
  • Какие объёмы занимает и как быстро «прирастает»
  • С какими другими данными связана сущность

Архитектура оборудования

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

  • Какое оборудование используется
  • За кем закреплено
  • Кто отвечает
  • Где расположено
  • Из чего состоит
  • Что расположено
  • Темпы «прироста»

Ссылки

Wikimedia Foundation . 2010 .

Смотреть что такое «Системная архитектура» в других словарях:

СИСТЕМНАЯ АРХИТЕКТУРА — Организация и структура основных элементов информационной системы, имеющая принципиальное значение для функционирования системы в целом Словарь бизнес терминов. Академик.ру. 2001 … Словарь бизнес-терминов

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

Архитектура (значения) — В Викисловаре есть статья «архитектура» Архитектура искусство проектировать и строить здания и другие сооружения (та … Википедия

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

Архитектура IBM PC — Архитектура современного персонального компьютера это схема его чипсета, которую можно найти на сайтах производителей Intel и AMD.Чипсет это набор микросхем материнской платы для обеспечения работы процессора с памятью и внешними устройствами.… … Википедия

архитектура шины промышленного стандарта — шина ISA Системная 16 разрядная (8 МГц) шина компьютеров архитектуры IBM PC AT. Другое название AT bus. [http://www.morepc.ru/dict/] Тематики информационные технологии в целом EN Industry Standart ArchitectureISA … Справочник технического переводчика

Системная Глобальная Область — В СУБД, разработанных Oracle Corporation, Системной Глобальной Областью (от англ. System Global Area или сокр. SGA) называют часть оперативной памяти, разделяемой всеми процессами одного экземпляра базы Oracle. SGA содержит всю необходимую… … Википедия

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

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

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

Что такое архитектура системы

Введение

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

«Архитектура системы: единая фундаментальная структура системы, описанная в терминах поведения, ограничений, процессов, интерфейсов и элементов системы».
[базовое определение, одобренное INCOSE Systems Architecture Working Group на конференции INCOSE 1996 в Бостоне (Массачусетс) 8 июля 1996 года]

«Архитектура системы описывает основные физические свойства, стиль, структуру, взаимодействия и предназначение системы».
[Process for System Architecture and Requirements Engineering, Derek Hatley, Peter Hruschka, Imtiaz Pirbhai, Dorset House Publishing 2000]

«Архитектура — это набор концепций и правил, характеризующих структуру, семантическое поведение и взаимосвязь между компонентами системы; план конструирования чего-либо. В состав архитектуры входят элементы, образующие конструкцию, отношения между ними, ограничения на эти отношения, описание отдельных компонентов конструкции, а также описание конструкции в целом».
[Architecting with RM-ODP, Janis Putman, Prentice Hall PTR 2001, which references ISO/IEC 10746-2: Information Technology — Open Distributed Processing — Reference Model: Foundations, as the source]

«Архитектура — это структура компонентов программы (системы), взаимосвязей между ними и принципов их разработки и эволюции во времени».
[DoD 5000.59-P, «Modeling and Simulation Master Plan,» October 1995]

Архитектура — это «структура компонентов, взаимосвязей между ними и принципов их разработки и эволюции о времени».
[IEEE STD 610.12, extended slightly by the Integrated Architectures Panel (IAP) of the C4ISR Integration Task Force (ITF) in DoD Architecture Framework, Version 1.0]

Читать еще:  Не открываются несколько документов excel в linux

Хотя эти определения оперируют различными терминами и охватывают различные наборы аспектов, они во многом пересекаются. Все определения сходятся в том, что архитектура описывает следующие компоненты:

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

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

Точки наблюдения

Точка наблюдения (в контексты системы) — это «форма абстракции, которая достигается с помощью определенного набора архитектурных концепций и правил структурирования для того, чтобы сфокусироваться на определенных аспектах системы» [ISO/IEC 10746-2: Information Technology — Open Distributed Processing — Reference Model: Foundations]. В следующей таблице приведены примеры точек наблюдения для различных аспектов системы. Эти точки наблюдения соответствуют стандарту ISO/IEC 10746-1: Information technology — Open Distributed Processing — Reference Model: Overview.

Архитектура систем

Архитектура и структура являются свойствами систем.

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

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

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

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

Архитектуру и структуру нередко отождествляют с их описаниями. Следует заметить, что описаний и того, и другого можно составить множество, причем отличающихся. К примеру, словесных, в виде рисунка, схемы… В силу этого подобное отождествление представляется разновидностью подмены понятия. К примеру, есть человек и у него есть свойства «здоровье», или «настроение». Интуитивно все понимают, что это, но свести эти свойства живого человека к их описаниям означает обязательное упрощение и, при любых попытках сделать это, что-то существенное обязательно останется за пределами описания.

Можно сформулировать следующие рабочие определения понятий «структура» и «архитектура».

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

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

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

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

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

«Финансовая газета. Региональный выпуск», 2011, N 23

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

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

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

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

Читать еще:  Ошибка опаньки в гугл хром

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

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

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

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

Компания BAA, управляющая большинством крупных аэропортов в Соединенном Королевстве, выяснила, что основная проблема, по которой при строительстве затягиваются сроки и превышается бюджет, состоит в том, что контракты пытаются переложить большую часть рисков на подрядчиков. Поэтому при строительстве терминала 5 в аэропорте Хитроу была разработана особая форма контракта — так называемое соглашение T5. По нему BAA брала весь риск проекта на себя, а подрядчики работали объединенными коллективами в небольших подпроектах с согласованной сметой и премиально-рисковым фондом. В случае если стоимость подпроекта превосходила запланированные расходы, деньги для покрытия дополнительных затрат брались из премиально-рискового фонда. По завершении проекта средства из этих фондов были направлены на премирование рабочих групп.

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

Поппендик М. Бережливое производство программного обеспечения: от идеи до прибыли / Пер. с англ. — М.: Вильямс, 2010. — С. 218 — 219.

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

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

Система розничного магазина отвечает за автоматизацию всех процессов, связанных с перемещением и учетом товара в розничных торговых точках (кроме бухгалтерского учета).

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

Таким образом, системная архитектура отражает долгосрочные и ключевые договоренности между заказчиком и исполнителем. Как правило, она фиксируется в виде небольшого (около 10 — 20 страниц) документа. Помимо текста он включает наглядные схемы — графические проекции модели системы. Для его составления требуются опыт и квалификация. Главное, чтобы ключевые участники процесса разработки понимали этот документ одинаково и могли общаться в его терминах.

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

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

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

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

Ссылка на основную публикацию
ВсеИнструменты
Adblock
detector
×
×