Архитектура предприятия
Архитектура предприятия (business architecture, enterprise architecture) — план предприятия (enterprise), который обеспечивает общее понимание организации (основные организационные и логистические решения), стратегические цели и тактические требования.
Терминология
- «Предприятие» является бизнес ассоциацией, состоящей из признанной совокупности взаимодействующих бизнес функций. Она способна работать как независимая, отдельная организация. Согласно такому определению, могут существовать предприятия в пределах предприятий. Например, организационная единица внутри общей корпоративной организации может быть рассмотрена как предприятие при наличии возможности независимого функционирования. Предприятие можно также рассматривать как «Расширенное предприятие (Extended Enterprise)»; это означает, что масштаб архитектуры предприятия может также включать взаимосвязи с внешними организациями. Такими как: поставщики, бизнес-партнеры и клиенты.
- «Архитектура» обеспечивает базовую концепцию. Она определяет и описывает платформу, необходимую предприятию для достижения своих задач и своего видения. Ее можно определить как: совокупность принципов, ориентиров, правил, моделей, стандартов и процессов, соответствующих требованиям бизнес стратегии и информации, направляющих выбор, создание и внедрение решений для будущих направлений бизнеса.
Моделирование процессов в организации
Задача моделирования «процессов» чаще всего появляется в следующих случаях:
- «Чтобы было» — для отчетности инвесторам, в том числе формального доклада Совету Директоров, или для покупки сертификата серии ISO 9000.
- Налаживание хода «регулярного менеджмента», когда делается попытка формализовать текущий оргбардак с целью провести хоть какую-то реорганизацию — т.е. для помощи менеджерам в принятии решений.
- При запуске нового сервисного продукта для договоренностей о том, как будет происходить работа множества разных служб в сложном «операционном дне»: кто что кому передаёт, и во сколько, чтобы успеть для какого-нибудь важного производственного цикла.
- Создание какой-то информационной системы. Быстро выясняется, что система живёт не в вакууме, а в организации, и требуется отмоделировать организацию, что и делают через «процессы».
Наиболее сложным подходом является моделирование процессов организации и создание «корпоративной информационной системы» (под которой понимается всё, что хоть как-то относится к компьютерам, т.е. сети, сервера, рабочие станции, данные и разнообразный софт). Люди, которые занимаются информационной системой хоть сколько-нибудь больших масштабов быстро приходят к тому, что им нужна «архитектура предприятия» (enterprise architecture) и тут же попадают в практику системной инженерии: рассматривается предприятие как система, в котором информационная система является подсистемой, а само рассмотрение ведется в терминах множества групп описаний.
Подходы к описанию архитектуры предприятия
Языки моделирования
- ArchiMate (ссылки) и архитектурный язык OpenGroup ArchiMate 2.0.
Критика архитектурных подходов
Опыт показывает, что все архитектурные подходы не слишком адекватны:
- группы описаний заставляют описать много лишнего, но не выявляют сущностного
- языки это сущностное не позволяют выражать
Поэтому продолжается поиск «сущностного» в организации, и адекватных описаний этого «сущностного». В последнее время выявлено несколько таких «сущностностей»:
- Органиграмма как описание делёжки орг.ресурсов в терминах статичного административного подчинения. Отделы, службы и прочие подразделения. Споры начинаются уже в том месте, когда нужно описать место начальника подразделения (начальник представляет собой всё подразделение в дереве органиграммы, или только входит в него? Ответ загадочен при нескольких уровнях, в разных системах моделирования ответы на этот вопрос разные). Когда же речь заходит о проектных организациях, то «органиграмма» оказывается нужна разве что для выпуска приказов на уход в отпуск, но не для организации работ.
- Структуры целей организации: например, Business motivation model (OMG BMM), или голдраттовское Strategic & Tactics Tree (S&TT).
- Правила работы (Business rules), например OMG SBVR. «Если клиенту за 60, и он клиент больше года, то выдать скидку 5% при любой покупке».
- Процессы
- Процессы моделируется как цепочка поручений работы (напр., от запроса клиента до выполнения заказа), которая обязательно возращается (будь это внутренний «заказ», или «внешний», по письменному контракту, или без оного). Такой подход, основанный на теории коммуникативного действия (парадигмы речевых актов) позволяет моделировать «организационную сущность»: кто что кому поручает, саму «организованность людей». Представителем такого подхода к «процессам» является DEMO (Design & Engineering Methodology for Organizations).
- Процессы документируются. Поскольку организация должна выполнять разные функции, эти функции нужно задокументировать. Этим занимаются главным образом люди, проникнувшиеся ISO 9000 и тамошнего понимания «процессов» как оргфункций. Проблема в том, что в оргфункциях нет даже времени, и функции — это не работы («конструкция»), это функции, и об этом забывают. На диаграммах IDEF0 (наиболее часто используемый стандарт изображения функций, раньше это называлось SADT) в верхнем левом углу рисуется не «самый первый шаг», а «самая важная функция на листе». То есть «процесса», как развертки времени, в IDEF0 нет.
- Документирование процесса во времени. Процесс, как развертка во времени из выполняемых шагов, или workflow («ход работ») это и есть BPM (business process management) — IDEF3 в наиболее древней нотации, в России хорошо известна нотация EPC (event-driven process chain) из ARIS, а главным современным стандартом является OMG BPMN 2.0, который поддерживают все «движки процессов». Каждую неделю очередная фирма заявляет о поддержке BPMN 2.0 моделирования, и компьютерного исполнения процессов, отмоделированных в BPMN 2.0.
- Практики жизненного цикла (по-английски это иногда processes, а иногда practices). Развертка во времени тут — это сам жизненный цикл (life cycle), понимаемый как «последовательность стадий», где каждая стадия соответствует примерной одинаковости состояния системы в ходе работ по ее инженерии (замысел, проектирование, сооружение, эксплуатация и т.д. — хоть спички, хоть организации, хоть космодрома). А вот в ходе стадий выполняются те или иные практики, причем подробно не рассказывается, как их делать «шаг за шагом», зато указываются руководства, требования к квалификации сотрудников, выполняющих эти практики, нужный инструментарий, используемые языки и нотации представления информации. Именно из описания жизненного цикла можно узнать, используются ли в работе «итерации», или никаких итераций нет, и «возврат на доработку» — это ЧП. Стандарты такого описания — OMG SPEM, ISO 24744 и вновь разрабатываемый подход SEMAT. Таким подходом занимаются люди, придерживающиеся ситуационной инженерии методов: их задача описать используемый в организации метод работы (а не, например, административное подчинение работников, или последовательность нажатия кнопок и принятия отдельных решений в ходе пошагового выполнения четкой инструкции).
- Проекты.
Примеры архитектуры предприятия
- Autodesk — изменение организационной структуры
- Spotify — отряды и племена
Архитектор предприятия кто это
НАЦИОНАЛЬНАЯ АССОЦИАЦИЯ АРХИТЕКТОРОВ ПРЕДПРИЯТИЯ. Контакты
- > Главная
- > О нас
- > Манифест
- > Устав
- > Органы управления
- > Лица ассоциации
- > Участие
- > Поддержать ассоциацию
- > Контакты
- > Об архитектуре предприятия
- > База знаний
- > Стандарт профессии
- > Партнерство
- > Блоги
Пара слов об архитектуре предприятия, людях, ею занимающихся, и директорах, ею пользующихся
Само понятие Архитектуры Предприятия у нас пока что не слишком распространено, Архитектуру предприятия часто путают с архитектурой зданий и населенных пунктов. Однако, это совершенно другая область знаний. Одна из задач НААП, объединяющей не слишком многочисленных специалистов в этой области, — популяризация этого понятия и разъяснение его границ и рамок применимости.
- Архитектура Предприятия – наиболее общее и всестороннее описание целостности, определяемой как «предприятие» во всех аспектах его деятельности и структуры, существенных для поддержания его идентичности и непрерывности в ходе трансформаций на всех этапах его исторического развития. Проще говоря, архитектура предприятия — это план, по которому создается и развивается предприятие в течение всего срока своего существования.
- Под Предприятием мы будем понимать образование, состоящее из одной или нескольких организаций либо их частей, а также индивидуальных производителей, разделяющих общую миссию и цели по предоставлению некоторого выхода, например услуги, продукта или информации.*
Архитектор предприятия – лицо или группа лиц, использующее инструменты АП для управления проектированием, созданием, трансформацией или завершением деятельности предприятия (таким образом, предприятие рассматривается Архитектором Предприятия как искусственная система). У Архитектора предприятия особый тип мышления и особый подход, отличный от системного и системно-инженерного. И применение этого типа мышления и подхода создает особый тип продукта — предприятие. По сути, архитектор предприятия отвечает за то, как предприятие пересоздает себя на каждом шаге развития.
«Кому нужна архитектура предприятия? Сколько лет предприятия жили без этой дисциплины, производили продукцию, и все было дешевле, а сейчас бездельники придумали для себя новые названия «Консультант», «Методолог», «Архитектор предприятия», а толку нет, все дорожает и становится хуже по качеству» — подобную точку зрения часто можно услышать не только от продавца на рынке, но и от директора или владельца бизнеса. Короткий ответ на это соображение таков: Мир меняется, и у нас есть инструменты, помогающие руководителям бизнеса меняться вместе с ним, быстрее его, и меняться управляемо. Подробный ответ вы найдете на нашем сайте, а также на наших бесплатных семинарах (хеш-тег #seminar_arch)
Мы публикуем интервью, заметки, статьи и размышления действующих Архитекторов Предприятий, как бы не звучало официальное название их должности, предназначенные как для специалистов (эти материалы помечены хеш-тегом #prof_arch), так и для всех интересующихся (под хеш-тегом #info_arch)
* Приведенные здесь определения являются обобщением множества взглядов и описаний этих понятий, приводимых в специализированных стандартах и сводах знаний. НААП ведет базу знаний по архитектуре предприятия, доступную членам Ассоциации — специалистам в области АП
Архитектура предприятия и инструменты ее моделирования
Рассматриваются состав, структура и процесс создания архитектуры предприятия. Анализируются существующие среды и методологии моделирования архитектуры предприятия. Отмечено, что в ближайшее время архитектура предприятия превратится в одно из главных средств управления изменениями на предприятии в РВ.
В самом общем виде под архитектурой предприятия (ЕА — Enterprise Architecture) понимается всестороннее и исчерпывающее описание (модель) всех его ключевых элементов и межэлементных отношений. Согласно ISO 15704 («Industrial Automa-tion Systems — Requirements for Enterprise-Reference Architectures and Methodologies. 1999») архитектура предприятия должна включать роль людей, описание процессов (функции и поведение) и представление всех вспомогательных технологий на протяжении всего жизненного цикла предприятия. Архитектура (в соответствии с документом «Federal Enterprise Architecture Framework. Dev. by: The Chief Information Officers Council (USA)») является стратегической информационной основой, определяющей:
структуру бизнеса;
информацию, необходимую для ведения бизнеса;
технологии, применяемые для поддержания бизнес-операций;
процессы преобразования, развития и перехода, необходимые для реализации новых технологий в ответ на изменение/появление новых бизнес-потребностей.Состав, структура и процесс выстраивания архитектуры
Архитектура предприятия традиционно представляется в виде следующих слоев: корпоративные миссия и стратегия, цели и задачи; бизнес-архитектура; системная архитектура (ИТ — архитектура).
Корпоративные миссия и стратегия определяют основные направления развития предприятия и ставят долгосрочные цели и задачи.
Бизнес-архитектура на основании миссии, стратегии развития и долгосрочных бизнес-целей определяет необходимые для их реализации бизнес-процессы, информационные и материальные потоки, а также поддерживающую их организационно-штатную структуру.
Системная архитектура определяет совокупность методологических, технологических и технических решений для обеспечения информационной поддержки деятельности предприятия, определяемой его бизнес-архитектурой, и включает архитектуру приложений, данных и техническую архитектуру.
Исследования выполнены автором в рамках работ Фонда ФОСТАС в 2003 г. Публикация осуществляется на основе разрешения, полученного Фондом от МЭРТ.
Архитектура приложений, в свою очередь, включает:
собственно прикладные системы, поддерживающие исполнение бизнес-процессов;
интерфейсы взаимодействия прикладных систем между собой и с внешними системами и источниками или потребителями данных;
средства и методы разработки и сопровождения приложений.Архитектура данных включает: БД и хранилища данных; системы управления БД или хранилищами данных; правила и средства санкционирования доступа к данным. Техническая архитектура состоит из сетевой архитектуры и архитектуры платформ. Сетевая архитектура включает:
локальные и территориальные вычислительные сети;
используемые в сетях коммуникационные протоколы, сервисы и системы адресации;
аварийные планы по обеспечению бесперебойной работы сетей в условиях чрезвычайных обстоятельств.Архитектура платформ включает:
аппаратные средства вычислительной техники — серверы, рабочие станции, накопители и другое компьютерное оборудование;
операционные и управляющие системы, утилиты и офисные программные системы;
аварийные планы по обеспечению бесперебойной работы аппаратуры (главным образом — серверов) и БД в условиях чрезвычайных обстоятельств.Основными этапами процесса построения архитектуры предприятия являются:
осознание необходимости построения архитектуры;
формирование рабочей группы;
выбор среды и средств моделирования и репозитория;
наполнение среды фактическим материалом (формирование архитектуры);
использование, расширение и сопровождение. Отметим, что в состав рабочей группы должен входить выделенный относительно новый ролевой участник — архитектор, который фактически является постановщиком задач на архитектурные изменения на основании как изменившихся внешних условий, так и понимания недостатков существующего положения дел.Моделирование архитектуры
Модель архитектуры предприятия аккумулирует знания о его процессах, поведении, информационных и материальных потоках, ресурсах и организационных единицах, инфраструктуре и архитектуре систем. При этом главной целью моделирования должно являться не только повышение интегрированности предприятия, но и поддержка его анализа в самых различных разрезах (экономических, организационных, качественных, количественных и т.д.) для совершенствования деятельности по принятию решений, контролю, координации и мониторингу различных его частей. Чтобы иметь полное понимание бизнеса, необходимо иметь ответы на вопросы — кто, что, когда, зачем, где и как осуществляет.
Среда моделирования архитектуры предприятия должна включать четыре компонента.
1) Блок элементарных объектов предприятия:
описания (представления) элементарных объектов (например, конкретного продукта/услуги, производимого на предприятии в настоящее время);
средства, используемые для порождения таких представлений (т.е. данных по объектам) со-гласно определенным правилам (например, ERP, SCM, CRM, СУБД).
2) Блок моделей архитектуры предприятия:
собственно модели различных видов (процессно-функциональные, информационные, ресурсные, организационные и др.), состоящие из элементов, абстрактно отображающих элементарные объекты;
средства моделирования, обеспечивающие анализ, проектирование и использование моделей.
3) Блок языков и методологий моделирования, включая:
общемодельные конструкции;
процессы моделирования архитектуры предприятия;
средства, поддерживающие процесс определения и модификации методологий и языков.
4) Блок языков мета-моделирования и мета-методологий для описания концепции, синтаксиса и семантики языков моделирования и методологий их применения, а также для описания процессов построения этих языков и методологий.Методологии моделирования должны регламентировать последовательность этапов и шагов моделирования, правила перехода от этапа к этапу, набор и правила построения моделей на каждом из них. При этом этапы моделирования архитектуры должны обеспечивать нисходящее проектирование основных архитектурных слоев в соответствии с общей схемой архитектуры предприятия и должны содержать следующие работы:
Существующие среды моделирования архитектуры предприятий могут быть классифицированы следующим образом:
Следует отметить, что моделирование архитектуры предприятий является инженерной дисциплиной, требующей комбинированного использования программных сред, языков и методологий моделирования. Однако большинство из перечисленных инструментов фактически являются фрагментарными подходами, покрывающими лишь различные части описанных выше требований к среде моделирования архитектуры предприятий, в том числе:
поддерживают лишь отдельные компоненты среды моделирования;
поддерживают лишь отдельные фазы и этапы процесса моделирования архитектуры;
не являются универсальными в части применимости к предприятиям любого вида;
поддерживают лишь отдельные виды моделирования.Наиболее продвинутыми в части покрытия обозначенных требований естественно являются универсальные интегрирующие среды. Например, Zachman Framework является одной из наиболее продвинутых сред в части гармоничного и комплексного учета всех архитектурно-существенных факторов, позволяя при этом концентрироваться на отдельных аспектах архитектуры, не теряя при этом общего взгляда на предприятие как на единое целое. Она легка для понимания, логически полна и согласована, нейтральна по отношению к инструментарию, является наиболее распространенной (включая большое число статей по ее описанию и использованию). С другой стороны, Zachman Framework не поддерживает представление динамики развития предприятия и его информационных систем (отсутствие оси времени), является достаточно поверхностной (в смысле степени детализации) референсной моделью, достаточно бедна с технических позиций.
Конкурирующая среда GERAM (Generalised Enterprise Reference Architecture and Methodology) определяет комплекс концепций, методов и моделей, необходимых для проектирования и сопровождения современного предприятия (любого типа) в течение всего времени его существования. GERAM обеспечивает поддержку всех вышепредставленных элементов среды моделирования архитектуры, базируясь при этом на:
Одним из главных преимуществ GERAM является его мощность в решении задач, связанных с изменениями (реинжиниринг, CPI/TQM). Одним из ее главных недостатков является концептуальный характер, она снабжает методологическими руководствами, но не обеспечивает ни языком моделирования, ни соответствующими инструментальными средствами.
Следует отметить, что в настоящее время прослеживается тенденция к обогащению подходов в части покрытия среды моделирования, например, одна из последних разработок университета г. Бордо GRAI Integrated Methodology (GRAI-GIM) обеспечивает референсную модель с концепцией, языком, графическим формализмом и инженерным методом реали-зации методологии.
К наиболее распространённым в настоящее время языкам моделирования предприятий относятся, прежде всего, IDEF, ARIS и BPML.
Идея создания семейства стандартов IDEF (Integrated Computer Automated Manufacturing Definition) родилась в середине 70-х годов в ВВС США как решение проблемы повышения производительности и эффективности информационных технологий, возникшей при реализации программы ICAM (Integrated Computer Aided Manufacturing). Часть этого семейства из 14 стандартов, относящихся к методам и технологиям создания моделей сложных систем и проектирования компьютерных систем, имеет непосредственное отношение к моделированию бизнес-процессов, а именно: IDEF0 (модель функций), IDEF1 и его расширение IDEF1X (информационная модель и модель данных соответственно), IDEF2 (динамическая модель), IDEF3 (модель процессов) и IDEF4 (объектно-ориентированные методы проектирования). Часть стандартов семейства фактически осталась на бумаге (стандарт IDEF2), другая часть (IDEF0 и IDEF1X) превратилась в стандарт правительства США, известный как FIPS. Основными недостатками IDEF являются:
ARIS в целом преодолевает перечисленные недостатки IDEF, однако его методология по сути является методологией-оболочкой: нет четко описанных регламентов действий, не предлагается уникального подхода к проблеме моделирования архитектуры предприятия. Сам язык включает более 100 типов моделей, 90% из которых практически никогда не ис-пользуются, инструментальная поддержка осуществляется продуктом той же компании — разработчика методологии. Этот продукт имеет цену, на порядок превышающую стоимость инструментов аналогичного класса для аналогичных платформ, и огромные трудозатраты на его разработку, что вряд ли позволит создать когда-либо конкурирующий инструментарий, поддерживающий данный язык.
Одной из последних разработок в данной области является создание специального языка, ориентированного на моделирование бизнес-процессов BPML (Business Process Modeling Language). Этот язык обеспечивает построение абстрактной исполняемой модели взаимодействующих процессов на основе концепции конечного автомата (машины конечных состояний). BPML представляет бизнес-процессы посредством объединения описания взаимодействий управляющих потоков, потоков данных и событий с дополнительными ортогональными средствами моделирования бизнес-правил, ролей, контекста взаимодействия. Он поддерживает синхронные и асинхронные распределенные транзакции, поэтому может быть использован как исполняемая модель для встраивания существующих приложений в качестве процессных компонент внутри е-бизнес-процессов.
Вторая важная проблема заключается в том, что многие из перечисленных инструментов поддерживают аналогичные концепции с различными названиями, которые трудно сравнивать из-за различного синтаксиса и семантики языков моделирования (которые к тому же часто точно не определены). Собственный синтаксис и ограниченная (ориентированная на поддерживающий инструментарий) семантика и графическая нотация языков привела к основной языковой проблеме — отсутствию интеграции моделей, разрабо-танных на различных языках моделирования.
Решением данной проблемы занимается рабочая группа, созданная компаниями-производителями языков моделирования, целью деятельности которой является создание унифицированного языка моделирования UEML (Unified Enterprise Modeling Language) с четко определенными синтаксисом, семантикой и правилами взаимоотношений (отображе-ний) между различными языками моделирования архитектуры предприятий. Проект UEML включает разработку:
Вендор Продукт Сайт Casewise Corporate Modeler www.casewise.com Computes Metis www.computas.com IDS Scheer Aris www.ids-scheer.com Mega Mega Suite www.mega.com Popkin System Architect www.popkin.com Proforma Corp. Provision www.proformacorp.com Ptech Enterprise Framework www.ptechinc.com Значение архитектуры предприятия постоянно увеличивается за счет обеспечения возможностей эффективного использования существующих технологий и эволюционного перехода к новейшим технологиям. В некоторых странах, например, в США, правительственные директивы требуют, чтобы предприятия имели четко описанную архитектуру. Соответствующий рынок инструментальных средств достаточно развит, в таблице приведен перечень пакетов, лидирующих по объемам продаж (в алфавитном порядке по вендорам).
В среднем, каждый из вендоров осуществляет продажи ПО на сумму 7. 15 млн. долл. США в год (исключение составляет компания IDS Scheer: объявленный ею доход за 2002 г. составил 211 млн. долл. США, но он включает не только продажи ПО, но и консалтинг, обучение, выполнение проектов и т.п.).
По прогнозам ведущих консалтинговых компаний через несколько лет архитектура превратится для предприятия в одно из главных средств управления изменениями, обеспечивая при этом:
Фактически, создание архитектуры предприятия является первым шагом на пути к предприятию, которое может реагировать на изменения в РВ.
Список литературы
1. Галактионов В.И. Системная архитектура и ее место в архитектуре предприятия//Директор информационной службы. 2002. № 5.
2. Разработка типовых требований к процессам информатизации органов государственной власти, включая разработку единой методологии построения «электронного прави-тельства»//Отчет о НИОКР. Фонд ФОСТАС, № госрегистрации 1027739757561, инв. № 2811/01. Москва. 2003.
3. Электронное правительство: рекомендации по внедрению в РФ /Под ред. В.И. Дрожжинова и Е.З. Зиндера, ЭКО-ТРЕНДЗ. Москва. 2004.
4. Harmon P. Developing an Enterprise Architecture // Business Process Trends, January, 2003.
5. Report on the State of the Art in Enterprise Modeling, University of Namur, 2002.Калянов Георгий Николаевич —
д-р техн. наук, проф., вед.научный сотрудник ИПУ РАН.
e-mail:Kalyanov@mail.ru http://www.kalyanov.by.ru- моделирование бизнеса с позиции менеджера, включающее построение концепций с использованием графических образов (пиктограмм) для представления бизнес-объектов и событий;
- моделирование бизнес-процессов, бизнес-функций, ресурсов;
- моделирование оргструктуры, включая ее нисходящую логическую схему, а также логические схемы принятия решений;
- преобразование бизнес-моделей в модели приложений и технологической архитектуры.
- универсальные интегрирующие среды (например, Zachman Framework, GERAM);
- языки моделирования предприятий (например, IDEF, ARIS, BPML);
- программные среды моделирования (например, ARIS 6 Collaborative Suite, Popkin System Architect, METIS);
- мета-модели и языки мета-моделирования (например, UML Profile for Business Process Definition, UEML).
- концепциях, ориентированных на человека (описание ролей, поддержка осуществляемых ролями процессов);
- процессно-ориентированных концепциях для описания бизнес-процессов;
- концепциях, ориентированных на технологии, для описания технологической поддержки процессов (моделирования и использования моделей).
- наличие всего трех типов моделей — функциональной, информационной и процессной, остальные аспекты архитектуры если и могут быть отображены, то на примитивном, недостаточном для серьезного анализа уровне;
- отсутствие интеграции даже для перечисленных трех типов моделей (при этом отсутствует как концепция интеграции, так и какая-либо реализация на уровне инструментов одного и того же производителя).
- общего, визуального, базированного на шаблонах языка для коммерческих инструментальных средств моделирования предприятий и программных систем класса workflow;
- стандартизованных, независимых от инструментов механизмов передачи знаний (моделей) между проектами;
- репозитория моделей предприятий.
- оказание помощи менеджерам при анализе потенциальных изменений и их реализации;
- предоставление основы для совместной работы бизнес-менеджеров и ИТ-менеджеров над целями, бизнес-процессами и выстраиванием предприятия в целом;
- предоставление единого хранилища всей информации о предприятии;
- обеспечение менеджерам поддержки в принятии решений: они могут обозревать отношения, задавать вопросы, идентифицировать проблемы, выполнять моделирование и т.д.
Корпоративный архитектор
Корпоративный архитектор (EA) — это специалист, который работает в тесном контакте с заинтересованными сторонами, в том числе экспертами по управлению предметной области для разработки стратегии, информации, процессов и ИТ-ресурсов организации. EA обеспечивает согласованность ИТ и бизнеса.
Основная цель EA — предоставить архитектуру, которая будет поддерживать наиболее эффективные и надежные ИТ-среды и удовлетворять бизнес-требованиям организации.
Hard
Автоматизация общекорпоративных процессов в одном или нескольких областях управления в любых компаниях среднего и крупного бизнеса.
Аналитическое и системное мышление. Корпоративный архитектор должен видеть решения в целом через взаимодействие частей.
Необходимые навыки
Soft
Знание инструментов проектирования и описания архитектуры (Togaf, Zachmann, RUP, DoDAF, TEAF).
Навыки проектирования систем и сервисов. Для этого нужно изучить различные архитектуры (SOA, WS-*, MOM, EBA, ESB, BPM) и шаблоны проектирования (GRASP, Gof, Enterprise Application).
Базовый навык разработки на платформе .Net/ Java EE.
Знание промышленных серверов баз данных (MSSQL, Oracle).
Стратегическое мышление. Задача этого специалиста — выбрать оптимальное решение вместо лучшего.Абстрактное мышление. Выходить за рамки привычной системы координат и правил, абстрагируясь от внешней действительности и пытаясь сконцентрироваться исключительно на исследовании мысли или идеи.
Понимание отраслевых особенностей бизнеса и его стандартов.
Умение работать в команде и аргументировать свои решения.Коммуникабельность. Умение выстраивать долгосрочные доверительные отношения и находить компромиссы между заинтересованными лицами.
Лидерство. Сотруднику предстоит управлять коллективом, правильно делегировать полномочия и ставить задачи.
Опыт бизнес-анализа и описания различных нотаций моделирования бизнес-процессов (VAD, eEPC(Aris), BPMN и др.
Знание ERP, CRM, HRM, ECM, BPM, BI, DWH, IDM, ESB, ETL различных вендоров.
По этому направлению ждут опытных специалистов. Путь к должности корпоративного архитектора чаще всего начинается с разработки ПО. Программирование можно изучить в вузах на ИТ-направлениях или на специальных курсах, время прохождения которых будет меньше обучения в университете. Многие учатся программировать самостоятельно, вырастая до корпоративного архитектора. Для переквалификации и углубления знаний можно пройти специализированные курсы по практикам архитектуры предприятия и корпоративной архитектуре.
Где и сколько учиться
«Шаблоны корпоративных приложений», Мартин Фаулер. Переиздание, 2020.
Создание компьютерных систем — дело не простое. По мере того, как возрастает их сложность, процессы конструирования программного обеспечения становятся более трудоёмкими, причём затраты труда растут экспоненциально. Книга даёт ответы на трудные вопросы, с которыми приходится сталкиваться всем разработчикам корпоративных систем. Автор выделил более 40 подходов, оформив их в виде типовых решений.
Полезные книги
Clean Architecture: A Craftsman’s Guide to Software Structure and Design, Robert Martin. 2017.
Применяя универсальные правила архитектуры программного обеспечения, вы можете значительно повысить производительность труда разработчиков на протяжении всего жизненного цикла любой программной системы. Основываясь на более чем полувековом опыте работы с программными средами всех мыслимых типов, автор делится критериями успешного выбора.
Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems, Martin Kleppmann. 2017.
Автор книги — исследователь распределенных систем в Кембриджском университете. Ранее он был инженером-программистом и предпринимателем в интернет-компаниях, включая LinkedIn и Rapportive. В первую очередь в книге рассматривается архитектура систем данных и способы их интеграции в приложения, интенсивно использующие данные.
Solutions Architect’s Handbook: Kick-start your solutions architect career by learning architecture design principles and strategies, Saurabh Shrivastava. 2020.
Став архитектором решений, вы сможете гибко работать с передовыми технологиями и определять стратегии продуктов. В этом справочнике вы познакомитесь с основными концепциями, принципами и шаблонами проектирования, архитектурными соображениями и новейшими технологиями, которые необходимо знать, чтобы стать успешным архитектором решений. Вы изучите приемы создания эффективной архитектуры, отвечающей вашим бизнес-требованиям.
The TOGAF® Standard, 10th Edition. TOGAF является руководящей основой (framework) для разработки и поддержания архитектуры. В соответствии с TOGAF архитектуру предприятия можно представить в виде четырёх основных доменов: бизнес архитектуру — определяет стратегию предприятия, — структуру управления и ключевые бизнес процессы.
«Дилемма инноватора. Как из-за новых технологий погибают сильные компании», Кристенсен Клайтон М. 2019.
Книга о том, как разоряются лидеры ИТ-отрасли. Автор на убедительных примерах доказывает: именно в период взлёта руководству следует быть наиболее внимательным по отношению к своей компании, поскольку этот период чреват финансовыми потерями и даже полным крахом. Как «переизбыток качества», требования заказчиков и давление акционеров парализуют творческую активность организаций, лишая их шансов противостоять замещающим технологиям. Это полезная книга для корпоративных архитекторов, из которой можно почерпнуть мысли о выстраивании системы в условиях большого количества стейкхолдеров.
Building Evolutionary Architectures: Support Constant Change, Neal Ford, Rebecca Parsons, Patrick Kua. 2017.
Экосистема разработки программного обеспечения постоянно меняется, образуя постоянный поток новых инструментов, сред, методов и парадигм. Это практическое руководство подробно рассказывает о новом взгляде на архитектуру, её переосмыслении и защите важных архитектурных характеристик.