Fruitsekta.ru

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

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

Software Design

Популярно о проектировании программ

Обо мне

Ярлыки

  • .net (1)
  • архитектура (4)
  • литература (2)
  • маркетинг (4)
  • планирование (4)
  • проектирование (14)
  • собеседование (4)
  • требования (8)
  • триз (2)
  • управление проектами (12)
  • Фаулер (2)
  • функциональный анализ (13)
  • халтура (1)
  • эргономика (5)
  • c# (1)
  • concept (2)
  • estimate (5)
  • ITGM (1)
  • singularity (1)
  • SPM Club (2)
  • usability (5)
  • use-case (2)

понедельник, 5 декабря 2011 г.

Отзыв на книгу Фаулера «Архитектура корпоративных приложений»

9 комментариев:

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

Наоборот, Фаулера уважаю. Просто честно отметил, как достоинства, так и недостатки. Конечно, с моей точки зрения.

1) Про объем — авторы книг получают деньги за объем. Поэтому почти в каждой книге плотность информации очень низкая, особенно в книгах по архитектуре.
2) Про содержание — Фаулер не автор этих паттернов, он лишь популяризатор, для него «шлюз таблицы» примерно на одном уровне с «active record» находится.

К сожалению большинство книг по архитектуре пишутся именно так.

У меня есть книга «Архитектурное проектирование жилых зданий». Как-то незаметно, чтобы авторы старались раздуть объём. Наоборот, мне кажется, они постарались вместить больше информации в меньший объём.

Странно, почему в книгах, посвящённых software architecture это не так?

>Книга не содержит описания архитектур, хотя в названии используется слово «архитектура».

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

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

Пример. Оглавление книги «Архитектурное проектирование жилых зданий»:

Глава 1. Общие сведения о жилище.
1.1. Жилая среда как объект проектирования.
1.2. Основные типы жилых зданий.
1.3. Виды жилой застройки.

Глава 2. Основные факторы, влияющие на проектирование жилища.
2.1. Социальные требования к жилищу.
2.2. Демография населения и структура жилого фонда.
2.3. Эстетика жилища.
2.4. .

Глава 3. Методика проектирования.
3.1. Предпроектный анализ.
3.2. Комплексная разработка проектов.
3.3. .

Глава 4. Функциональные основы формирования квартир.
4.1. .

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

При всем моем уважении к Мартину Фаулеру. Его книга вовсе не образец книги по архитектура ПО. Кроме того. в книге дается явное ограничение: корпоративные приложения, т.е. типовые решения в исторической ретроспективе именно для бизнес-приложений. Понятию архитектура в ней посвящено три абзаца. Кроме того оригинальное название звучит совершенно иначе, чем русский вариант. Это уже маркетинговый ход Вильямс.

Если говорит об книгах о архитектуре, то следует в первую очередь смотреть хотя бы Басса.
А еще лучше — http://www.viewpoints-and-perspectives.info

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

1. понятие архитектуры — http://ru.wikipedia.org/wiki/%C0%F0%F5%E8%F2%E5%EA%F2%F3%F0%E0 — Очевидно, что за сотни тысяч лет человечество действительно научилось делать это и как искусство и превратило в точную науку.

2. вы же сами ранее определили архитектуру как список функций (в ответе на мой комментарий). Однако обратите внимание на содержательную часть цитируемого вами оглавления: среди факторов функциональные факторы недоминантные.

Эдуард, по названию согласен. В оригинале книга называется «Patterns of Enterprise Application Architecture». Тем не менее, я не отказываюсь от своей точки зрения — книге действительно не хватает системности.

Читать еще:  В приложении ок произошла ошибка

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

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

Software Design

Популярно о проектировании программ

Обо мне

Ярлыки

  • .net (1)
  • архитектура (4)
  • литература (2)
  • маркетинг (4)
  • планирование (4)
  • проектирование (14)
  • собеседование (4)
  • требования (8)
  • триз (2)
  • управление проектами (12)
  • Фаулер (2)
  • функциональный анализ (13)
  • халтура (1)
  • эргономика (5)
  • c# (1)
  • concept (2)
  • estimate (5)
  • ITGM (1)
  • singularity (1)
  • SPM Club (2)
  • usability (5)
  • use-case (2)

понедельник, 5 декабря 2011 г.

Отзыв на книгу Фаулера «Архитектура корпоративных приложений»

9 комментариев:

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

Наоборот, Фаулера уважаю. Просто честно отметил, как достоинства, так и недостатки. Конечно, с моей точки зрения.

1) Про объем — авторы книг получают деньги за объем. Поэтому почти в каждой книге плотность информации очень низкая, особенно в книгах по архитектуре.
2) Про содержание — Фаулер не автор этих паттернов, он лишь популяризатор, для него «шлюз таблицы» примерно на одном уровне с «active record» находится.

К сожалению большинство книг по архитектуре пишутся именно так.

У меня есть книга «Архитектурное проектирование жилых зданий». Как-то незаметно, чтобы авторы старались раздуть объём. Наоборот, мне кажется, они постарались вместить больше информации в меньший объём.

Странно, почему в книгах, посвящённых software architecture это не так?

>Книга не содержит описания архитектур, хотя в названии используется слово «архитектура».

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

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

Пример. Оглавление книги «Архитектурное проектирование жилых зданий»:

Глава 1. Общие сведения о жилище.
1.1. Жилая среда как объект проектирования.
1.2. Основные типы жилых зданий.
1.3. Виды жилой застройки.

Глава 2. Основные факторы, влияющие на проектирование жилища.
2.1. Социальные требования к жилищу.
2.2. Демография населения и структура жилого фонда.
2.3. Эстетика жилища.
2.4. .

Глава 3. Методика проектирования.
3.1. Предпроектный анализ.
3.2. Комплексная разработка проектов.
3.3. .

Глава 4. Функциональные основы формирования квартир.
4.1. .

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

При всем моем уважении к Мартину Фаулеру. Его книга вовсе не образец книги по архитектура ПО. Кроме того. в книге дается явное ограничение: корпоративные приложения, т.е. типовые решения в исторической ретроспективе именно для бизнес-приложений. Понятию архитектура в ней посвящено три абзаца. Кроме того оригинальное название звучит совершенно иначе, чем русский вариант. Это уже маркетинговый ход Вильямс.

Если говорит об книгах о архитектуре, то следует в первую очередь смотреть хотя бы Басса.
А еще лучше — http://www.viewpoints-and-perspectives.info

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

1. понятие архитектуры — http://ru.wikipedia.org/wiki/%C0%F0%F5%E8%F2%E5%EA%F2%F3%F0%E0 — Очевидно, что за сотни тысяч лет человечество действительно научилось делать это и как искусство и превратило в точную науку.

2. вы же сами ранее определили архитектуру как список функций (в ответе на мой комментарий). Однако обратите внимание на содержательную часть цитируемого вами оглавления: среди факторов функциональные факторы недоминантные.

Читать еще:  Что такое ошибка 80070020

Эдуард, по названию согласен. В оригинале книга называется «Patterns of Enterprise Application Architecture». Тем не менее, я не отказываюсь от своей точки зрения — книге действительно не хватает системности.

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

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

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

Влияние архитектуры приложений на инфраструктуру

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

Например, компания Delta Air Lines построила свою «Нервную Систему», которая использует при работе с данными принцип «публикации и подписки» для управления операциями и работы с клиентами. Эта инфраструктура работает так, что каждый, кому это необходимо, будет получать точную информацию о статусе полета, экипажах и пассажирах. Однако архитектура этой инфраструктуры не обеспечивает адекватные возможности по созданию прикладных систем для таких задач, как планирование прибыли, что является критически важной проблемой для обеспечения прибыльности операций и распределения ресурсов, или развертывания ERP-системы для управления административными процессами. Таким образом, различные бизнес-процессы требуют разную по характеру среду информационных технологий, отличающуюся производительностью, надежностью и пр. Для решения этой проблемы в компании Delta Air Lines была сформулирована концепция » архитектурного стиля «, которая определяет архитектурный стиль как некоторую совокупность корпоративных технологий и операционных сред, ориентированных на обслуживание определенного класса бизнес-процессов [4.21].

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

С этой точки зрения, оправдана следующая классификация прикладных систем [4.21], [4.22] с пятью различными архитектурными стилями:

  • Приложения, обслуживающие большое количество транзакций (Transaction Processing). Примеры: биллинг у телекоммуникационных операторов, резервирование авиабилетов, обработка транзакций по кредитным картам.
  • Операции в реальном времени (Real-Time Operations). Примеры: транспортные операции в аэропорту, мониторинг пациентов в клинике.
  • Аналитические приложения, бизнес-аналитика, поддержка принятия решений (Analytical and Business Intelligence). Примеры: интенсивный анализ больших массивов данных в поисках закономерностей, прогнозирование, принятие решений о выдаче кредита.
  • Приложения поддержки совместной работы (Collaborative). Примеры: средства асинхронного взаимодействия (электронная почта, дискуссионные форумы, групповые календари), средства синхронного взаимодействия (мгновенный обмен сообщениями – instant messaging ), средства управления контентом и библиотечные сервисы ( каталогизация и поиск информации, создание электронных библиотек и цифровых архивов документов и пр., портальные сервисы для внутреннего использования служащими).
  • Корпоративные и обслуживающие (Utility) приложения. Этот стиль характерен для многих стандартных систем, таких как ERP, CRM, системы управления персоналом, системы расчета заработной платы.

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

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

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

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

  • стратегические потребности;
  • бизнес-требования;
  • отличительные характеристики;
  • интегрирующие технологии.

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

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

На практике ключевыми должны являться такие вопросы, как:

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

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

Таблица 6.1. Требования и характеристики основных типов прикладных систем

Процессы с большим количеством транзакцийОперации в реальном времениАналитические процессы и бизнес-аналитикаСовместная работаКорпоративные (обслуживающие)
Стратегические потребности
  • Предоставление услуг
  • Время реакции системы
  • Способность дать объяснение
  • Поддержка принятия решения
  • Распространение знаний
  • Скорость
  • Инновации
  • Надежность
  • Низкая стоимость с точки зрения ИТ
Бизнес-требования
  • Обслуживание клиентов
  • Уменьшение затрат
  • Работа 24*7
  • Целостность данных
  • Экономичность и безопасность
  • Работа 24*7*365
  • Повышение эффективности и производительности, наглядность представления информации
  • Скорость выпуска услуг
  • Повторное использование знаний
  • Экономичность
  • Улучшения в процессах
Отличительные характеристики
  • Низкая стоимость (на одну транзакцию)
  • Надежность
  • Масштабируемость
  • Производительность
  • Резервирование
  • Сканирование и фильтрация потока данных
  • Приоритезация запросов
  • Надежность
  • Публикация и подписка на данные
  • Механизм аналитики
  • Мощность обработки
  • Объединение данных
  • Простота использования
  • Надежность
  • Высокая пропускная способность
  • Обмен данными «по горизонтали»
  • Стандартные процессы
  • Кандидаты на аутсорсинг
Интегрирующие технологии
  • Системы интеграции корпоративных приложений
  • Специально разработанный программный код
  • Хранилища данных
  • Совместно используемые данные и обмен данными
  • Стандартные интерфейсы (API), XML

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

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