Size: a a a

Архитектура ИТ-решений

2020 April 14
Архитектура ИТ-решений
Архитектор решений (solution architect), пожалуй, самый атипичный представитель семейства ИТ-архитекторов. Вальяжный архитектор предприятия (enterprise architect) стремится выстроить правильный ИТ-ландшафт. Технологически подкованный архитектор ПО (software architect) настаивает на грамотном использовании технологий. Они всегда голосуют за правильное. Solution architect из другой когорты. Он взламывает (to hack) унаследованную корпоративную систему для получения нового качества, не реализуемого в текущих процессах взаимодействия и технологиях. Он нарушает социальные и технологические правила, чтоб продукт или сервис состоялся. Архитектор решений – это больше про авантюризм и про совсем другую степень ответственности. Вся компания будет ждать, когда же он, нарушитель сложившихся устоев и негласных правил, ошибется. Будут ждать, чтоб потом злорадно отметить: ага, мы же говорили, что так нельзя!
источник
Архитектура ИТ-решений
Длинный текст с плохими картинками, но разумными мыслями https://medium.com/@kylegenebrown/whats-the-right-size-for-a-microservice-bf1740370d47
источник
2020 April 15
Архитектура ИТ-решений
Draw.io Вернее, теперь и в будущем Diagrams.netDiagrams.net создает картинки из псевдокода (причем здесь русалки?) https://www.diagrams.net/blog/mermaid-diagrams Лучше бы он создавали диаграммы, а не изображения. Но это посложнее будет
источник
2020 April 16
Архитектура ИТ-решений
it_arch
Архитектор решений (solution architect), пожалуй, самый атипичный представитель семейства ИТ-архитекторов. Вальяжный архитектор предприятия (enterprise architect) стремится выстроить правильный ИТ-ландшафт. Технологически подкованный архитектор ПО (software architect) настаивает на грамотном использовании технологий. Они всегда голосуют за правильное. Solution architect из другой когорты. Он взламывает (to hack) унаследованную корпоративную систему для получения нового качества, не реализуемого в текущих процессах взаимодействия и технологиях. Он нарушает социальные и технологические правила, чтоб продукт или сервис состоялся. Архитектор решений – это больше про авантюризм и про совсем другую степень ответственности. Вся компания будет ждать, когда же он, нарушитель сложившихся устоев и негласных правил, ошибется. Будут ждать, чтоб потом злорадно отметить: ага, мы же говорили, что так нельзя!
Ещё несколько отличий солюшена от других архитекторов:
- наличие нескольких вариантов реализации, а не одного, безоговорочно «правильного»
- выбор варианта реализации в большей степени на заказчике, а не на ИТ. Ну или коллегиальное решение всех заинтересованных лиц
- решение выбрано в тот момент, когда все заинтересованные лица договорились.Пока не договорились – рано что-либо делать
- фокус на интеграции приложений, а не на обсуждении того, что там внутри. Главное, чтоб внутри приложения сидел человек, который пообещает сделать всё, что от него требуется
- причем интеграция— это не взаимодействие точка-точка, а длинное путешествие сквозь множество систем
- требования – субстанция относительная, сегодня их больше, завтра меньше. Решение – это русло реки в котором течет функционал. Лишь бы река полностью не пересохла, но и не вышла бы из берегов

... можно продолжать еще долго
источник
2020 April 17
Архитектура ИТ-решений
it_arch
Архитектор решений (solution architect), пожалуй, самый атипичный представитель семейства ИТ-архитекторов. Вальяжный архитектор предприятия (enterprise architect) стремится выстроить правильный ИТ-ландшафт. Технологически подкованный архитектор ПО (software architect) настаивает на грамотном использовании технологий. Они всегда голосуют за правильное. Solution architect из другой когорты. Он взламывает (to hack) унаследованную корпоративную систему для получения нового качества, не реализуемого в текущих процессах взаимодействия и технологиях. Он нарушает социальные и технологические правила, чтоб продукт или сервис состоялся. Архитектор решений – это больше про авантюризм и про совсем другую степень ответственности. Вся компания будет ждать, когда же он, нарушитель сложившихся устоев и негласных правил, ошибется. Будут ждать, чтоб потом злорадно отметить: ага, мы же говорили, что так нельзя!
Пятничное: Мне бы следовало стать писателем и сочинить рассказ Интернет забытых вещей - подражание сказке Успенского Гарантийные человечки о забытых в бытовой технике персонажах, отвечающих за её исправность на время гарантийного срока. Может кто читал в детстве.

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

Вредный он персонаж по всеобщему разумению. Лучше б я книжки пошел писать ;-)
источник
Архитектура ИТ-решений
it_arch
Проанонсирую вебинар: https://www.itexpert.ru/rus/webinars/AWS-WEB/
Не ожидал такого большого количества регистраций, учитывая текущие времена. Изучаю ваши вопросы. На что-то начну отвечать здесь еще до вебинара
источник
Архитектура ИТ-решений
Вот оно как: https://www.it-world.ru/it-news/it/152779.html на инфраструктуре Сбербанка и Ростелекома, так сказать
источник
2020 April 18
Архитектура ИТ-решений
Замечательные анимированные gif-ки из заметки о том, что пора бы в  k8s легализовать sidecar как специальный тип контейнера в поде https://banzaicloud.com/blog/k8s-sidecars/
источник
Архитектура ИТ-решений
Мои уважаемые подписчики! Расскажите, пожалуйста, как объяснить людям, что любая цифровая услуга начинается с службы поддержки. Услуга может быть простой, сложной, высоконагруженной или не очень, располагаться в центре экосистемы или в её удалённых уголках, но одно должно быть точно - возможность для клиента спросить, что он делает не так или сказать поставщику услуги что тот сделал что-то не так. Двадцать лет назад, когда я пришел в мобильную связь это было всем очевидно. Сейчас есть много всяких книжек, презентаций, видео, модных слоганов, типа Human by Exception, но не могу найти авторитетного источника, говорящего о важности в цифровом мире работы с претензиями и обращениями. Подскажите куда смотреть…

Заранее благодарен!
источник
2020 April 20
Архитектура ИТ-решений
Прежде чем разбирать вопросы к вебинару Проектирование по событиям, надо немного поговорить про управляемые событиями архитектуры. Сам термин появился лет двадцать назад как своего рода альтернатива сервис-ориентированным архитектурам или, если угодно, SOA 2.0 (подробнее см. Event-driven architecture) Потом много чего происходило и с термином и с управляемыми событиями архитектурами. Если разбирать всё, то экскурс получится не только обширный, но и довольно занудный.
Потому перенесемся сразу в 2017 год к выступлению Мартина нашего Фаулера The Many Meanings of Event-Driven Architecture на GoTo Conference в Чикаго. Кому лень смотреть всё выступление – в первом комментарии приведены отметки времени. Краткий обзор озвученных рассуждений здесь: https://martinfowler.com/articles/201701-event-driven.html
источник
Архитектура ИТ-решений
Частый и довольно важный вопрос, от зарегистрировавшихся на вебинар: а в чём именно разница между описаниями цифровых услуг и традиционными функциональными требованиями?

Есть много осязаемых различий. О них я подробней расскажу на вебинаре. Но есть и неявное, но принципиальное различие в подходе к дизайну услуг. Заключается оно в том, что акцент с продукта сместился на клиента. Т.е. раньше компании разрабатывали продукты. Что представляет собой продукт было более-менее ясно, но не особо понятно для кого именно нужен этот продукт. Теперь времена CustDev-а, т.е. мы намного лучше представляем для кого, но всегда представляем что именно собираемся сделать. Это довольно сильно влияет на дизайн клиентского опыта и на подходы к разработке решения. А еще между клиентом и продуктов появилась сущность кампания… Ну и т.д...
источник
Архитектура ИТ-решений
… кстати, когда госструктуры начинают рассуждать, что им нужна цифровая платформа для сокращения количества информационных систем в разных ведомствах, сразу ясно, что они еще в прошлом, а не с нами. Иначе бы они озвучивали бы тезис, что платформа им нужна для того, чтоб проще и полнее закрывать потребности разных групп клиентов, независимо от того, какое из ведомств отвечает за ту или иную часть услуги, ну или что-то подобное. В этом случае скепсиса в отношении подобных инициатив было бы меньше
источник
2020 April 21
Архитектура ИТ-решений
17:00 MSK Проектирование по событиям: https://youtu.be/eR_PbrQ7PwQ
источник
Архитектура ИТ-решений
https://youtu.be/oMSzGc5bDr4 Программа по ссылке https://www.asyncapiconf.com/
источник
2020 April 22
Архитектура ИТ-решений
it_arch
Почему архитектурные эскизы становятся всё более востребованы? Раньше люди умели читать. Большинство сотрудников внимательно изучали документы, стараясь понять, что там написано. Только обчень большим начальникам рисовали слайды с красивыми графиками. Сейчас сотрудники утрачивают способность к вдумчивому прочтению документов. Они ролики на YouTube смотреть умеют, а вот документы читать - не очень. Можно сокрушаться на эту тему, а можно относится к этой тенденции более диалектически. Многие ораторы древности тоже не писали колонки в популярные еженедельные издания, а выступпали на площадях. Мы знаем об их идеях по запискам учеников. Похоже, что сегодня жанр устного творчества отыгрывает утраченные позиции. Но надо учитывать следующий момент. Большим начальникам и слушателями публичных лекций, вы обычно рассказываете очень простые вещи. Их можно воспринять с голоса. В крайнем случае оратор поможет себе красноречивой жестикуляцией. Технически сложные вещи с голоса воспринимаются плохо.

Нужна картинка!

(насколько большее число людей восприняло бы этот текст, будь он нарисован)
Меня вчера спрашивали про Domain Storytelling, а в цитируемом сообщении (и том, что после него) я немного досадовал по поводу этого подхода
источник
2020 April 23
Архитектура ИТ-решений
Поделюсь событием: T-Meetup Online: Architecture as Code
Вы не успеваете задокументировать архитектуру приложения, потому что спринт очень короткий? Тогда подумайте об автоматизации ваших ежедневных задач," — советует архитектор T-Systems Сергей Лукин
https://t-systems-russia.timepad.ru/event/1302333/https://t-systems-russia.timepad.ru/event/1302333/
источник
2020 April 24
Архитектура ИТ-решений
Вот какую картинку нашёл
источник
Архитектура ИТ-решений
Термин Micro-Web-Service появился в 2005 году. Его использовал Питер Роджерс, выступая на конференции Web Services Edge. Всё было выражено одним слайдом: одним из типов ресурсов сети могут быть программные компоненты, реализованные в произвольных средах исполнения,  обнаруживаемые по своим URI и допускающие интеграцию в стиле Unix-like pipelines
источник
2020 April 27
Архитектура ИТ-решений
Поработав в центральном и коммерческих банках, я довольно скептически настроен в отношении BIAN. Да и Archimate стараниями The Open Group движется в некотором, не ясном для меня направлении. Тем не менее, поделюсь новой статьей Ирины Блажиной https://habr.com/ru/post/499092/ Ведь может так случиться, что взаимодействие этих двух вещей рано или поздно принесет неожиданные, но так давно ожидаемые финансовым сектором плоды
источник
2020 April 28
Архитектура ИТ-решений
Наконец-то! А то мы уже заждались отчета о новых и уже не вполне свежих технологиях, подходах и практиках в архитектуре и дизайне ПО: https://www.infoq.com/articles/architecture-trends-2020/
источник