Диссертация (1145120), страница 40

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 40)

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

Для насважны такие проекты в области управления ИТ-архитектурой предприятия,результатом которых является ИТ-решение, внедрённое в компанию.Будем называть такие проекты КИТ-проектами, (Корпоративная ИТархитектура), а их результаты — КИТ-решениями.

Применим для изученияКИТ-решений аппарат программной инженерии, идентифицируя отдельныерабочие продукты. На практике это позволит точнее определять состав работКИТ-проекта.245Будем считать, что КИТ-проект один, особо оговаривая те случаи, когдасущественно, что их может быть несколько (серия)51. Приведём пример такойсерии.1. Разработкасоглашенияомоделировании(предметно-ориентированного языка) в компании.2. Настройка и внедрение EAM-инструмента.3. Наладка процесса моделирования и внедрение решения заказчику.4. Развитие созданного КИТ-решения.КИТ-решение разделим на три части: методологический блок, технологический блок, обучение и сопровождение (см. табл. 4.5).Табл.

4.5. Состав КИТ-решенияМетодологическийблокТехнологическийблокСопровождение и поддержкаЯзык моделированияБазовый инструментОбучениеМетод использованияКомплекс программныхсредствСопровождениеПроцессДокументацияИнтеграцияРезультаты моделированияОпишем рабочие продукты, содержащиеся в этих блоках.В рамках КИТ-проекта создаётся язык моделирования — большие компании обладают уникальной спецификой, поэтому стандартные языки и нотации, предлагаемые в рамках выбранного стандартного EAM-инструмента,нуждаются в доработке (расширении/сужении/модификации). При этом используются средства расширения, которые, как правило, имеются у всехEAM-инструментов [183], и создаётся предметно-ориентированный язык мо51Новый КИТ-проект целесообразно начинать тогда, когда существуют новые цели —например, налажена процедура описания бизнес-процессов, и теперь ставится задачаналадить процедуру систематизации и описания ИТ-систем, используемых в компании.Или требуется перенести модели на новую версию EAM-инструмента.246делирования.

Разработку такого языка важно выделить в отдельную работу,не ограничиваясь полуформальной выборкой необходимых видов диаграмм исущностей базового EAM-инструмента. При этом важно определить те понятия, которые должны будут использоваться — с их помощью специалистамкомпании должно быть удобно описывать деятельность своего предприятия.Здесь часто используются референтные материалы, отраслевые стандарты иархитектурные схемы (frameworks) и, фактически, явно или не явно, создаются онтологии (о применении онтологий в бизнесе см. работы [14], [15],[249]).

Язык моделирования может быть несложной вырезкой/надстройкойстандартного языка, но возможен и более сложный случай, когда меняетсяметамодель языка и определяются новые понятия и связи между ними, создаются новые ракурсы моделирования (viewpoints) и соответствующие имновые виды диаграмм, матриц и пр.Метод использования нацелен на формализацию способа практическогоприменения языка и решения в целом. Метод отвечает на вопрос КАК моделировать, в то время как на вопрос ЧТО моделировать был получен ответ приразработке языка моделирования. Методика содержит сценарии моделирования, определяет уровни детализации и фокусы моделирования, а также источники информации для разработки и модификации моделей.Важным рабочим продуктом является запущенный и отлаженный процессуправления архитектурой компании.

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

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

Эффект от управления архитектурой будет, во многом, зависеть от того, насколько хорошо реализована эта интеграция. Различные методологии и стандарты, в частности, TOGAF [421], уделяют интеграции большое внимание.2. Интеграция КИТ-решения с другими информационными системамикомпании: при управлении архитектурой необходимо использоватьимеющиеся в компании данные и обеспечивать данными другие информационные системы.Результаты моделирования архитектуры компании — это примеры, создаваемые проектной группой и/или при её консультативной помощи в рамках КИТ-проекта для того, чтобы после окончания проекта специалистыкомпании смогли продолжить моделирование самостоятельно. При этом могут создаваться модели «as is» — описание текущей ситуации в компании, имодели «to be» — описание итоговой (желанной) организации компании.

Поскольку деятельность по управлению архитектурой непосредственно связанас проектированием изменений в компании, то оба вида моделей важны. В248результате такого пилотного моделирования могут проявиться недостатки инедоработки различных компонент КИТ-решения, и эти недостатки можнобудет устранить в рамках проекта. Также при этом происходит обучениепользователей. Необходимо отметить, что на практике часто возникаютсложности с точным определением «as is» и «to be» моделей. Например, создаются описания существующих информационных систем, и это должныбыть «as is» модели. Но главным источником информации для них выступают технические задания, а не сами системы, при этом оказывается, что данные технические задания реализованы не в полном объёме, то есть такая модель оказывается не «as is».Базовый инструмент — важнейший рабочий продукт КИТ-проекта, вомногом, определяющий успешность КИТ-проекта.

Функциональность EAMсредств классифицирована и подробно описана [183]. При выборе EAMинструмента целесообразно руководствоваться следующими принципами.1. Инструмент должен входить в обзор, как минимум, одного из ведущиханалитических агентств IFEAD [290], Forrester [243] или Gartner [183],присутствуя в разделах лидеров или потенциальных лидеров рынка(исключение составляют российские инструменты, о чём будет сказанониже).2. Поставщик инструмента должен располагать представительством илисильным партнёром в РФ, способным обеспечить поддержку в процессе внедрения и эксплуатации инструмента. Поставщик, располагающийтолько зарубежными ресурсами, несёт высокие риски — не завершитьуспешно проект, превысить сроки и стоимость, не достигнуть целей.Это происходит ввиду ошибок интерпретации требований компанийзаказчиков и высокой стоимости специалистов по внедрению.

Крометого, для небольших и средних КИТ-проектов целесообразно использовать российские инструменты, в частности ОРГ-Мастер, поскольку249близость коллектива авторов позволяет очень гибко конфигурироватьэти инструменты под потребности конкретного заказчика и проекта.3. Если в компании уже используется некоторый EAM-инструмент, тоимеет смысл использовать именно его и в данном КИТ-проекте.Например, в компании уже специфицированы бизнес-процессы и естьпотребность систематизировать ИТ-архитектуру: в этом случае, еслиобе модели будут созданы в одном EAM-инструменте, то реализоватьсвязи между ними будет значительно легче, а надёжность таких связейбудет существенно выше, чем в случае, если модели располагаются вразных инструментах.4. При выборе инструмента для отечественных КИТ-проектов нужно учитывать современную политику импортозамещенияРФ, и в первуюочередь, для EAM-инструментов из США. В связи с этим отечественные средства оказываются предпочтительными.КомплекспрограммныхсредствявляетсяИТ-составляющейКИТ-решения, созданной в ходе КИТ-проекта: выбранный EAM-инструмент должен быть сконфигурирован/доработан с тем, чтобы обеспечить поддержкусозданного языка моделирования.

Характеристики

Список файлов диссертации