CC BY
212
TOGAF в проекте по разработке системы взаимодействия с клиентами банка
TOGAF framework application in the project of developing a system of interaction with bank
customers
Котковский Д.Г.
Магистр 1 курса,
ф-т бизнес - информатики и управления комплексными системами, Национальный исследовательский ядерный университет «МИФИ»,
РФ, г.Москва e-mail: dgkotkovsky@gmail. com
Kotkovskiy D.
1st year master,
faculty of business informatics and complex systems management, National research nuclear university "MEPHI",
Russia, Moscow e-mail: [email protected]
Аннотация.
В современном мире, в условиях жесткой рыночной конкуренции у различных организаций и компаний возникает потребность в постоянной модернизации своего внутреннего устройства. Использование концепции архитектуры предприятия позволяет детализировать и описать работу по организации, выполнению и контролю действий по изменению структуры предприятий различного уровня. В статье приводится пример использования одного из самых известных фреймворков архитектуры предприятия TOGAF применительно к построению системы взаимодействия и коммуникации с клиентами для крупного банка. Рассматривается ключевой компонент методологии, отвечающий за процесс проектирования архитектурного решения. Каждый этап цикла проектирования описывается и сопровождается примером из действующей архитектуры крупного банка. Даются основные документы фреймворка, позволяющие зафиксировать результаты каждого отдельного этапа.
Annotation.
In today's world, in the conditions of severe market competition, various organizations and companies need a constant modernization of their internal structure. Using the concept of enterprise architecture allows to detail and describe the work on the organization, implementation and monitoring of actions to change the structure of enterprises of different levels. This article gives an example of using one of the most famous enterprise architecture frameworks TOGAF with the goal to build a customer interaction and communication system for a large bank. A key component of the methodology responsible for the architectural design process is considered. Each stage of the design cycle, in addition to the description, is accompanied by an example from the existing architecture of a large bank. The basic documents of the framework are also given that allows to fix the results of each separate stage.
Ключевые слова: архитектура предприятия, система, формирование архитектуры, взаимодействие с клиентами, крупная компания, банк.
Key words: enterprise architecture, system, architecture formation, interaction with customers, large company,
bank.
Введение
В настоящее время не существует однозначного определения «архитектуры предприятия». Множество
подходов, сформированных на текущий момент, порождают различные семантики этого понятия. Согласно определению Марка Ланхорста, автора книги «Enterprise Architecture at Work», «архитектура предприятия» - это целостный набор принципов, методов и моделей, который используется в проектировании и реализации организационной структуры, бизнес-процессов, информационных систем и технологий» [1]. Несмотря на то, что само по себе понятие является относительно новым ( первое упоминание появилось в 1987 г. в статье Дж.А. Захмана «Структура архитектуры информационных систем»), сейчас можно уверенно говорить о том, что концепция архитектуры предприятия является мощным разносторонним инструментом управления организацией.
Современные и динамично развивающиеся компании осознают важность ИТ-инфраструктуры как ключевого аспекта ведения бизнеса. Показатели таких организаций напрямую зависят от уровня организации ИТ -служб, что обуславливает постоянную потребность их развития. Банковская отрасль, наряду с телеком-компаниями, является одним из передовых секторов в части применения информационных технологий для осуществления своих прямых функций, однако количество бизнес-процессов и систем, обеспечивающих работу, настолько велико, что не позволяет банку создать полноценную внутреннюю экспертизу по каким-то продуктам. В связи с этим банки обращаются к услугам сторонних ИТ-компаний, специализирующихся на определенных услугах и продуктах. Однако для повышения скорости реализации проектов, координации взаимодействия в ходе разработки и повышения качества решений необходим механизм управления архитектурным проектом. В рамках данной статьи делается попытка рассмотреть применение архитектурного фреймворка TOGAF (The Open Group Architecture Framework) [2] применительно к процессу построения системы взаимодействия крупного банка с клиентами в части распространения счет - выписок по карточным договорам.
Обзор фреймворка TOGAF и пример его применения
Счет - выписка - это документ, отражающий движение денежных средств по счету карты за отчетный период. В ней содержится информация об операциях по карте, остатке средств, сумме задолженности и дате внесения минимального платежа.
Процесс построения архитектуры в общем случае состоит из пяти основных этапов:
1. Осознание необходимости построения архитектуры
2. Выбор среды и средств моделирования, формирование рабочей группы (выбор стандарта или методологии)
3. Наполнение среды фактическим материалом
4. Использование
5. Расширение и сопровождение.
Необходимость построения архитектуры в крупных коммерческих организациях в первую очередь может обуславливаться желанием увеличить прибыль и уменьшить затраты. Работа исходной системы взаимодействия с клиентами строится следующим образом - клиенты Банка получают счет-выписку через Почту России. Финансовые данные для формирования счет - выписки формируются в автоматизированной банковской системе и через интеграционные таблицы передаются в систему Actuate для формирования печатных форм документов с дальнейшей печатью, упаковкой в конверты и рассылкой через Почту России. Подобная организация порождает большие затраты банка и невысокое качество обслуживания, связанное в первую очередь со скоростью предоставления услуг и наличием только одного канала коммуникации. Кроме того, отсутствует возможность производить аналитику по результатам рассылки материалов клиентам. Исходя из вышесказанного, можно сделать вывод о необходимости проектирования архитектуры, которая, если не нивелирует все указанные недостатки, то позволит сократить их в долгосрочной перспективе.
Согласно второму и третьему пунктам процесса построения архитектуры, требуется выбрать средства моделирования и методологию (фреймворк), а также произвести наполнение среды фактическим материалом. Как было упомянуто в начале этой работы, в качестве фреймворка выбран один из наиболее известных инструментов
2
построения архитектуры предприятия, а именно TOGAF, разрабатываемый архитектурным форумом The Open Group. The Open Group является консорциумом, включающим крупнейшие мировые корпорации (NASA, BP, IBM, Oracle и многие другие), являющиеся как производителями, так и покупателями информационных систем.
Фреймворк TOGAF включает в себя полный набор инструментов для построения и развития архитектурной практики. Семь основных частей позволяют охватить весь архитектурный процесс.
1. Introduction. Эта часть содержит высокоуровневое описание ключевых концепций EA (Enterprise Architecture) в целом и TOGAF в частности.
2. Architecture Development Method (ADM). Пошаговая методика разработки архитектуры предприятия. Является ключевой частью методологии.
3. ADM Guidelines and Techniques. Включает в себя подробное описание правил и техник, которые используются в TOGAF ADM.
4. Architecture Content Framework. Содержит метамодель архитектурных артефактов, структуру и описание типовых архитектурных артефактов.
5. Enterprise Continuum & Tools. Определяет подход к адаптации общих архитектурных принципов для решения конкретных задач и процесс перевода адаптированных и зарекомендовавших себя в решений в форму универсальных руководств.
6. TOGAF Reference Models. В данной части дается описание эталонных моделей, доступных для использования в архитектурных проектах.
7. Architecture Capability Framework. Подход к организации архитектурной практики в компании. Структура, процессы, роли, навыки и полномочия, требуемые для работы архитектурной практики в компании.
На практике TOGAF часто оказывается избыточным. Не всегда использование всех частей необходимо для достижения желаемого результата. Тем не менее, ADM как ключевой компонент фреймворка используется практически всегда. На рисунке 1 представлена схема, состоящая из 10 взаимосвязанных этапов, которые проходят в процессе разработки архитектуры ADM. Каждый из этапов содержит собственные шаблоны и инструменты для разработки. Однако весь процесс целиком можно адаптировать под нужды своего проекта.
Рисунок 1. Схема Architecture Development Method (ADM) [2] Проведем процесс ADM на низком уровне детализации, с целью сформировать некоторое представление об архитектуре предприятия, удовлетворяющей целям заказчика, и приведем перечень документов TOGAF, которые позволяют зафиксировать результаты каждого этапа.
0. Предварительная фаза
Данная фаза является подготовительной для всего архитектурного проекта и подразумевает его инициацию. Адаптация фреймворка построения архитектуры под конкретную задачу происходит на этом этапе. Документы:
• «TOGAF 9 Template - Architecture Principles.doc»
• «TOGAF 9 Template Business Principles Goals Drivers.doc»
Управление требованиями
Управление требованиями находится в центре цикла ADM и обеспечивает целостность процесса разработки архитектурного проекта. Каждая фаза цикла должна соотноситься со сформулированными бизнес-требованиями. Данные требования могут объединяться в отдельные группы. Например, в рамках указанного проекта можно выделить следующие категории требований:
• Требования к хранению сформированных документов (время хранения документов, формат хранения и другие)
• Требования по взаимодействию программных систем комплекса (взаимодействие системы формирования счет-выписок с типографией и фронтальными банковскими системами и другие)
Документ:
• «TOGAF 9 Template - Architecture Requirements Specification.doc»
A. Видение архитектуры
Данный этап подразумевает под собой определение целей и задач проекта, выделение заинтересованных сторон, описание ограничений и допущений по проекту.
• Цель проекта - оптимизация процесса информирования клиентов о состоянии их карточных счетов, который осуществляется посредством предоставления клиенту счет-выписки по различным каналам информирования. Для снижения расходов Банка и повышения качества обслуживания, предусматривается введение альтернативных каналов для получения клиентами счет-выписки (СМС, E-mail) и введение комиссии за получение счет-выписки через канал Почта (Почта России).
• Основными группами заинтересованных сторон проекта в первую очередь выступают Банк и его клиенты.
• Ограничения и допущения в подобном проекте более целесообразно описывать на этапе разработки технологического решения, они порождаются деталями реализации бизнес-процессов с помощью ИТ - решений.
Документ:
• «TOGAF 9 Template - Architecture Vision.doc»
B. Бизнес-архитектура
C. Архитектура информационных систем
D. Техническая архитектура
Согласно фреймворку TOGAF, архитектуру предприятия в общем случае можно представить в виде четырех основных доменов [3], представленных на рисунке 2 [4]. Рассмотрим эти области с точки зрения архитектуры банка в целом и применительно описываемой задаче в частности.
/Бизнес-\ архитектура
Z Технологи ческа я архитектура \
(инфраструктура: аппаратное, программное обеспечение \
и коммуникации) \ч
Рисунок 2. Основные домены архитектуры предприятия согласно TOGAF [3]
1. Бизнес-архитектура
Идеальная ИТ - архитектура должна в первую очередь обеспечивать функционирование основных бизнес -процессов, нацеленных на получение банком прибыли. Предоставление клиентов выписок является основным бизнес-процессом в рамках описываемой задачи, но с целью его улучшения и понимания областей развития при описании могут вводиться и описываться побочные процессы.
В соответствии с исходными целями проекта, выделим следующие процессы:
• Подготовка данных для формирования счет-выписок.
• Передача каналов распространения выписок в системы, отвечающие за распространение по данным
каналам.
• Непосредственное формирование счет-выписок.
• Хранение сформированных счет-выписок.
• Печать счет-выписок в типографии для распространения через Почту России.
• Предоставление счет-выписок, через системы взаимодействия с клиентами - CRM и интернет-банк.
• Предоставление счет-выписок для отправки по вновь введенным каналам СМС и E-mail.
2. Архитектура информации (данные)
Данный домен описывает логическую и физическую структуру данных, задействованных в работе ИТ -систем. Большинство корпоративных приложений работает с реляционными базами данных, которые, как известно, хранят данные табличном виде. Сложность взаимодействия подразумевает разветвленную структуру, которая должна быть спроектирована таким образом, чтобы обеспечить интегрированные потоки информации для всех систем. Чаще всего это производится с использованием виртуальных таблиц-представлений. Такие таблицы формируются по средствам SQL-запросов к промежуточным операционным представлениям каждого отдельного приложения или централизованному хранилищу данных компании.
3. Архитектура приложений
Данный уровень выступает в роли карты корпоративных приложений и описывает как участие каждого из них в бизнес - процессах, так и взаимодействие со сторонними системами. При этом архитектура приложений должна коррелировать с бизнес - архитектурой и давать возможность эффективно реализовывать бизнес-процессы. На рисунке 3 показана схема архитектуры с указанием бизнес-процессов, за которые отвечает каждая отдельная система.
Рисунок 3. Пример архитектуры банковской системы по рассылке счет-выписок Компоненты, представленные на рисунке 3 - выполняют следующие функции:
• АБС ЦФТ - Автоматизированная банковская система
• Витрина ЦФТ - витрина данных для хранения и обработки данных, получаемых из АБС Банка
• FormIT - промышленное решение по управлению, формированию и распространению любых исходящих и внутренних документов компании.
• Печать - типография банка.
• WebSphere - промежуточное программное обеспечения для отправки сообщений (Message-Oriented Middleware).
• Директ - On-line интернет Банк.
• Siebel CRM - Фронтальная банковская система.
• Siebel CM - Аналитический модуль Siebel, предназначенный для автоматизации операционной работы проведения тестовых и промышленных целевых кампаний бизнеса Банка.
4. Технологическая архитектура
Современные бизнес-приложения работают с большими объемами данных и являются достаточно
6
требовательными к производительности вычислительных машин, на которые устанавливаются. Данный уровень служит для описания аппаратной среды и поддерживающей инфраструктуры. Требования к объему оперативной памяти, количеству ядер и другим характеристикам, необходимым для оптимальной работы приложений приводятся в комплектах лицензионной поставки банковского ПО.
Документ:
• «TOGAF 9 Template - Architecture Definition.doc»
E. Возможности и решения
В рамках данной фазы осуществляется определение разрыва между целевой и текущей архитектурами, а также определение возможных средств достижения желаемого архитектурного результата. Так как в ИТ - системах желаемый результат достигается с использованием программных продуктов, описываемых в архитектуре приложений, то данный этап можно опустить.
Документ:
• «TOGAF 9 Template - Architecture Principles.doc»
F. Планирование миграции
Процесс перехода от текущей архитектуры к целевой не должен нарушать процесс предоставления клиентам банковский услуг. В связи с этим, необходима разработка плана миграции как последовательности действий по переходу. Также данная стадия включает в себя анализ затрат и рисков по переходу. Анализ затрат со стороны банка подразумевает запрос документов по оценке работ у компаний-интеграторов, в случае, если системы разрабатываются на стороне. При этом документы по оценке должны быть как минимум двух видов:
• Оценка стоимости работ с подробным описанием стоимости каждой отдельной работы
• Временная оценка на выполнение каждого этапа работ, включая возможных рисков, возникающих в
процессе разработки
Документы:
• «TOGAF 9 Template - Transition Architecture.doc
• «TOGAF 9 Template - Implementation and Migration Plan.doc»
G. Управление реализаций
H. Управление изменениями архитектуры
Данные стадии обеспечивают процессы работы с архитектурой на стадии разработки и постразработки программной реализации архитектуры. Контроль за процессом перехода к целевой архитектуре и достижение первоначальных целей проекта в изменяющихся условиях осуществляются на данных стадиях цикла ADM.
Документы:
• «TOGAF 9 Template - Implementation and Migration Plan.doc»
• «TOGAF 9 Template - Architecture Contract.doc»
Заключение
В заключение стоит сказать, что архитектура предприятия является мощным инструментом для выстраивания и организации предприятия. Большое количество подходов и фреймворков позволяет выбрать подходящий именно конкретной компании с учетом ее целей и задач. Управление изменениями, внедрение новых функций, фокусирование на достижение конкретных результатов и извлечение максимальной ценности из используемых служб - это лишь малый пул возможностей, которые предоставляют современные методологии
7
построения архитектуры предприятия.
Список используемой литературы
1. Mark Lankhorst et al. Enterprise Architecture at Work: Modelling, Communication and Analysis (Second Edition) -Springer, 2009
2. TOGAF, an Open Group Standart [Электронный ресурс]. URL: www.opengroup.org/subjectareas/enterprise/togaf (Дата обращения: 04.06.2017)
3. Введение в стандарт TOGAF — архитектура предприятия [Электронный ресурс]. URL: http://www.dataved.ru/2014/04/togaf.html (Дата обращения: 03.06.2017)
4. Данилин А.В., Слюсаренко А.И. Архитектура предприятия - ИНТУИТ. - 2007. - Лекция 10.
