Автор работы: Пользователь скрыл имя, 02 Июля 2015 в 12:25, реферат
Архитектура предприятия выделилась в отдельную дисциплину чуть более 20 лет тому назад и в настоящее время является одной из ключевых функций как корпоративного, так и проектного менеджмента, основным средством достижения и поддержания конкурентоспособности любого предприятия или организации, особенно в сфере ИТ.
Надо отметить, что кроме вышеперечисленных общих трактовок данного понятия, в данной области существуют и разработки крупных компаний. Например, в исследовании Технологической академии IBM архитектура EA определяется следующим образом: «Дисциплина EA определяет и обслуживает архитектурные модели, механизм управление и инициативы по переходу, необходимые для эффективной координации частично автономных групп для решения бизнес-задач- и/или ИТ-задач (М. Ибрагим, 2008)».
Это определение было разработано специально для того, чтобы подчеркнуть, что EA -это не просто архитектура, а именно дисциплина. Кроме того, его цель - отразить потребность EA в связывании бизнес-стратегии предприятия с его программой изменений через определение следующих моментов:
Архитектура уровня отдельных проектов определяет структуру и функции систем (бизнес и ИТ) на уровне проектов и программ (совокупностей проектов), но в контексте всей организации в целом, т.е. не в изолированном рассмотрении индивидуальных систем. Архитектура уровня отдельных проектов детализирует, соответствует и существует в рамках Архитектуры предприятия.
Архитектура прикладных систем определяет структуру и функции приложений, которые разрабатываются с целью обеспечения требуемой функциональности. Некоторые элементы этой архитектуры могут быть определены на уровне Архитектуры предприятия или Архитектуры отдельных проектов (в форме стандартов и руководств) в целях использования лучшей практики и соответствия принципам всей архитектуры в целом.
Отличительной характеристикой решений, принимаемых в отношении архитектуры, является то, что эти решения должны приниматься с учетом широкой, или системной, перспективы. Любое решение, которое может быть принято локально (например, в рамках подсистемы), не является архитектурным для системы в целом. Это позволяет делать различие между детальным проектированием и принятием решений по поводу практической реализации системы, с одной стороны, и архитектурными решениями - с другой. Первые решения имеют локальное влияние, а вторые - систематическое. Поэтому для проектных решений нужна соответствующая более широкая перспектива, позволяющая учесть системное влияние решений более высокого уровня, что дает возможность достичь желаемого уровня компромиссов и соглашений между составными частями для обеспечения должного уровня качества системы в целом.
Например, если система прикладной, то свобода принятия решений, которые могут приниматься на уровне отдельных ее компонент или модулей, должна быть предоставлена соответствующим разработчикам этих подсистем. Архитектор прикладной системы должен рассматривать вопросы, которые важны для системы в целом.
Если предметом рассмотрения является архитектура проекта или некоторого решения (например, проект создания портала организации, который интегрирует информацию из некоторого количества информационных систем), то решения по поводу архитектуры отдельных прикладных систем должны приниматься, соответственно, разработчиками этих систем. На уровне архитектуры проекта должны рассматриваться только те вопросы, которые имеют систематическое значение или важны для проекта в целом. Например, в примере с порталом это могут быть решения о структуре метаданных, которыми должны руководствоваться все прикладные системы для того, чтобы информация из этих систем могла бы быть опубликована на едином портале.
В этом смысле, чтобы еще раз уточнить предмет данного курса, можно сказать, что в нем рассматриваются вопросы и подходы, которые относятся, в основном, к уровню предприятия в целом. При этом под предприятием понимается организация (или государственное ведомство) со всей совокупностью ее информационных систем, либо государство (регион, город) с соответствующей совокупностью информационных систем ведомств.
Определяющей характеристикой, которая отличает Архитектуру предприятия (или Корпоративную архитектуру) от других типов архитектур является соответствующий масштаб и охват. Она пересекает и пронизывает все внутренние организационные границы: границы различных бизнес-подразделений и границы отдельных функций.
Понимая, что построение архитектуры предприятия основано на системном подходе, что не может ограничиваться только рассмотрением его отдельных компонентов, вполне очевидно, что именно рассмотрение ее на уровне всей организации открывает новые возможности и позволяет решать проблемы так, как было бы невозможно на более «низком уровне», т.е. в более узких рамках. Например, это позволяет улучшить совместную работу, а также достичь эффективности за счет выстраивания коммуникации между отдельными элементами, что влечет за собой создание более эффективных систем и экономию затрат.
С другой стороны, интересна взаимосвязь архитектуры предприятия и имеющихся в организации информационных систем. Каждая из них представляет собой сложный, комплексный объект, который к тому же динамически изменяется во времени. Для упрощения можно выделить его наиболее существенные характеристики, которые и образуют архитектуру системы, понимаемую как компонентный состав системы и связи между ними. Такой подход позволяет с достаточной определенностью оценивать характеристики системы, планировать ее развитие и сравнивать различные системы. В то же время конкретная реализация данной информационной системы будет, наряду с ее архитектурой, «включать» все многообразие экземпляров данных, физическое расположение компонент, фактическую реализацию процессов управления и т.п. Таким образом, реализация отдельной информационной системы невозможна без понимания не только ее самой, но и того, какое место она занимает в общей структуре всей организации.
С другой стороны и саму информационную систему можно рассматривать с точки зрения архитектурных подходов. Тогда можно выделить два понятия:
Разделение этих понятий приводит к интересным следствиям. Архитектура системы по определению является бесконечно сложным, глубоким и неявным понятием. Только часть этого общего понятия, которая в принципе доступна для восприятия архитекторами, может быть переведена в явную документируемую форму - модель или набор моделей с неизбежными упрощениями, ограничениями и субъективными искажениями. Такая проекция и представляет собой «описание архитектуры». Поэтому при использовании подобных описаний при проектировании систем необходимо всегда помнить об их неизбежной неполноте.
Таким образом, ИТ-архитектура существует независимо от предпринимаемых в организации проектов по ее описанию, упорядочиванию и развитию. Более того, так как сама система неизбежно претерпевает изменения, то и ИТ-архитектура может тем временем меняться даже без целенаправленной деятельности предприятия и его ИТ-службы.
В дальнейшем термин «архитектура» будет использоваться в зависимости от контекста, обозначая как существующую реальность, так и соответствующее ей описание.
Еще одна формальное определение приведено в стандарте IEEE 1471 Института инженеров-электриков и электронщиков, который предоставляет метамодель для определения архитектуры. Этот стандарт определяет такие абстрактные элементы архитектуры, как представления, системы, среды, обоснования, заинтересованные стороны и т.д. В соответствии с этим представлением система обладает некоторой архитектурой, которая мажет быть определенным образом описана с различных точек зрения в зависимости от интереса тех людей (участников), которые рассматривают архитектуру системы. Каждой точке зрения на архитектуру системы соответствует определенное представление, основу которого составляет некоторый набор моделей. Все вышеперечисленные элементы увязаны между собой в соответствии со схемой (рис. 1.3).
Рис. 1.3. Рамочная модель архитектуры по IEEE 1471
Однако этот стандарт не определяет структуру собственно Архитектуры предприятия. Например, говорится о том, что необходимо иметь различные представления архитектуры, но при этом не указывается, какие это должны быть представления.
Возвращаясь к предмету нашего обсуждения, можно рассмотреть различные аспекты понятия архитектуры ИТ. В частности, можно выделять такие подмножества, как системная архитектура (архитектура систем - System Architecture) и программная архитектура (архитектура программного обеспечения - Software Architecture). На практике, в зависимости от контекста, термин «системная архитектура» может относиться либо к архитектуре ИТ-системы предприятия (в дополнение к бизнес-архитектуре) или даже в еще более узком смысле к технологической инфраструктуре информационной системы, либо - к архитектуре сложного продукта или семейства продуктов, выпускаемых предприятием.
Хотя методика описания и проектирования архитектуры отдельных прикладных систем имеет много общего с подходами к описанию архитектуры предприятия в целом, тем не менее, архитектура программных систем является отдельной областью знаний, которой посвящено большое количество соответствующей литературы. Под «программной архитектурой», опять же в зависимости от контекста, может пониматься как архитектура взаимодействия приложений в рамках информационной системы предприятия (т.е. архитектура приложений), так и архитектура программных модулей или архитектура взаимодействия различных классов в рамках одного приложения. Каждая из отмеченных архитектур, в свою очередь, может рассматриваться с тем или иным уровнем детализации и под определенным углом зрения. Так, для программной архитектуры традиционными являются следующие перспективы или уровни описания архитектуры:
Все эти «частные» архитектуры - системная архитектура, программная архитектура - представляют, тем не менее, существенный интерес для нашего внимания, так как опираются на одни и те же подходы и методы, а также используют сходные средства описания и представления результатов. Еще более интересным является тот факт, что и сами процессы разработки данных архитектур, требования к архитекторам и понимание того, что является действительно хорошей архитектурой, во многом совпадают. Поэтому мы можем полагать, что для эффективного овладения проблематикой архитектуры предприятия будет, несомненно, полезно использовать соответствующие наработки в данных «смежных» областях, тем более, что в указанных ниже работах достаточное внимание уделяется и нашему основному предмету.
В частности, хорошее введение в предмет программной архитектуры и в специфику профессии программного архитектора представляет собой работа [(Monin, 2007)]. Другим интересным примером анализа различных аспектов деятельности Программного архитектора являются публикации Д. Бредемейера (http://www.bredemeyer.com/).
Для того чтобы разобраться, какой должна быть архитектура предприятия, а также того, как именно она связана с информационными системами, имеющимися на предприятии, попробуем вначале определить самые общие рамки данного понятия.
«Корпоративная архитектура» или «архитектура предприятия» являются терминами, которые специалисты очень часто используют, но при этом редко бывает ясно, что имеется в виду на практике. В реальности профессионалы в области информационных технологий, понимают под архитектурой ИТ достаточно большой спектр понятий - структурированное семейство технических руководств, включая концепции, принципы, правила, шаблоны и интерфейсы, а также взаимосвязи между ними, которые используются при создании новых информационных систем и развитии существующих систем. В отличие от них, профессионалы в области бизнеса не рассматривают этот вопрос как вопрос исключительно технологий. Наоборот, они разговаривают в терминах бизнес-моделей, бизнес-процессов и иногда - бизнес-архитектуры (она как раз и является одним из представлений архитектуры предприятия).
В результате эволюция указанных выше понятий и анализ взаимосвязей между ними прошел множество этапов. Каждый из них был связан с расширением охвата разрабатываемых моделей, что приводило к более комплексному и всеобъемлющему (а значит более реалистичному) подходу к описанию деятельности организации, в том числе и в сфере ИТ. В литературе, посвященной данной проблематике [(А. Данилин, 2005)] приводится следующая общая схема эволюции данных понятий (рис. 1.4):
Рис. 1.4. Эволюция понятия «архитектура предприятия»
В ранних работах ИТ-архитектура понималась в основном как технологическая архитектура или архитектура, определяющая инфраструктуру информационной системы. Работы по описанию архитектуры сводились к рассмотрению исключительно технических аспектов, то есть формированию технологических стандартов и принципов, включая проведение инвентаризации различных технологий, используемых в организации. Такой подход хоть и позволяет добиться определенных преимуществ например, снизить стоимость закупок и эксплуатации информационных систем и уменьшить затраты на разработку приложений и обучение персонала. Однако он является заведомо ограниченным, так как не подразумевает ориентацию на решение бизнес-задач, которые как известно могут меняться весьма кардинально, требуя от организации большой гибкости в части архитектуры (в том числе и в сфере информационных технологий).
Информация о работе Применение архитектурных подходов в сфере информационных технологий