Контекст разработки архитектуры предприятияТак как я заметил, что ты, Цезарь, уже много построил и продолжаешь строительство, я разработал определенные правила, чтобы ты сам смог оценить качество как уже существующих, так и будущих зданий. Витрувий, архитектор времен Римской империи Разработка архитектуры предприятия включает в себя компоненты, связанные с функциональной архитектурой (бизнесом), информационными технологиями и управлением архитектурным процессом. Приведенная нижедиаграмма отражает подход NASCIO (Национальной Ассоциации CIO США), которая наглядно отражает то, как различные компоненты взаимодействуют и влияют друг на друга.
Рис. 8.1. Общий контекст разработки Архитектуры предприятия С учетом полученных выше знаний и детализации представления об архитектуре предприятия мы можем сказать, что ее разработка является процессом, основанным на бизнес-стратегии, который координирует идущие параллельно процессы создания бизнес-архитектуры, архитектуры информации, архитектуры прикладных систем и технологической архитектуры. Таким образом, архитектура предприятия является целостным описанием ключевых стратегий организации, связанных с бизнесом, информацией, прикладными системами и технологиями, а также их влиянием на функции и бизнес-процессы организации. Разработка архитектуры предприятия ведется в соответствующем контексте существующих в организации структур управления и взаимодействия. Существуют различные подходы или рамочные модели, методики (то, что по-английски называется frameworks) к описанию архитектуры предприятия. Эти методики задают классификацию основных областей архитектуры и единые принципы для их описания во взаимной увязке друг с другом, описание используемых правил (политик), стандартов, процессов, моделей, которые используются для определения различных элементов архитектуры на разных уровнях абстракции. В качестве примеров можно указать следующие методики: · методики, опубликованные аналитическими компаниями, такими как Gartner, Giga Group, META Group и другими; · модель Захмана; · методика TOGAF; · методика POSIX 1003.23, которая основывается на разработках компании Cap Gemini, переданных для публичного использования в 1996 году. Для государственных организаций существуют специальные методики, такие как разрабатываемая при поддержке правительства США Федеральная Архитектура Госорганизаций (FEAF – Federal Enterprise ArchitectureFramework) или используемая в Министерстве Обороны США DoDAF (Department of Defence Architecture Framework). Методика является инструментом для создания широкого спектра различных архитектур. Она, как правило, включает в себя описание методов проектирования архитектуры в терминах использования определенных " строительных блоков", описание того, как эти " строительные блоки" связаны между собой, набор инструментов для описания элементов архитектуры, общий словарь используемых терминов. Методики также могут содержать список рекомендуемых стандартов и совместимых продуктов, которые могут использоваться для реализации различных элементов архитектуры. Важно понимать, что методики не только задают набор документов и планов, необходимых для описания предприятия, но и определяют, как все эти элементы описания связаны между собой. Методики описывают, как определяются и документируются основные элементы архитектуры предприятия. Они позволяют решить проблему плохого взаимопонимания между вовлеченными в этот процесс людьми, поскольку задают некий общий, одинаково понимаемый набор понятий и моделей для описания элементов архитектуры в интересах различных категорий заинтересованных сторон. Разработка одних методик была инициирована государственными структурами, других – частным сектором и представителями индустрии. Различные методики, как правило, ориентированы на разные аудитории потенциальных пользователей и отличаются широтой охвата проблемы, вниманием к определенным областям, хотя тенденция состоит в постепенной унификации определений, связанных с архитектурой. Некоторые из методик концентрируются на определенных секторах индустрии, преимущества других подходов состоят в более четком документировании, а третьи уделяют большее внимание процессу перехода от сегодняшнего в будущее состояние архитектуры. Если говорить формально, то существуют индустриальные стандарты на описание архитектуры предприятия, принятые такими организациями, как Институт инженеров электрики и электроники (IEEE – Institute of Electricaland Electronics Engineers), международная организация стандартизации (ISO – International Organization for Standardization), The Open Group и т.д. Но ни один из этих стандартов не занимает доминирующего положения. Более того, ни один из них, взятый в отдельности, не дает группам, ответственным за разработку архитектуры, всех инструментов, необходимых с методической точки зрения и с точки зрения шаблонов, используемых для описания архитектуры. Однако этот накопленный арсенал методик и стандартов предоставляет архитекторам широкие возможности выбора архитектурных моделей, примеров и опыта различных индустрий. При этом надо четко понимать, во-первых, отличие методики описания архитектуры от самой архитектуры как таковой, а во-вторых то, что использование одной и той же методики может приводить к созданию абсолютно непохожих между собой архитектур предприятия из-за различий в бизнесе и области деятельности организации, наличия определенного набора унаследованных систем и т.д. Важным для понимания методик являются используемые в них модели, различные представления (view) или домены архитектуры. Описание ИТ-архитектуры служит детальным руководством, которое определяет основные, стандартные или типовые элементы ИТ-систем, их взаимосвязи, а также процессы управления информационными системами. Что хотелось бы получить от такого документа? Можно сформулировать следующие, частично противоречивые, требования: · достаточно высокий уровень детализации для практического использования специалистами в области информационных технологий при разработке новых систем; · простоту для понимания бизнес-аудиторией; · динамику рассмотрения (т.е. " Архитектура как есть" – " Краткосрочные и среднесрочные задачи" – " Стратегические планы"); · возможность адаптации по новым требованиям бизнеса и учет возможностей реализации незапланированных (ad-hoc) проектов. Для формализованного описания ИТ-архитектуры организации могут использовать различные форматы. Важно, чтобы организация использовала такой формат описания, который бы обеспечивал легкий для понимания способ руководства по развитию всех аспектов ИТ в организации. Поэтому закономерно возникает вопрос по поводу " оптимального" формата, который может использоваться для описания ИТ-архитектуры именно как подмножества Архитектуры предприятия. В следующих разделах этой лекции мы рассмотрим наиболее распространенные методики описания архитектур. При этом мы не делаем принципиального различия между теми из них, которые ориентированы на описание архитектуры предприятия как целого, и теми, которые рассматривают более узкий контекст ИТ-архитектуры. Заметим, что достаточно важная и хорошо проработанная методика Федеральной архитектуры США FEAF, документы с описанием которой к тому же находятся в публичном доступе. Ниже представлена еще одна полезная модель, которая является отражением того факта, что существуют два взаимодополняющих определения архитектуры: " архитектура как описание" и " архитектура как процесс".
Первое определение говорит о том, что " архитектура – это описание некоторой сложной системы в определенный момент времени". Оно аналогично схемам описания и чертежам здания, города, сада или компьютерной сети. Этому определению архитектуры соответствует центральная секция таблицы. Данная часть таблицы описывает два представления архитектуры: существующее и будущее состояния. В лекциях 10-12, посвященных организации архитектурного процесса, мы отдельно обсудим, как должны, с точки зрения затрачиваемых усилий, соотноситься эти два представления архитектуры. Второе определение говорит, что " архитектура – это процесс, т.е. набор руководств, правил и/или стандартов, которые применяются в процессе построения новых систем" (правая секция таблицы). То есть второй смысл архитектуры – в создании системы правил, обеспечивающих направленный переход из текущего состояния информационных систем в будущие. Одним из элементов архитектуры при этом является модель технологической архитектуры, которая задает список утвержденных для закупки технологий. Выбор этих правил, узаконенных архитектурой, определяется принципами, которые должны быть сформулированы как часть всего архитектурного процесса. Опять-таки, необходимо отдавать себе отчет, что наличие этой модели не означает, что все описание архитектуры предприятия можно поместить в одну простую таблицу. Однако эта таблица наглядно отражает основные аспекты архитектуры и связи между ними. Ранее мы уже пришли к заключению, что многие понятия ИТ-архитектуры являются частными применениями соответствующих более общих понятий, связанных с архитектурой предприятия в целом. Соответственно, для описания и моделирования ИТ-архитектуры могут быть, при определенных условиях, применимы подходы, методологии и инструментальные средства моделирования, разработанные для более общих задач. Поэтому в этих разделах мы еще раз попробуем проследить на более детальном уровне связи понятий бизнес-архитектуры и корпоративной ИТ-архитектуры.
|
