Size: a a a

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

2019 November 18

GK

Gennadiy Kruglov in Архитектура ИТ-решений
1) экосистемы и платформы воспринимают как синонимы
2) ссылаются на классификацию платформ от Ростелекома и на материалы Маккинзи
3) на самом деле хотят площадки по вовлечению и "соединению" разных людей, что похоже на маркетплейсы
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Технически, это комплексные транзакционно-аналитические решения. На верхнем уровне микросервисная и лямбда архитектуры
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Транзакционные понятно почему. Аналитические, потому что хотят рекомендательные сервисы и отчётность, прежде всего дескриптивную аналитику.
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Какой нужен архитектор. Наверно тот, кто умеет строить комплексные транзакционно-аналитические решения.
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Критикуйте
источник

DZ

Denis Zarin in Архитектура ИТ-решений
Геннадий! Мне кажется, что экосистемы / платформы -- это сильно про взаимодействие с 3rd parties.
Или все эти интеграции / стандарты / api уже по умолчанию включены в skillset архитектора?
источник

DZ

Denis Zarin in Архитектура ИТ-решений
Denis Zarin
Геннадий! Мне кажется, что экосистемы / платформы -- это сильно про взаимодействие с 3rd parties.
Или все эти интеграции / стандарты / api уже по умолчанию включены в skillset архитектора?
Или, исходя из оригинального запроса, все-таки редуцируем к маркетплейсам?
источник

AT

Alexander Teterkin in Архитектура ИТ-решений
Maxim Smirnov
Остановил опрос. Почти четверь участников относится к ЦЭ с умеренным оптимизмом. Столько же проголосовало за "Не догоним, так согреемся"
Только четверть оптимистов. Интересно... 🤔
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Denis Zarin
Или, исходя из оригинального запроса, все-таки редуцируем к маркетплейсам?
Денис, на мой взгляд первое не противоречит второму. Маркетплейсы - это сильно про взаимодействие.

Api, интеграции конечно важны. Но, решения такого класса сложные, нужен высокоуровневый архитектор, который имеет кругозор в технологиях и умеет выстраивать коммуникации между разными стейкхолдерами. Потому что команд скорее всего будет много, а Api в зоне ответственности команд
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Или я не понял вопрос
источник

DZ

Denis Zarin in Архитектура ИТ-решений
Gennadiy Kruglov
Денис, на мой взгляд первое не противоречит второму. Маркетплейсы - это сильно про взаимодействие.

Api, интеграции конечно важны. Но, решения такого класса сложные, нужен высокоуровневый архитектор, который имеет кругозор в технологиях и умеет выстраивать коммуникации между разными стейкхолдерами. Потому что команд скорее всего будет много, а Api в зоне ответственности команд
Спасибо! Про разные уровни услышал
источник

d

dreamore in Архитектура ИТ-решений
Я вижу экосистемы как очередной виток истории "разделение-консолидация"
Сначала создаются приложения под каждую потребность индивидуально. Потом хочется интеграции приложений между собой. Потом приходит понимание что хочется разбить на кусочки...
источник

d

dreamore in Архитектура ИТ-решений
Между каждым витком происходит перераспределение ответственности и меняются цели
источник

RT

Roman Tsirulnikov in Архитектура ИТ-решений
Нам IBM снова показывали свою очередную интегрированную платформу “для всего”.
Мир вращается по спирали, монолиты еще вернутся.
источник

AS

Andrei Soloschak in Архитектура ИТ-решений
Gennadiy Kruglov
Какой нужен архитектор. Наверно тот, кто умеет строить комплексные транзакционно-аналитические решения.
Здесь наверное надо исходить из того, что заказчик точно не знает, что ему нужно. То есть нужно прийти с решением и объяснить, что это именно то, что он хочет. Твой вариант выглядит вполне солидно с этой точки зрения.
Но если все же заказчик знает чего хочет, что вряд ли, то наверное нужно детально понять потребности, составить Lean Canvas. А уже потом думать о решении... Оно может быть другим...
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Andrei Soloschak
Здесь наверное надо исходить из того, что заказчик точно не знает, что ему нужно. То есть нужно прийти с решением и объяснить, что это именно то, что он хочет. Твой вариант выглядит вполне солидно с этой точки зрения.
Но если все же заказчик знает чего хочет, что вряд ли, то наверное нужно детально понять потребности, составить Lean Canvas. А уже потом думать о решении... Оно может быть другим...
Заказчик точно знает, что он хочет экосистему, но не может объяснить, что это такое. Заказчик нуждается в том, чтобы ему объяснили, что такое экосистема и предложили концепт её реализации. А поскольку закачик точно значет, что он хочет экосистему, но не может объяснить, что это такое, он также хочет и архитектора экосистемы, но не может объяснить какого именно.
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Как я понял, заказчики хотят чтобы им подобрали архитектора, а заодно рассказали про экосистемы.
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Или спокойно выслушали их мнение и согласились.
источник

AS

Andrei Soloschak in Архитектура ИТ-решений
Gennadiy Kruglov
Заказчик точно знает, что он хочет экосистему, но не может объяснить, что это такое. Заказчик нуждается в том, чтобы ему объяснили, что такое экосистема и предложили концепт её реализации. А поскольку закачик точно значет, что он хочет экосистему, но не может объяснить, что это такое, он также хочет и архитектора экосистемы, но не может объяснить какого именно.
"Ну, значит, та самая блоха с того берега лужи" (с) Заказчик который знает чего хочет, в первую очередь знает зачем это ему нужно. Экосистема это решение, но не проблема. С остальным в целом согласен :)
источник

AS

Andrei Soloschak in Архитектура ИТ-решений
Но это не единственный вариант :)
источник