Пользователи архитектуры

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

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

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

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

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

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

зз

Интегрированная концепция архитектуры организации

Рис. 1.13. Интегрированная концепция архитектуры организации

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

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

(средства формализации), своих «читателей» и отличается степенью формал изованности.

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

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

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

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

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

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

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

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

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

Данный уровень описания архитектуры организации должен содержать ответы на следующие вопросы:

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

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

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

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

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

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

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

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

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

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

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

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

 
Посмотреть оригинал
< Пред   СОДЕРЖАНИЕ   ОРИГИНАЛ     След >