Архитектура ИТ решений. Часть 4. Архитектура приложений. 4.2. Портфель прикладных систем

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

https://habr.com/ru/articles/961910/

#архитектура_приложений #архитектура #архитектура_по #архитектура_систем #слои_архитектуры #уровни_зрелости #итинфраструктура #портфель_проектов #портфельные_инвестиции

conway-errors: порядок в ошибках как часть архитектуры проекта

Однажды при работе с крупной кодовой базой одного фронтенд-приложения я заметил, что функционал постепенно группируется относительно команд (доменов). Каждая из таких групп функционала постепенно накладывает собственные ограничения на архитектуру. Как оказалось, обработка ошибок при сравнении кода двух разных команд неоднородна. В одном случае разработчики структурировали ошибки стандартным наследованием JS/TS, в другом были использованы перехваты возникающих ошибок и логирование. Стало ясно, что нам требуется обобщить подход к тому, как мы структурируем (называем, наследуем) и выбрасываем ошибки. Как показала практика, соглашений о кодировании недостаточно. Что мы хотели получить?

https://habr.com/ru/articles/961184/

#ошибки #ошибки_в_коде #обработка_ошибок #архитектура_приложений #фронтенд #бэкенд

Архитектура ИТ решений. Часть 4. Архитектура приложений. 4.1. Область разработки прикладных систем

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

https://habr.com/ru/articles/960984/

#архитектура_приложений #архитектура_по #архитектура_системы #слои_архитектуры #архитектурные_паттерны #итинфраструктура #итиндустрия #принципы_проектирования #приложения #паттерны_проектирования

Чек-лист, который превращает интеграцию из хаоса в процесс

Добрый день, дорогие читатели! Хотела бы поделиться своим накопленным опытом и предложить вам некий универсальный чек-лист или даже в некоторой степени перечень рекомендаций в разрезе активностей и ролей, который поможет вам при интеграции систем, подготовке новых проектов. Желаю вам приятного чтения!

https://habr.com/ru/articles/960234/

#интеграция #интеграция_сервисов #интеграция_систем #интеграция_приложений #интеграция_данных #проектирование_систем #system_design #архитектура #архитектура_приложений #архитектурные_паттерны

Архитектура ИТ решений. Часть 3. Информационная архитектура

В предыдущих частях курса мы погрузились в масштабность общего восприятия архитектуры в рамках предприятия. Прошли слой Бизнес-архитектуры, рассуждая о работе организаций в терминах бизнес-моделей, бизнес-процессов, потоков ценностей и способностей бизнеса, организационной структуры и прочего. Эти знания уже сами по себе чрезвычайно важны, для организации максимально эффективного функционирования предприятия, даже без учета ИТ составляющей. Но поскольку основная цель нашего курса — это все же развитие ИТ технологий, то с этой позиции представление Бизнес-архитектуры, служит отправной точкой на пути создания ИТ решений, которым предопределено поддерживать и развивать деловые активности предприятия. Так шаг за шагом, мы поднялись на горизонт ИТ-архитектуры. Перед тем как приступить к рассмотрению Слоя информации , давайте все же кратко еще раз остановимся на рассмотрении общего восприятия аспектов ИТ-архитектуры. ИТ-архитектура предприятия (Enterprise IT Architecture) — это системное представление структуры, компонентов и взаимодействий всех информационных технологий , которые поддерживают бизнес-процессы, ценности и стратегию организации. Иными словами — это “скелет” технологической среды , который обеспечивает реализацию бизнес-архитектуры и поддержку бизнес-способностей . Из определения следует, что ИТ-архитектура , является неразделимой частью Архитектуры предприятия , всецело зависит от той мисси, которую в данной организации предопределили для информационных систем. В связи с этим она может фокусироваться на разных подходах к решению и быть:

https://habr.com/ru/articles/958942/

#архитектура_приложений #архитектура #архитектура_по #архитектура_системы #слои_архитектуры #уровни_зрелости #архитектурные_паттерны #итинфраструктура #итиндустрия

Архитектура ИТ решений. Часть 2. Бизнес-архитектура

Продолжаем рассматривать вопросы, связанные с проработкой архитектурных решений в области цифровизации предприятий. Сталкивались ли Вы с ситуацией, когда ИТ проект, в котором задействована сильная команда разработчиков, в конечном счете выпускает программный продукт, не удовлетворяющий потребностям бизнеса? Когда полученный вариант попросту никак не облегчает жизнь компании, не избавляет от ее болей и печалей, не переводит ее процессы на качественно новый уровень. Чаще всего такой итог означает, что затеявшие цифровую трансформацию специалисты, не справились со своей основной задачей и просчитались, скорее всего, еще на этапе анализа. А причина тому - отсутствие экспертизы в области архитектуры бизнеса. И аргумент: «как нам заказчик объяснил, так мы и сделали», служит слабым оправданием. Команда профи, должна была, обследовав предприятие, указать на нелогичность цепочек бизнес-процессов, нерелевантность используемых бизнес-сервисов, избыточность организационной структуры, искажения потоков ценностей и прочие упущения, присущие первоначально сложившейся архитектуре. Квалифицированный специалист в области организации бизнеса должен гарантировать качественный инжиниринг и реинжиниринг деятельности предприятия, используя при этом профессиональные подходы, инструменты и приемы. Результат этих активностей и должен заложить основу для последующей эффективной цифровизации деятельности заказчика. В данном аспекте важно учитывать, что на больших предприятиях цифровизацией будут заниматься множество команд, использующих разные технологические платформы, методологии, и накопленный ранее приватный опыт автоматизации. Их технические новации в свою очередь будут влиять на выстраивание бизнес-решений, определяя то, как бизнес будет меняться и развиваться. А потому, если централизовано не управлять слоем бизнес-архитектуры, то разнообразные ИТ-технологии могут привести к культивированию зоопарка управленческих, финансовых, предпринимательских и прочих бизнес-решений в общей структуре предприятия, вызывая противоречия, неконструктивную конкуренцию, затруднение в управлении и прочие кризисные предпосылки.

https://habr.com/ru/articles/956656/

#архитектура #архитектура_приложений #архитектура_системы #слои_архитектуры #уровни_зрелости #информационная_архитектура #архитектурные_паттерны #архитектура_по #итинфраструктура #итиндустрия

Архитектура ИТ решений. Часть 1. Понятие «Архитектура»

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

https://habr.com/ru/articles/955218/

#архитектура #архитектура_приложений #архитектура_систем #слои_архитектуры #уровни_зрелости #информационная_архитектура #архитектурные_паттерны #архитектура_по #итинфраструктура

Function Object — как основа бизнес логики приложения

В предыдущей статье " Адаптированный паттерн Command с использованием Dependency Injection ", я описывал как инкапсуляция логики приложений в отдельные объекты-функции позволяет получить преимущества в архитектуре приложений. В качестве основы для концепции объекта-функции мной был выбран известный паттерн Command, но обсуждение статьи показало, что читателям тяжело отказатся от слишком узкой специфики паттерна Command и это мешяет восприятию материала. Эта статья пытается исправиль допущенную автором ошибку. Статья является дополнением к предыдущей.

https://habr.com/ru/articles/954516/

#function_object #архитектура_приложений

Мой опыт over-engineering: как 4 микросервиса на Spring Boot убили pet-проект

История о том, как попытка построить «идеальную» архитектуру для простой задачи обернулась системой из 4 сервисов, потребляющей 8 ГБ ОЗУ и 15 ГБ диска. Разбираю свои ошибки и выводы, которые помогут не повторять их другим разработчикам.

https://habr.com/ru/articles/950768/

#java #spring #микросервисы #архитектура_приложений #ошибки_проектирования

PCI DSS глазами архитектора: разбираем кейс передачи карточных данных в ДБО

Привет, Хабр! В этой статье я приоткрою вам самое священное место в любом финтех учреждении - обработку данных платежных систем и особенности работы с CDE сегментом. Вопрос о безопасной передаче карточных данных часто возникает на собеседованиях для архитекторов и senior аналитиков, и он будет полезен не только тем, кто напрямую занимается подобными задачами, но и разработчикам, специалистам по информационной безопасности, а также менеджерам продуктов в финтехе.

https://habr.com/ru/companies/otpbank/articles/944970/

#финтех #финтехпроекты #pcidss #интеграции #интеграции_сервисов #отп_банк #архитектура #архитектура_приложений #информационная_безопасность

Микросервисы vs Монолиты: что на самом деле ускоряет разработку

Привет, Хабр! Поскольку первая встреча прошла очень полезно и интересно, мы решили повторить и снова в эфире телеграм-канала Dev Q&A продолжили дискуссию о микросервисах и скорости разработки. Собрались технические эксперты из BPMSoft, DevTale, Revizto и Диасофт (в лице меня). Обменялись практическими примерами на тему как же упростить жизнь разработчикам и получать результат быстрее, дешевле и качественнее.

https://habr.com/ru/articles/941050/

#микросервисы #микросервисная_архитектура #микросервисные_инструменты #монолит #разработка_программного_обеспечения #планирование_проектов #программирование #квалификация_сотрудников #архитектура_по #архитектура_приложений

Второе пришествие микросервисов: почему в 2025 мы снова в них верим

Привет, Хабр! Недавно принял участие в панельной дискуссии про микросервисы. Планировался холивар «монолит vs микросервисы», но получился, на мой взгдяд, интересный разговор с реальными кейсами. Собрались специалисты с интересным практическим опытом: Павел Куликовский (Цифра банк), Антон Мартынов, Алексей Захаров (Axiom JDK), Андрей Почтов (АЭРО) и Александр Тырышкин (DEVTALE).

https://habr.com/ru/articles/941038/

#микросервисы #lowcode #контейнеризация #контейнеры_docker #монолит #микросервис #микросервисная_архитектура #программирование #разработка_приложений #архитектура_приложений

Spring Modulith: проверяем границы модулей в монолите и события домена

Привет, Хабр! Еще в C++20 появилась явная поддержка модулей в языке. Интересно, но в Java тоже давно искали похожее решение для упорядочивания больших монолитных проектов. Spring предлагает свой ответ – проект Spring Modulith , цель которого дать разработчику инструмент для построения модульного монолита. Он не делает всю работу, но помогает структурировать код по модулям, проверять архитектурные правила и организовывать взаимодействие между этими модулями.

https://habr.com/ru/companies/otus/articles/940314/

#spring #модульный_монолит #архитектура_приложений #границы_модулей #зависимость_модулей #слабая_связность #микросервисы #Spring_Boot

Внедрение зависимостей (Dependency Injection DI), SOLID, ошибки выделения абстракций и чуть-чуть психологии

Мне тут попалась идеальная статья про DI в который нашелся очень интересный пример для разбора. Есть фундаментальные основы, которые почему то никто не хочет сформулировать, а начинающим разработчикам, которые впервые сталкиваются с концепцией DI, в первую очередь надо бы рассказать эти фундаментальные основы, но почему то нет желающих это сделать и у меня даже есть предположения, почему это не получается, я попробую их как-то выразить в том числе. Я знаю что искать ошибки в статьях начинающих на Хабре это плохой тон, и я вряд ли выйду в плюс с такой статьей, но как говорится: Платон мне друг, но истина дороже. В предыдущей статье мы выяснили как создать два класса (Хост и Енкодер, класс А и класс В) один из которых (А) не может работать без использования функций другого класса (В, а может, и без данных из этого класса В не может работать), но при этом совершенно не зависит от этого класса В! То есть класс А может запросто работать с любым другим классом (C, D, … ) вместо класса В, при некотором условии изложенном в предыдущей статье. По моему, та статья может быть хорошей разминкой для понимания концепции Внедрения Зависимостей. И, определенно, эта статья может считаться продолжением темы практической архитектуры ПО.

https://habr.com/ru/articles/938512/

#dependency_injection #dependencies #di #ооп #архитектура #архитектура_приложений #космотекст

Ожидания и Реальность от Роли Архитектора

Я хотел бы поделиться размышлениями о роли архитектора — о том, как мы ее представляем и с чем сталкиваемся на практике. Мы часто создаем вокруг этой роли определенный шарм и завышенные ожидания, которые не всегда соответствуют реальности. Это приводит к разочарованию у тех, кто приходит в профессию. Давайте поговорим об этом честно.

https://habr.com/ru/articles/936452/

#архитектура_приложений

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

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

https://habr.com/ru/articles/934672/

#архитектура_приложений #архитектура_по #библиотеки #libraries #directx #инкапсуляция #incapsulation

Скетч системного дизайна: как одна схема решает множество проблем на старте проекта

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

https://habr.com/ru/articles/933584/

#контекстная_диаграмма #стартапы #архитектура_приложений #архитектура_по #бизнесаналитика #сбор_требований #планирование_проектов #интеграция #интеграция_сервисов #интеграция_систем

[Перевод] Эффективные практики программирования с использованием ИИ чат-бота

В этой статье мы разберём, как использовать агентов в процессе разработки ПО и какие изменения это влечёт в повседневной работе разработчика. Чтобы показать, как может выглядеть подобный новый рабочий процесс на практике, мы создадим простое Angular-приложение, которое ищет статьи в Википедии и выводит результаты в виде списка, используя «режим агента» GitHub Copilot. Назовём его «Search wiki app».

https://habr.com/ru/companies/otus/articles/931608/

#агентный_ИИ #GitHub_Copilot #Claude_Sonnet #генерация_кода #контроль_качества #Angular #архитектура_приложений #пошаговая_разработка #instruction_files

Практические вопросы архитектуры ПО, из чего строить будем?

Вы знаете из чего и как строятся программы? Странно что ни в одной из статей о программной архитектуре вы не найдете упоминаний о том из чего эти программы строятся. Я попробую изложить свое понимание, понимание профессионала с более чем 20-ти летним опытом построения, рефакторинга программ. Возможно я в чем-то, а может и совсем, буду не прав и ошибаюсь, но тогда в комментариях, а может и в новых статьях мы увидим откровения знающих профессионалов, которые разобьют в пух и прах мои рассуждения, то есть в любом случае должно быть интересно. Но, мне кажется, кто-то должен рискнуть начать рассуждать на эту тему.

https://habr.com/ru/articles/929964/

#архитектура_по #архитектура_приложений

Сердце Фреймворка: Философия и Практика Dependency Injection в Angular

Dependency Injection (DI) один из столпов, на которых держится фреймворк Angular. Каждый разработчик, так или иначе, сталкивается с ним с первого дня: запрашивает сервисы в конструкторе, добавляет providedIn: 'root' и видит, как «магия» работает. Но именно в этом и кроется ловушка. Для многих DI так и остается на уровне «магии» удобного механизма, который просто работает. Однако поверхностное понимание этого мощнейшего инструмента неизбежно приводит к архитектурным компромиссам: неочевидным утечкам памяти, сложностям в тестировании, созданию неявных связей между компонентами и, в конечном счете, к коду, который трудно поддерживать и масштабировать. Эта статья не очередной пересказ официальной документации. Это глубокое погружение в архитектуру и философию Dependency Injection в Angular. Наша цель демистифицировать «магию» и превратить ее в предсказуемый, управляемый и мощный инженерный инструмент в вашем арсенале. Мы пройдем путь от фундаментальных принципов инверсии контроля (IoC) до тонкостей иерархического инжектора. Мы разберем на атомы все стратегии предоставления зависимостей, научимся управлять их жизненным циклом и областью видимости. Мы изучим продвинутые паттерны с использованием InjectionToken и multi-провайдеров и поймем, как современная функция inject() меняет подход к композиции логики. Перейти к полному анализу

https://habr.com/ru/articles/931400/

#dependency_injection #angular #ioc #typescript #архитектура_приложений #паттерны_проектирования #provideIn #InjectionToken #treeshaking #Standalonecomponents