Читать книгу «ИТ-архитектура от А до Я: Теоретические основы. Первое издание» онлайн полностью📖 — Вадима Алджанова — MyBook.
image

Сферы, охваченные книгой

Книга является первой из серии «ИТ Архитектура от А до Я» и представляет собой руководство на русском языке, в котором собраны и обобщены теоретические знания, в области построения Архитектуры Предприятия, Управления Проектами, Информационной Безопасности, Организации и Управления ИТ сервисами и ИТ аудита, так и рассмотрена последовательность применения их на практике, позволяющий полностью обеспечить потребности организации в процессе создания и управления ИТ архитектурой и инфраструктурой. На основе обширного материала, дается систематичное описание современного состояния ИТ компании, приводятся основные модели и подходы по формированию ИТ стратегии, управлению проектами, управлению ИТ сервисами, анализу рисков и управлению качеством, Контроль и аудит ИТ, интеграции и взаимодействие различных подходов и методов.

Книга предназначена для широкого круга читателей и будут полезна:

Топ-менеджерам, кураторам ИТ, ИТ директорам крупных и средних компаний так как позволит лучше понимать Архитектуру Предприятия (Enterprise Architecture) на базе подхода (TOGAF), роль и вовлеченность ИТ в бизнес. Показатели распределения финансовых инвестиций на ИТ сервисы. Представители бизнеса смогут понять общие аспекты по функционированию ИТ инфраструктуры, технические термины, принципиальные отличия различных архитектурных решений, принципы построения и сопровождения технических решений. Позволяет сформировать понимаемые обоими сторонами метрики и отчеты по оценке эффективности и результативности функционирования ИТ инфраструктуры.

Руководителям ИТ подразделений, ИТ архитекторам, менеджеров среднего звена ИТ департамента, а также менеджерам проектов книга предоставляет теоретические основы управления ИТ сервисами (ITSM) с применением рекомендаций практик ITIL, интеграцию методики Управление Проектами (PMI) в ИТ, вопросы аудита ИТ (CobiT) и Информационной Безопасности.

Книга не предназначена для малых ИТ инфраструктур т. к. стоимость бумаги выше чем требования, предъявляемые к ИТ. Так же будет мало эффективна для крупных предприятий с корпоративным управлением т. к. по каждому направлению деятельности скорее всего имеются узко направленные эксперты.

Благодарность

Выражаю благодарность друзьям, учителям, руководителям и коллегам за помощь в написании книги, а также бесценный опыт и знания полученный от общения с такими людьми как Александр Буслаев («AIC Group»), Иршад Гулиев («SINAM»), Фазиль Маммедов («ROTABANK»), Яна Хмельницкая и Karsten Stellner («LFS Financial Systems GmbH»), Thomas Engelhardt («Microfinance Bank of Azerbaijan»), Andrew Pospielovsky («ACCESSBANK») и Alan Crompton («Baku European Games Operation Committee BEGOC 2015»).

Юридическое уведомление

Информация, содержащаяся в книге, не несет в себе никакой коммерческой тайны или иной конфиденциальной информации. Материалы собраны из открытых источников, переработаны автором, используя имеющийся опыт и знания. Некоторые рассмотренные примеры приведены только для справки и являются вымышленными. Любое сходство с реально существующими людьми или организациями является случайным. Все упоминающийся в книге названия компаний и продуктов могут быть торговыми марками, принадлежащими соответствующим владельцам.

Авторские права

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

@ Copyrights Vadim Aldzhanov, 2018

Отказ от ответственности

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

Автор не несет никакой ответственности за прямые, косвенные, случайные или прочие убытки при использовании данного руководства. Читатель данного руководства проинформирован.

Посвящается моим родителям, любящей жене и двум прекрасным дочерям.

АРХИТЕКТУРА ПРЕДПРИЯТИЯ

Общие Положения

В данной главе описывается общая информация по Архитектуре Предприятия (Enterprise Architecture). Обобщенное определение можно представить, как:


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

Так как Архитектура Предприятия представляет из себя сложное и комплексное решение, включающая в себя переплетение различных методологий и техник, при построении Архитектуры Предприятия должны быть учтены, но не ограничены, рекомендациями следующих стандартов:

• TOGAF – Enterprise Architecture

• ISO/IEC 20000 – Quality in IT Service Management

• ISO/IEC 27000 – Best Practice IT Security Standards

• CobiT v5 – Audit and Control Framework

• ITIL v3 – Best practices in IT Service Management

• MOF – Microsoft Operations Framework

• PMI – Project Management Institute


Архитектура призвана ответить на такие вызовы и проблемы организации как:

•Недовольство бизнеса ИТ‐службой. Причины могут быть объективные или субъективные.

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

•Отсутствие порядка в «зоопарке» ИТ решений и систем, внедренных в организации.

•Сложность принятия решений, связанных с ИТ;

•Сложность согласование бюджета и запуск ИТ‐проектов;

•Рост ценности «Информации»;

• Рост связанности бизнеса и ИТ;

•Отсутствие прозрачности связей бизнеса и ИТ?

•Можно ли решить актуальные задачи бизнеса с использованием ИТ?

•Как заставить ИТ давать компании большую ценность?

•Как нужно менять ИТ при изменениях в бизнесе?

•ИТ системы сложны, не управляемы и дороги в обслуживании;

•ИТ системы сдерживают организацию от адекватного реагирования на изменения в бизнесе

•Критичная для бизнеса информация не своевременна и не адекватна;

•Отсутствует культура общения бизнеса и ИТ


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

Основные аспекты Архитектуры Предприятия

Для борьбы с выше сказанными проблемами и последствиями, Архитектура Предприятия помогает сформулировать следующие важные критерии.

Определение Структуры Предприятия

При построении Архитектуры Предприятия самый первый и наиболее важный аспект – понимание организационной структуры предприятия, принципов управления, принятия решения и т п.

Структура организации – фиксированное упорядоченное множество объектов и связей между ними.

По характеру специализации и видам деятельности различают:

•Вертикальное разделение – по уровню подчинения

•Горизонтальное разделение – по функциям и специфики деятельности

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

•Плоская – наиболее простая структура. Подходит для рабочих или проектных групп, или небольшой организации.

•Иерархическая (бюрократическая) – формирование структуры исходя из структуры организации, разделение труда на функции и ответственности работников.

•Линейная – управление по прямой (руководитель – подчинённый), общение между подразделениями только через руководителей подразделений

•Функциональная – взаимодействие идет по функциональному признаку

•Линейно-функциональная – взаимодействие совмещается по линейному и функциональному типу (наиболее используемая модель)

•Линейно-штабная – отдельные функциональные группы (штабы), самостоятельно ведущие работу с подразделениями или организациями. Как пример группа компаний в составе холдинга.

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

•Органические (адаптивные) – формирование структуры исходит из необходимости приспособления к изменениям. Отношения формируются, исходя не из структуры, а характера поставленных задач.

•Проектные – организуется при ведении проектов

•Матричные (программно-целевые) – принцип двойного подчинения, непосредственное подчинения руководителю, и проектному менеджеру

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

Существование той или иной организационной структуры может зависеть от ряда факторов:

•Специфика и степень разнообразия деятельности

•Географическое размещение

•Уровень централизации в организации

•Стратегия организации

•Количества и спектра предоставляемых услуг

Определение роли ИТ в составе организации

Одним из главных критериев при построении Архитектуры Предприятия можно выделить задачу по определению роли ИТ в составе организации. Если отбросить множество статей, рекомендаций различных консультантов о значимости ИТ в современном мире и «бла бла бла», необходимо четко и конкретно зафиксировать роль ИТ в составе организации, задачи, права возможности и степень ответственности. Для понимания роли ИТ в конкретной организации нужно ответить на следующие вопросы:

• Вовлеченность ИТ в бизнес организации. Насколько бизнес организации зависит от ИТ. Многие бизнес процессы и функции завязаны на сложных, централизованных или специфических ИТ решениях. Развитие бизнеса невозможно без быстрой и качественной работы ИТ. Есть целые отрасли, которые зависят от ИТ: банки, страховщики, прочие финансисты, сервисные компании, госорганы, технологические компании, энергетика и прочие (как пример в банке две третьи сотрудников так или иначе работают с централизованной банковской программой, в то время как для сельского хозяйства, лишь небольшая часть организации использует ИТ решения, да и те по большей части автономные – большинство сотрудников работают на поле или уровень компьютеризации компании низкий).

• Вашу организацию можно отнести к крупному или среднему бизнесу. На мой взгляд, до тех пор, пока все технологии компании со всеми подробностями помещаются в одной голове, а ИТ директор напрямую общается с руководством организации об архитектуре предприятия думать рано. Для малого бизнеса архитектура предприятия вообще, как телеге пятое колесо.

• Компания активно развивает ИТ. В компании идет несколько ИТ проектов в год, или хотя бы один проект по внедрению ERP, CRM или прочего сложного решения. Формирование Архитектуры Предприятия поможет с принятием решений и убережет от большинства переделок, ошибок, не состыковок, задержек и прочих проблем. У кого-то, и желательно не одного, должна быть общая картинка будущего и понимание процесса развития. Иначе кусочки мозаики, созданные в разных проектах, не сойдутся.

• У компании периодически происходят кризисы в ИТ, которые имеют существенное влияние на бизнес. В информационных системах происходят сбои, которые негативно влияют на бизнес, вплоть до его остановки. Сбои вызваны проблемами в интеграции, просчетами в инфраструктурных решениях, временными решениями и просто бардаком. Не все проекты, в том числе и ИТ, заканчиваются успешно, уложившись в сроки, бюджет и заявленные требования. Если руководство вашей компании устало от провалов, задержек, превышения бюджетов ИТ проектов, то стоит задуматься.

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

Выстраивание взаимоотношения между бизнесом и ИТ

Сфокусировать действия ИТ на целях и задачах бизнеса. Бизнес и ИТ стороны по-разному видят задачи, цели и ожидания по отношению друг к другу. Видение ИТ сотрудников «… мы прекрасно разбираемся в технологиях, нам платят деньги за умение программировать, настраивать, устанавливать и решать технические проблемы и т п. Наша работа начинается после получения технического задание…». Видение со стороны бизнеса – «… столько новых ИТ технологий, ИТ должен нам внедрить нам какое-то решение, чтобы увеличить объем продаж. Или что еще хуже, нам нужно решение ХХХ, оно есть у конкурентов и поэтому продажи у них выше… внедряйте мы уже все решили вы ничего не понимаете бизнесе…». Задача ИТ директора, участие на равных в обсуждении стратегии бизнеса. Общие принцип можно определить, как: «бизнес описывает свои требования и ожидания (Бизнес требования), ИТ в свою очередь формирует техническое задание для достижения целей.»

Наладить сотрудничество между бизнесом и ИТ.

Из выше сказанного вытекает вторая важная проблема – «вакуум» в коммуникации между сотрудниками бизнеса и ИТ. Задача руководства организации, и ИТ директора в том числе, наладить общение между сотрудниками организации не только на высшем уровне, но и между сотрудниками среднего уровня, и непосредственных исполнителей бизнеса и ИТ. Как говорится в популярной фразе «дьявол кроется в мелочах». Любая классная идея в общих чертах должна быть спущена вниз для детальной проработки. На этом этапе особенности мышления ИТ специалистов с его жесткими связями «причина – следствие», вопросами «… что будет если …,», «… как контролировать…», «… как измерить…», анализ сценариев предельных состояний, поможет выработать оптимальное решение. Кроме этого такие вопросы помогут представителям бизнеса лучше понять и проработать решение, с точки зрения бизнеса. Понять, что можно требовать от ИТ, текущие возможности решения и их перспективные возможности или ограничения.

Получить максимальную ценность от ИТ.

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

ЦЕННОСТЬ = ВЫГОДА – ЗВТРАТЫ

• С точки зрения бизнеса: Получить максимальную ценность от ИТ. Ценность информационных технологий – это разница между выгодами использования информационных технологий и затратами на них).

• С точки зрения ИТ: Соблюдение ИТ ценностей и требований (технологичность, безопасность и управляемость ИТ).

Перенос часть работ на сторону ИТ департамента, или отказ от автоматизации ряда элементов, может снизить стоимость решения, повысить простоту эксплуатации и удобство для клиентов. Одна из первостепенных задач – определить границы, где можно искать возможности, а где та грань, переход которой ломает основы управляемости ИТ и информационной безопасности.

...
7