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


АРХИТЕКТУРНЫЕ ПРОЦЕССЫ В ОРГАНИЗАЦИОННО-ЭКОНОМИЧЕСКИХ СИСТЕМАХ

УДК 65.014(045)

К.С. Дрогобыцкая
Финансовый университет  при Правительстве Российской Федерации,
профессор, доктор экономических наук, доцент, Москва

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

Abstract
In the present article is an attempt to "lift the veil" on the mystery of the development and use of architecture throughout the life cycle of the organization. The main attention is paid to the structure and contents of the stages of the architectural process, leaving economic issues and methodology of his organization in the background. In conclusion, the analysis of the pros and cons of both upstream and downstream approaches to the development of architecture.

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

Keywords: architecture organization, the architectural process, architectural domains, the migration of information systems, the descending and ascending design, technological infrastructure.

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

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

 

Рис. 1. Процесс разработки архитектуры

 

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

Выделяют шесть масштабных этапов разработки и обновления архитектуры организации (на рисунке они имеют вертикальное расположение и пронумерованы):

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

Анализ общих тенденций развития сферы принадлежности организации – это абсолютно творческий этап, лишенный каких бы то ни было средств формализованной поддержки. Одним из самых общих подходов к выполнению данного этапа является моделирование. Как известно, любая модель представляет собой упрощенное представление действительности, которое может быть использовано для описания, обсуждения и анализа текущего состояния исследуемой действительности, с одной стороны, и проверки возможных решений по её дальнейшему развитию – с другой [3]. Искусство моделирования состоит в определении разумного компромисса между сложностью модели и её способностью отражать  свойства и поведение исследуемой организации. В дополнение этому компромиссу в данном случае ещё необходимо найти  компромисс между применением стандартных и/или оригинальных решений и учетом специфических особенностей  организации. Такая сдвоенная компромиссность обуславливает большую неопределенность и, следовательно, творческий характер работ на первом этапе  архитектурного процесса.

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

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

Как следует из приведённого перечня, в формировании общего видения как этапа разработки архитектурного описания организации значительное место занимает её стратегия. Архитектура и стратегия аналогичны силам «инь» и «янь» древнекитайской философии, которые характеризуют баланс сохранения и изменения. В этом смысле стратегия задает направление и способы изменения архитектуры [1, с. 329].

В самом общем виде стратегия предполагает наличие общего видения, которое очерчивает контуры будущих целей, с одной стороны, и ограниченный набор путей (способов) их достижения – с другой [2]. Когда общее видение материализуется в конкретные цели, стратегия делает их достижение управляемой и выполнимой задачей. Следовательно, те кто отвечает за целеполагание, должны видеть  ограниченный набор способов её достижения, уметь выбрать наилучший и «расписать» его в логическую цепочку конкретных задач. Таким образом, классический стратегический план включает в себя видение (куда идем), стратегию (как достигаем намеченные цели) и перечень подлежащих решению задач (что конкретно делаем). В рамках второго этапа разработки архитектуры организации надо определиться с общим видением её целевого состояния.

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

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

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

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

На последнем, шестом, этапе оценивается влияние архитектуры на текущее и будущее состояния организации. Департаменты ИТ всегда находятся под прессом необходимости создавать новые системы (на основе сложившейся инфраструктуры и с учетом имеющегося набора прикладных систем) и интегрировать их между собой. Это непрерывное развитие корпоративной информационной системы делает практически невозможной замену всех старых приложений полностью. Не редко в организации можно встретить информационные системы, о которых пользователи думают, что они были инсталлированы ещё в середине прошлого века.  Более того, эксплуатируемые в организации  прикладные системы разрабатывались различными  проектными  командами, приобретались в различных компаниях в разное время. Они неизбежно различаются по внутренней архитектуре, формам используемых данных и др. параметрам, но какое-то время должны работать совместно [4]. Не редко это время совместной работы растягивается на всю обозримую перспективу.

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

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

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

Каждый из подходов имеет свои положительные и отрицательные стороны. В зависимости от значений ряда факторов, предпочтение  может быть   отдано  любому из них. Если, например, архитектурный проект должен быстро показать отдачу, или если разнообразие используемых в организации информационных технологий явно приводит к падению качества ИТ-сервисов, то предпочтительным является подход «снизу-вверх». Организации, которым нужно решить проблемы, связанные с неэффективностью или большим количеством излишних бизнес-процессов или перегруженностью прикладных систем, должны использовать подход «сверху-вниз». Не редко используется гибридный подход. Тем не менее, всегда выбранная стратегия должна отвечать конкретным потребностям организации и в любом случае требуется поддержка со стороны её высшего руководства, а также понимание того, что создание архитектуры – это долговременный и недёшевый процесс.

Литература

  • Данилин А. Архитектура и стратегия: «инь» и «янь» информационных технологий предприятия/А.Данилин, А.Слюсаренко. - М.: Интернет-университет Информационных технологий, 2009. - 504с.
  • Дрогобыцкая К.С. Организационный дизайн в информационном обществе / К.С. Дрогобыцкая. – М.: Экономика, 2009. – 206с.
  • Дрогобыцкий И.Н. Системный анализ в экономике: учебник / И.Н. Дрогобыцкий. – 2-е изд., перераб. и доп. – М.: ЮНИТИ-ДАНА, 2011. – 423с.
  • Радаев А. Как сделать интеграцию бизнес-приложений  эффективной – http: //www.insapov.ru/integration-busines-application.html



Рубрика: 
Другое
Ваша оценка: Пусто Средняя: 8 (1 голос)
Школа IT-менеджмента Экономического факультета АНХ, 119571, Россия, г. Москва, проспект Вернадского, д. 82 корп. 2, офис 207, тел.: +7 (495) 933-96-00, Copyright @ 2008-2009