Какие архитектурные перспективы вы рассматриваете как часть общего дизайна программного обеспечения?

Question

Когда кто-то использует термин «архитектура XXX», я склонен раздражаться. Это часто указывает на то, что есть другая архитектурная дисциплина или перспектива, которую я, вероятно, не рассматриваю. Какие перспективы архитектуры вы рассматриваете и есть ли у вас хорошие ресурсы для информации о них?

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

• Выживаемость
• Управление производительностью
• Оперативный мониторинг и управление
• Сервисная ориентация
• TOGAF определяет ряд атрибутов качества обслуживания

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

Answer 1

Архитектура и архитектурные решения в основном касаются «нефункциональных» требований системы; pace RoadWarrier, но каждая из вещей, о которых он упоминает, является следствием архитектурных решений, более чем независимых сами по себе. (Доказательство: что приводит к определенному выбору в любой из этих областей? Всегда необходимо удовлетворять некоторым нефункциональным требованиям.)

Имея это в виду, это проблема из двух частей. Во-первых, вам нужно решить, какие NFR важны. желательно, указав их с определенной конкретностью, используя строгий метод, например, не просто сказать «высокодоступный», скажем, «система должна быть доступна (MTTF / (MTTF + MTTR)) 99,99 процента, при этом наибольшее время простоя составляет 4 минуты. "

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

В домене business , скажем, в ИТ-системе, доступной через веб-интерфейс, вы можете, например, захотеть:

• надежность (MMTF)
• доступность (MTTF / (MTTF + MTTR))
• масштабируемость (система должна быть в состоянии добавить 10-процентную емкость в течение 72 часов при стоимости X)
• емкость (система должна поддерживать 1 миллион активных пользователей)
• пропускная способность (система должна обрабатывать 100 транзакций в секунду со средним значением & sigma; = 2,5 т / с)
• время отклика (при тестовой загрузке пользователь должен получить полную страницу за ≤ 2 секунд)
• безопасность (метрики здесь - тема для некоторой статьи)

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

Answer 2

РЕДАКТИРОВАТЬ : Поскольку вопрос изменился, я отредактировал свой ответ следующим образом.

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

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

В крупной бизнес-компании архитектура с нисходящей (организационной) точки зрения обычно разделяется примерно так:

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

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

• Правильное использование промежуточного программного обеспечения - слабая связь, отказоустойчивость, специфичные для цели преобразования, уничтожение точка-точка и т. Д.
• Выявление и разработка как можно большего количества сверок.
• Выявление и разработка как можно большего количества двойных ключей.
• Определение и разработка как можно большего количества ручных процессов.
• Определение и разработка любых компьютерных решений для конечных пользователей - например, Доступ к базам данных, электронные таблицы Excel.
• Выявление и разработка любого конечного пользователя для редактирования «ответа» - получение информации после завершения всех работ, а затем ее редактирование.
• Исследование полного жизненного цикла данных: кому принадлежит, кто его обогащает, кто его распространяет, единственная версия правды, удаляющая сверки.
• Определение показателей производительности и масштабируемости, тестирование рискованных областей по нескольким профилям данных.
• Идентификация в режиме реального времени в сравнении с пакетными процессами и интерфейсами и устранение зависимости между пакетами, где это возможно.
• Консолидация в единую платформу, где это возможно, и в одном экземпляре против нескольких
• Способность быстро справляться с новым ванильным бизнесом и новым сложным бизнесом в разумные сроки.
• Идентификация четкой модели поддержки, особенно в регионах, где это необходимо.
• Состояние обслуживания и восстановления - насколько хорошо можно восстанавливать ежедневные сбои обработки и интерфейса.
• Требования и возможности BCP / DR, общая отказоустойчивость, зависимости от глобальной сети.
• Где можно снизить риск проекта?
• Безопасность, доступ для конечного пользователя и разработчика, кольцо из стали вокруг производства.
• Какие средства отчетности по МИ имеются?
• Как можно больше подчеркивая простоту, вывод системы из эксплуатации.

Answer 3

• проверяемость
• Масштабируемость
• отказоустойчивость
• снижение производительности (изящно, можно надеяться)
• возможность обновления (аппаратное и программное обеспечение)

Кстати, это все причины, по которым мне нравятся корпоративные сервисные шины (ESB)!