#enterprise_architect — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #enterprise_architect, aggregated by home.social.
-
Десять типовых ошибок при внедрении управления корпоративной архитектурой (Enterprise Architecture) и как их исправить
Enterprise Architecture помогает связывать бизнес‑цели, технологии и изменения в компании. Но без правильного подхода она легко превращается в набор диаграмм и бюрократию. Разбираем 10 типовых ошибок внедрения EA и способы их избежать.
https://habr.com/ru/companies/otus/articles/1055524/
#enterprise #enterprise_architect #enterprise_architecture #architecture #togaf #archimate #корпоративная_архитектура #ошибки_управления #архитектурный_комитет #архитектурный_репозиторий
-
Корпоративный и Solution Architect: как не убить друг друга в одном домене?
Приветствую! На связи корпоративный архитектор банка Уралсиб - Моне Даниил! СА говорит ''это срочно для бизнеса'', а КА — ''это не по стратегии''? Узнаете себя? Мы нашли способ, как помирить их в одном домене, не жертвуя ни скоростью, ни качеством
https://habr.com/ru/companies/uralsib/articles/1049688/
#enterprise_architect #solution_architect #system_architect #корпоративный_архитектор #архитектор_решений #системный_архитектор #togaf #архитектура #банк #бигтех
-
Как мы строим клиентские стенды AI-ассистента: per-tenant overlay без форка кодовой базы
Когда мы начали встраивать AI-агента в BPM-платформу, перед нами встала знакомая enterprise-задача: десятки клиентов, у каждого своя онтология, словарь, роли и ограничения безопасности. В одной компании «заявка на покупку» — это «реестр заявок», в другой — «карточкой закупки». Один клиент работает на изолированном контуре с локальной моделью, другой не даёт ассистенту доступ к почте и репозиториям. Традиционный ответ — форк репозитория под каждого клиента — при масштабировании превращается в ад поддержки: багфиксы не попадают автоматически, стоимость растёт экспоненциально, качество падает. Мы решили эту проблему иначе: per-tenant overlay позволяет кастомизировать поведение агента без изменения кода.
https://habr.com/ru/companies/1forma/articles/1036934/
#bpm #bpmсистемы #enterprise #enterprise_architect #lowcode #автоматизация #автоматизация_процессов #оптимизация
-
Краткий обзор стандарта Open Agile Architecture от The Open Group (O-AA)
В октябре 2022 года The Open Group официально выпустил Open Agile Architecture™ (O-AA) — новую версию стандарта, призванного соединить мир «классической» корпоративной архитектуры с реалиями Agile, DevOps и цифровой трансформации. Первая версия документа была опубликована Open Group еще в 2020 году. Если вы корпоративный архитектор, архитектор решения, бизнес- или системный аналитик, и до сих пор считали, что Agile — это «про разработчиков», а архитектура это «про рисунки и бумажки», эта статья для вас. Задача этой статьи — дать краткое содержание стандарта Open Agile Architecture, чтобы вы могли сами решить, нужно ли его вам изучить подробнее или нет. Подробнее о стандарте
https://habr.com/ru/companies/otus/articles/969122/
#togaf #Open_Agile_Architecture #Open_Group #enterprise_architect #enterprise_architecture #agile #architecture #archimate #architectural_patterns #OAA
-
Используем на практике Business Capability Map на языке Archimate
Business Capability Map (карта бизнес-способностей) — это один из ключевых артефактов в современных подходах к управлению корпоративной архитектурой, особенно в таких методологиях, как TOGAF, ArchiMate и других архитектурных фреймворках. В данной статье разберемся с определением что же такое бизнес-способность, и приведем пример карты бизнес-способностей небольшого бизнеса в области обучения.
https://habr.com/ru/companies/otus/articles/968098/
#togaf #architecture #archimate #capabilities #capability #babok #enterprise #enterprise_architecture #enterprise_architect #business
-
Мифы об ИТ-архитектуре, из-за которых ваш проект стоит дороже
Всем привет. Меня зовут Александр Виноградов, я главный архитектор Ви.Tech – ИТ-дочки ВсеИнструменты.ру. Последние 9 лет занимаюсь ИТ-архитектурой и менеджментом в архитектуре, и сегодня бы хотел поделиться с вами своим топом заблуждений про эту самую архитектуру из серии: «если бы мне каждый раз давали рубль, когда я слышу...». Кому будет полезна эта статья: ● Тимлидам и РП, которые смогут чуть лучше понять, почему архитектор так долго возится со своими картинками. ● Продактам, которых пугают словами «ну здесь нам нужен корпоративный архитектор». ● Разработчикам, которые считают, что архитекторы занимаются исключительно рисованием квадратиков и стрелочек. ● Самим архитекторам, чтобы почерпнуть дополнительные аргументы для дискуссий с коллегами. Вы узнаете, что: ● Не существует «правильных» технологий (и postgres не лучше mysql). ● Архитектор не должен писать код (и почему). ● Что покупка коробочных решений не избавляет от проблем. Миф 1, или «Ты ж архитектор» Да, и что? Под этой фразой могут скрываться аж два заблуждения. Обсудим сначала первое. К примеру, ваш собеседник может думать, что любой человек с должностью/ролью, в которой есть «архитектор», обязан ответить на очень широкий спектр вопросов. И это будут вопросы от «как построить ИТ-стратегию» и «как сделать метамодель» до «как настроить вакуум в постгре под какой-то специфический сценарий». Но очень важно понимать, что видов архитекторов в разных таксономиях много (обычно 4-7). Кратко: ● Enterprise Architect (EA, Архитектор предприятия) – работает на уровне стратегии компании, связывает бизнес-процессы и ИТ.
https://habr.com/ru/articles/932640/
#итархитектура #solution_architect #системный_архитектор #проектирование #enterprise_architect #выбор_технологии #командная_разработка #архитектура_решений #мифы_в_ит
-
Python в enterprise-разработке: почему популярность ЯП распространилась и на корпоративный сектор. Часть 2
Всем привет! Это Леша Жиряков. На прошлой неделе мы начали разбирать , почему Python стал настолько востребован для создания корпоративных программных решений. Сегодня продолжим тему — поговорим об управлении зависимостями, асинхронном программировании в корпоративной среде, тестировании, корпоративной безопасности и других ключевых моментах. Заодно обсудим перспективы Python в enterprise-разработке. Приступим!
https://habr.com/ru/companies/ru_mts/articles/927802/
#python #программирование #исследования_в_ит #enterprise_architect #асинхронное_программирование #корпоративная_безопасность
-
Python в Enterprise-разработке: почему популярность ЯП распространилась и на корпоративный сектор. Часть 1
Привет! Это Леша Жиряков, я руководить бэкенд-команды витрины KION и Python-гильдии в МТС. Как раз о Python сегодня и пойдет речь. Обсудим, почему самый популярный ЯП, по версии TIOBE, так востребован в корпоративном секторе: из простого инструмента автоматизации он превратился в полноценную экосистему для создания критически важных продуктов. Если коротко, причина успеха — в эволюции языка и его экосистемы. Аннотации типов в Python 3.5 сделали доступной статическую проверку кода без потери гибкости динамической типизации. Это решающий фактор для корпоративной разработки, ведь главные требования тут — это надежность и поддерживаемость. Недавно я уже писал о причинах успеха Python в целом, а сегодня хочу подробно рассмотреть его современные инструменты для предприятий: типизированные структуры данных с dataclasses, высокопроизводительные системы валидации msgspec , pydantic 2 и другие библиотеки. То есть все, что помогло ему стать идеальным выбором для серьезных бизнес-решений. Информации много, так что тему разобью на две части. Погнали!
https://habr.com/ru/companies/ru_mts/articles/926932/
#python #программирование #исследования_в_ит #enterprise_architect #языки_программирования
-
Принцип каскадного снижения связанности
Часто ли вы слышите о новом принципе проектирования IT-архитектуры? А об обновлении классических принципов? Попробую вас удивить и привнести что-то новое. 😎 У вас никогда не вызывало недоумения, что связанность и прочность (или связность) — это про примерно одно и то же (и то, и другое — это некая связь), но одно — хорошо, а другое — почему-то плохо? 🙂 Но давайте по порядку.
https://habr.com/ru/articles/894766/
#архитектура #микросервисы #enterprise_architect #solutionsархитектура #принципы_проектирования #паттерн #связанность #связность #coupling #cohesion
-
EA Tool для ИТ-Архитектора
Если самым популярным вопросом о работе архитекторов является “ Кто такие архитекторы и чем они занимаются ?”, то второй по популярности причиной провала архитектурной практики после “ Не сошлись в видении с руководством ” является отсутствие нормального инструмента. Под этим инструментом подразумеваются Enterprise Architecture Tool , которых на рынке представлено огромное множество, примерно такое же, как и различных framework и методологий архитектуры. Кстати говоря о framework’ах, если выбор такого стоит остро и кроме TOGAF ничего не попадается, рекомендую книгу “ The Practice of Enterprise Architecture ” Святослава Котусева, которую я упоминал в публикации на тему навыков архитекторов. Я уже много лет пользуюсь различными инструментами и какое-то время даже занимался продажей одного из таких инструментов (на мой взгляд очень удачного, за парой исключений) и в этой публикации решил поделиться ранее накопленным опытом. Первое и золотое правило в выборе инструмента, и EA Tool в частности: Fools with tools are still fools.
https://habr.com/ru/articles/854240/
#архитектура #архитектура_системы #ea #enterprise #enterprise_architect
-
Пробы на роль Архитектора: вступление
Я тут наткнулся на старую почту с приглашением на собеседование. С пожелтевшими гифками в подписи и просроченным сургучом сертификатов. Дело давнее, пандемийное, так что, думаю, можно рассказывать. Я один не смотрю на сроки NDA, когда подписываю? На всякий случай стоит обезличить и переделать. Тем более, что бонуса за продвижения бренда нет, а наказание всегда найдётся. Так что у нас тут анонимный клуб найма лиц похожих на архитекторов.
https://habr.com/ru/articles/825686/
#system_architect #architect_interview #architecture #panel_interview #experience #true_story #cool #enterprise #enterprise_architect #legacy
-
Укрощаем DNS в Wireshark. Часть 2
В предыдущей статье мы начали рассматривать использование анализатора пакетов Wireshark для работы с DNS. В этой мы продолжим рассмотрение данной темы и поговорим о рекурсии DNS. Здесь принцип обмена пакетами будет немного сложнее, потому что помимо обмена DNS пакетами между клиентом и сервером будет также обмен с авторитетным DNS сервером. Система разрешения доменных имен имеет иерархическую структуру и все DNS-cepвepы должны быть в состоянии связываться друг с другом, чтобы получать ответы на запросы, отправляемые клиентами. И совершенно очевидно, что локальный DNS сервер не может знать информацию об узлах во всех доменных зонах. Тогда в дело вступает рекурсивный DNS сервер.
-
Разбираемся с Cloud Landing Zone
Облачные сервисы в последние годы пользуются большой популярностью. Преимущества всем хорошо известны — это экономия на закупке и сопровождении оборудования, лицензиях, персонале и т.д. Если у нас разворачивается инфраструктура с нуля, то ситуация несколько проще. Мы можем сразу развернуть наши сервисы в облаках и дальше уже тестировать их работу. Конечно, здесь тоже можно столкнуться с различными трудностями, но по крайней мере при создании инфраструктуры с нуля нам не требуется выполнять миграцию. Совсем другая история, когда у нас уже имеется некоторый набор сервисов, функционирующий на железе, и мы хотим перевести их в облака. Тогда всё становится значительно веселее, так как при миграции можно столкнуться с массой сюрпризов.
-
Технологии интеграции ИТ систем
Одной из основных задач для Enterprise архитекторов является проектирование и проведение работ по интеграции различных ИТ систем. Так типичной историей является наличие у заказчика каких-то решений, либо не взаимосвязанных, либо частично связанных между собой и архитектору необходимо встроить свое решение, интегрировав его с теми решениями, которые уже есть у заказчика. Далее мы рассмотрим несколько подходов к интеграции, и начнем с простейшего случая, когда между системами нет интеграции. То есть, представим ситуацию, когда в компании используются несколько независимых информационных систем: складская, бухгалтерская, CRM и финансовая. Между этими системами нет информационного обмена. В результате для выполнения задачи по отгрузке товара, заявки в каждой системе заводятся отдельно и к примеру, менеджеры по продажам после выставления счетов клиентам вынуждены печатать их копии и нести в бухгалтерию. В бухгалтерии они регистрируются в бухгалтерской системе. Бухгалтерия регистрирует поступление денег на счет. Менеджеры по продажам, не имея возможность получить оплаты автоматически в CRM-систему, вынуждены ежедневно осведомляться в бухгалтерии о поступлении денег от клиентов. В результате у нас образуется некоторый «Paper Net», то есть бумажный обмен данными между менеджерами, бухгалтерией и складом, а также двойная регистрация действий (один раз в складской системе, второй раз в бухгалтерской). Кроме того, когда заявки в каждой системе заводятся вручную, то большую роль начинает играть человеческий фактор, то есть ошибки, допускаемые различными специалистами в процессе обработки заявок в системах.