Типы архитектурных решений — Мир ПК

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

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

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

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

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

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

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

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

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

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

Архитектура ИС – концептуальное описание структуры, определяющее модель, выполняемые функции и взаимосвязь ее компонентов, которое предусматривает наличие 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 приведены требования, предъявляемые к отдельным характеристикам рассматриваемых типов ИС.

Требования к различным типам ИС

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

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

Не нашли то, что искали? Воспользуйтесь поиском:

Лучшие изречения: Студент — человек, постоянно откладывающий неизбежность. 11311 — | 7592 — или читать все.

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

Анализ области решений

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

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

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

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

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

Под архитектурой ПО понимают набор внутренних структур ПО , которые видны с различных точек зрения и состоят из компонентов , их связей и возможных взаимодействий между компонентами , а также доступных извне свойств этих компонентов [1].

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

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

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

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

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

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

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

  Архитектура ПО: разница между архитектурой и проктированием

  

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

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

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

  Характеристики архитектуры ПО

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

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

  Архитектурные шаблоны программного обеспечения

  Большинство из вас, наверно, уже знакомы с термином « микросервисы». Микросервисы — один из способов моделирования архитектуры ПО, наряду с многоуровневой архитектурой, архитектурой, управляемая событиями, бессерверной архитектурой и многими другими. Некоторые из вышеперечисленных шаблонов будут описаны ниже. Микросервисный стиль архитектуры стал известным после того, как его стали успешно применять в Amazon и Netflix. А теперь, давайте углубимся в детали и более подробно обсудим архитектурные стили.

  ** Внимание: пожалуйста, не путайте архитектурные стили с шаблонами проектирования, такими как фабричный шаблон проектирования или адаптерами. Я расскажу о них позже.

  Бессерверный архитектурный стиль

  Этот элемент применим к приложениям, которые в качестве решения используют сервисы третьих лиц для того, чтобы решить проблему загруженности серверов и бэкенда. Бессерверная архитектура делится на две основные категории. Первая это «бэкенд как услуга (BaaS)», вторая — «функция как услуга (FaaS)». Бессерверная архитектура поможет сэкономить время на проверке и исправлении ошибок переноса, а также на работе с регулярными задачами сервера.
  Самым известным примером бессерверного API является сервис Amazon AWS «Lambda».

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

  Архитектура, управляемая событиями

  Эта архитектура завязана на производителях и потребителях событий. Главная идея состоит в том, чтобы разделить части вашей системы так, чтобы каждая из частей активизировалась, когда интересное событие происходит в другой. Сложно? Давайте упростим. Представьте, что вы создаете систему для онлайн-магазина и она состоит из двух частей: модуль покупок и модуль продаж. Когда клиент совершает покупку, модуль покупок создает событие «orderPending». Так как модуль продаж заинтересован в этом событии, он будет следить за процессом на случай, если его вызовут. Как только модуль продаж получит это событие, он выполнит определенные задания или запустит ещё одно событие для продолжения покупки товаров у определенного вендора.

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

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

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

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

  

  Проектирование программного обеспечения

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

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

  Принципы SOL >Single Responsibility, Open Closed, Liskov substitution, Interface Segregation and Dependency Inversion Principles ) — это единственная ответственность, открытость/закрытость, принцип подстановки Барбары Лисков, принцип разделения интерфейсов и принцип инверсии зависимостей.

  • Принцип единственной ответственности означает, что каждый класс работает только над одной целью, ответственен только за неё и изменяется только по одной причине.
  • Принцип открытости/закрытости: класс должен быть открытым для расширения, но закрытым для изменений. Проще говоря, вы можете добавлять новую функциональность в класс, но не можете редактировать существующие функции таким образом, что они будут противоречить используемому коду
  • Принцип подстановки Барбары Лисков: согласно этому принципу, разработчик должен соблюдать наследственность таким образом, чтобы нигде не нарушалась логика приложения. Так, если новый класс «Xy >Принцип разделения интерфейсов: Всё просто: класс способен реализовывать множество интерфейсов, создавайте свой код таким образом, чтобы классу никогда не приходилось реализовывать функцию, которая не важна для его задач. Вывод — разделяйте свои интерфейсы на категории.
  • Принцип инверсии зависимостей: Если вы когда-либо использовали TDD для создания своего приложения, вы знаете насколько важно расщеплять свой код перед тестированием и моделированием. Другими словами, если определенный класс «ex:Purchase» зависит от класса «Users», установка пользовательских объектов должна инициировать снаружи класса «Purchase».

  Шаблоны проектирования

  • Фабричная модель — самый часто используемый шаблон проектирования в мире OOП, так как он позволяет сэкономить много времени в будущем, когда потребуется изменить один из классов, который вы использовали. Рассмотрим на примере:

  Представим, что вы хотите реализовать модель класса пользователей Users(), — вы можете использовать один из двух методов:

  1 — $users = new Users();
  2 — $users = DataFactory::get(‘Users’);

  

  Я бы выбрал второй, по двум основным причинам, помимо всех остальных. Во-первых, изменение названия класса с «Users» на «UserData» — это всего лишь одно изменение в одном месте, внутри фабричной базы, в остальном ваш код остается тем же. Во-вторых, если в классе «Users» появятся такие параметры как Users($connection), то вам останется только внести изменения в одном месте, а не в каждой функции которая использует объекты класса Users. Поэтому, если вы думаете, что первый вариант лучше, подумайте ещё раз.

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

  Представьте,что ваше приложение работает по API c YouTube и, чтобы получить токен доступа, вам необходимо вызвать функцию getYoutubeToken();

  

  Итак, вы вызвали эту функцию в 20 разных местах в приложении.

  

  А потом, Google публикует новую версию API, переименовав функцию на getAccessToken();

  

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

  

  

  В последнем случае, единственное, что вам придется сделать — изменить одну строку, все остальное приложение продолжит работать как раньше.

  

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

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

  Описание архитектуры ИТ-решения не самая простая практика. И уж точно не следует приступать к её освоению с заполнения шаблона описания архитектуры. Тем не менее, такого рода шаблоны существуют и кто-либо из представителей заказчика информационной системы не редко требует описать архитектуру. Обычно, такого рода запрос поступает от персонажа, именуемого главным архитектором, и потому я возьму на себя смелость дать несколько рекомендаций о том, как это следует делать. Обычно, в качестве шаблона используются производные от RUP-овского Software Architecture Document просмотреть который можно, например, здесь. Существенно реже можно встретить TOGAF-овский Architecture Definition Document и уж вряд ли вам попадется ISO-шный Architecture description. Поэтому ориентироваться будем на первый шаблон. Разделы такого документа кроме введений и определений включают следующий набор архитектурных представлений:

  • Use-case view
  • Logical view
  • Process view
  • Deployment view
  • Implementation view
  • Data view (optional)

  В общем, все в строгом соответствии с моделью архитектуры «4+1 architectural view model» от Philippe Kruchten (Иногда к перечисленным разделам добавляют описания программных интерфейсов. Я же люблю дополнять этот документ разделом «Открытые вопросы и предположения».) Казалось бы, все просто. Берем книжку по UML и начинаем рисовать картинки. Сначала UML диаграмму вариантов использования, потом диаграмму классов и т.д… А вот и ни разу не так!

  Замечание 1. Разработка архитектуры решения – это процесс, состоящий, как минимум, из следующих этапов:

  1. Анализ и структурирование в виде моделей требований и прочей проектной информации. Кстати, для значительного количества моделей, полученных в ходе структурирования проектных данных, раздела в шаблоне не найдется. Это не значит, что их не надо включать в описание архитектуры.
  2. Выбор варианта реализации.
  3. Описание варианта реализации.
  4. Согласование предложенной архитектуры.

  Это надо учитывать при планировании и оценке трудоемкости. Кроме того, каждый этап требует различных действий. На первом этапе мы не собираем требования. Сбор требований – задача аналитика и в том или ином виде они должны быть. Мы внимательно их читаем, уточняем, задаем вопросы и структурируем их в виде моделей. Это может быть итеративный процесс внесения структуры в поток требований, но такой поток должен быть. Нет требований – нет архитектуры. Далее. Выбирать и согласовывать вариант реализации лучше до того, как мы плотно займемся его описанием. Меньше придется переписывать. Непосредственно проектирование, т.е. придумывание из головы чего-то нового, занимает незначительную часть времени. Как правило, за нас все уже придумали и потому:

  Замечание 2. Традиционный процесс проектирования не подходит для большинства проектов. Обычно в проектах используются уже готовые системы, так называемые COTS (Commercial off the shelf ) или уже существующие ИТ-решения. И потому все перечисленные модели надо основывать на описании уже существующих приложений. Правда, частенько, таких документов не существует и вот их приходится собирать(создавать заново). Тем не менее, вы не можете придумать заново ни свою модель данных, ни компонентную структуру системы, ни варианты использования. Все что вы можете сделать, так это «вписать» требования в существующие решения. Иначе, в худшем случае ваша архитектура нанесет непоправимый вред существующей системе, нарушив её концептуальную целостность, а в лучшем – вашу архитектуру просто выкинут и сделают по-своему. С данными ситуация не самая сложная. Все сущности, которые вы хотите реализовать в системе, должны являть частными случаями уже существующих сущностей. В каком-то смысле это напоминает отношение наследования в диаграмме классов. Но не всегда архитектура используемой системы позволяет реализовать отношения наследования. Чаще работа заключается в том, что вы берете существующую модель данных и придумываете набор типов (стереотипов) для того, что вам нужно на этой модели создать: создаете список типов обращений, придумываете поля заявок и workflow их обработки и т.п. С компонентами – хуже. В принципе, готовая программная платформа должна поставлять вам узлы(nodes, говоря языком UML) для создания и развертывания ваших новых компонент. SQL server(узел) служит для того, чтоб вы создавали собственные компоненты со стереотипами таблица, отношение, хранимая процедура и т.д., BPMS – для моделей процессов, джава-портал — для создания портлетов и т.п. Но когда речь заходит не о программных платформах, а о бизнес-приложениях все становиться загадочным и туманным. Готовое решение, вроде бы есть, но достоверных данных о том, как его следует использовать, что и где на ней нужно создавать и развертывать нет. Это не правильно. Я бы воздержался от использования таких систем.

  Замечание 3. На каком уровне детализации остановиться? Безусловно, ответ на этот вопрос зависит от целей разработки описания архитектуры. Обычно, мы делаем описание архитектуры решения для проекта. Для того, чтоб распланировать фазу «реализация», успешно произвести разработку(доработку) ИТ-систем, осуществить их развертывание и ввод в эксплуатацию. Потому и детализация должна быть достаточной для решения этих задач. Каждый квадратик с архитектурных рисунков превращается в строчку проектного плана, а стрелочки показывают взаимозависимость работ. Практически как на UML диаграмме развертывания. Зависимость одного компонента от другого говорит о том, что нет смысла приступать к его разработке не дождавшись хотя бы спецификации программного интерфейса от второго компонента. Вообще, все эти квадратики нужны для того, чтоб можно было выделить набор работ, которые можно будет вести параллельно, не таская всех участников проекта на многочасовые совещания. Наличие архитектуры помогает сохранить доверие между командами или индивидуумами, позволяя им действовать независимо друг от друга. Как правило, в отдельный набор задач можно вынести закупку лицензий и оборудования и разработку ПО. Описание процессов позволяет разделить разработку с подготовкой и согласованием инструкций и регламентов. Внутри разработки одна команда идет писать базу данных, другая бизнес-логику, третья – отчетность четвертая интеграцию с внешними источниками и т.д. Если кто-то настаивает на излишней детальности архитектурного описания и не может ответить на вопрос — зачем это нужно, то данного персонажа следует вежливо послать. Можно использовать и более миролюбивую модель процесса проектирования – каждый создает свой раздел документа, а архитектор сводит все в единое целое. В общем, конечно, замечания довольно поверхностные. Кому-то они могут показаться банальными (но тогда возьмите и допишите в эту заметку свой раздел). Но, если не следовать хотя бы этим рекомендациям, смысла в проектировании ИТ-решений будет не много