Контекст и основные элементы архитектуры приложений

 

 

СОДЕРЖАНИЕ

   Введение…………………………..…………………………………………..…..3

 

ГЛАВА 1. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ АРХИТЕКТУРНЫХ

 ПРИЛОЖЕНИЙ

1.1. Основные понятия элементов  архитектурных приложений………..……5

1.2. Модели и инструменты управления  портфелем приложений …………10

 

ГЛАВА 2. КОНТЕКСТ ЭЛЕМЕНТОВ АРХИТЕКТУРНЫХ ПРИЛОЖЕНИЙ

2.1. Функции элементов архитектурных  приложений……………....………14

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

 

ГЛАВА 3. ТРЕБОВАНИЕ К  ОБОБЩЕННОЙ АРХИТЕКТУРЕ ПРИЛОЖЕНИЙ ДЛЯ ПОИСКА КОДА……………………………....……..26

 

Заключение……………………………………………………………………….32

Список используемой литературы…………………………………………….34

 

 

 

 

 

 

 

 

 

 

 

Введение

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

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

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

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

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

Собственно архитектура  – это объективная реальность, включающая существующие компоненты системы и их связи, как это есть «в металле», «бетоне», «штатном расписании» и т.п.

Описание архитектуры (architecture description) – это отражение  объективной или планируемой  реальности в какой-либо документированной  форме

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

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

Тема: «Контекст и основные элементы архитектуры приложений».

Актуальность данной темы состоит в исследовании направлений моделей и инструментов управления элементами архитектурными приложениями.

Объектом исследования является элементы архитектурных приложений.

Целью является исследование деятельности компании и выполнение следующих задач.

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

 

 

 

 

1. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ АРХИТЕКТУРНЫХ ПРИЛОЖЕНИЙ

 

 

1. Основные  понятия элементов архитектуры приложений

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

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

В Архитектуре приложений, как правило, выделяют две основные области: формирование и управление портфелем прикладных систем предприятия; разработку прикладных систем.

Рис. 1 Две области Архитектуры  приложений предприятия

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 2.  Контекст управления портфелем прикладных систем

 

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

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

 

2. Модели и инструменты управления портфелем приложений

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

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

системы, требующие сопровождения  и развития.

Рис.3. Оценка портфеля прикладных систем по критериям бизнес-ценность и техническое состояние

 

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

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

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

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