Size: a a a

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

2020 August 26

GK

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

AZ

Anton Zhbankov in Архитектура ИТ-решений
Gennadiy Kruglov
Когда я проектирую решение, инфраструктурные архитекторы, которые проектируют инфраструктуру, также учитывают и аспекты эксплуатации и больше того, они несут отвественность за свои решения
Но отвечает за эксплуатацию служба эксплуатации
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Anton Zhbankov
Но отвечает за эксплуатацию служба эксплуатации
См выше
источник

AZ

Anton Zhbankov in Архитектура ИТ-решений
Gennadiy Kruglov
При проработке решений мы не внедряли инфр. софт, пока не получали одобрение от инженеров со стороны эксплуатации в том числе
И где противоречие?
источник

GK

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

VU

Vitaly U in Архитектура ИТ-решений
Вы ещё подеритесь (с)
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Anton Zhbankov
Что же до опенсорса - предложите сотовому оператору перевести биллинг на него.
Ну, кстати, я видел оператора, который был за Postgress )
источник

AL

Alexander Luchkov in Архитектура ИТ-решений
Gennadiy Kruglov
Пример нарушения коммуникаций - подразделения не могут договориться в принципе, проще вынести взаимодействие на Шину. Или нет описания контрактов, нет сервис дискавери, и только подразделение интеграции осведомлено о компонентах ландшафта.
Я конечно извиняюсь, но мне всегда казалось, что описание любого взаимодействия = описание контракта = описание интерфейса = результат коммуникации. И в моём мире интеграция=взаимодействие, только названное другим словом.
Если говорить о динамических интерфейсах, т.е. изменяемым в после ввода в эксплуатацию, то задаётся способ доставки изменений. Классический пример - это система моделирования реального времени со случайным набором акторов. Т.е. в одном модельном мире запустить несколько заранее определенных разработчиками объектов, о которых система моделирования заранее ничего не знает.
источник

AL

Alexander Luchkov in Архитектура ИТ-решений
Там есть "федерация" сервисов, в каждый момент времени неопределенная по составу и свойствам.
Но при этом каждый из федератов ответственнен за вычисление собственного состояния и рассылку уведомлений о его изменении.
Если кто-то смотрел в сторону HLA, и знает про DDS то оно.
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
В любом случае мы говорим об интерфейсах (контрактах) и адаптерах
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Описание взаимодействия = описание контракта = описание интерфейса = результат коммуникации - это формула из мира идей Платона. В мире вещей  не все даже слово "контракт" знают. Не сталкивался с гордыми разработчиками, которые при слове "контракт" смотрят на тебя как на идиота?
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Приведу такое сравнение. Опытный в душевных делах человек непременно приложит усилия к заключению брачного договора (SLA с ненулевым RPO) на выгодных для него условиях, хотя при этом конечно хочет любить до гроба.
источник

EI

Eugene Istomin in Архитектура ИТ-решений
Alexander Luchkov
Я конечно извиняюсь, но мне всегда казалось, что описание любого взаимодействия = описание контракта = описание интерфейса = результат коммуникации. И в моём мире интеграция=взаимодействие, только названное другим словом.
Если говорить о динамических интерфейсах, т.е. изменяемым в после ввода в эксплуатацию, то задаётся способ доставки изменений. Классический пример - это система моделирования реального времени со случайным набором акторов. Т.е. в одном модельном мире запустить несколько заранее определенных разработчиками объектов, о которых система моделирования заранее ничего не знает.
Я тут пересобираю подход к интеграции, и что заметил:
- "контракт как wsdl/json схема"
- "контракт как результат процесса исполнения сторонами обязательств асинхронной передачи данных"
- "контракт как исполнение бизнес-смысла операции"

это три контракта, в реальности, сложно сводимые вместе по причине "я вот не понимаю ваш язык и ваши цели, а мои простые - вот они. Потрудитесь их гарантировать".
источник

EI

Eugene Istomin in Архитектура ИТ-решений
Eugene Istomin
Я тут пересобираю подход к интеграции, и что заметил:
- "контракт как wsdl/json схема"
- "контракт как результат процесса исполнения сторонами обязательств асинхронной передачи данных"
- "контракт как исполнение бизнес-смысла операции"

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

На вымышленной этой "я прав, так как с моей точки зрения это так" и строится miscommunication, это в тему "взаимодействие и интеграция"
источник

EI

Eugene Istomin in Архитектура ИТ-решений
Eugene Istomin
Я тут пересобираю подход к интеграции, и что заметил:
- "контракт как wsdl/json схема"
- "контракт как результат процесса исполнения сторонами обязательств асинхронной передачи данных"
- "контракт как исполнение бизнес-смысла операции"

это три контракта, в реальности, сложно сводимые вместе по причине "я вот не понимаю ваш язык и ваши цели, а мои простые - вот они. Потрудитесь их гарантировать".
Я тут просто готов признать, что я не видел ещё интеграций, в которых эти три контракта сходились.
Мало жил, может :))
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Eugene Istomin
Я тут просто готов признать, что я не видел ещё интеграций, в которых эти три контракта сходились.
Мало жил, может :))
Это тоже из мира идей, но ведь нужно стремиться приблизиться к идее)
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Eugene Istomin
Я тут пересобираю подход к интеграции, и что заметил:
- "контракт как wsdl/json схема"
- "контракт как результат процесса исполнения сторонами обязательств асинхронной передачи данных"
- "контракт как исполнение бизнес-смысла операции"

это три контракта, в реальности, сложно сводимые вместе по причине "я вот не понимаю ваш язык и ваши цели, а мои простые - вот они. Потрудитесь их гарантировать".
первое - это один из вариантов описания второго
источник

EI

Eugene Istomin in Архитектура ИТ-решений
Gennadiy Kruglov
первое - это один из вариантов описания второго
» В мире вещей  не все даже слово "контракт" знают. Не сталкивался с гордыми разработчиками, которые при слове "контракт" смотрят на тебя как на идиота?

Всё так ) Смотрят )
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Eugene Istomin
» В мире вещей  не все даже слово "контракт" знают. Не сталкивался с гордыми разработчиками, которые при слове "контракт" смотрят на тебя как на идиота?

Всё так ) Смотрят )
Меня и в закат посылали))
источник

EI

Eugene Istomin in Архитектура ИТ-решений
Gennadiy Kruglov
первое - это один из вариантов описания второго
По опыту, для разработчика существует только первый. Про остальные нужно рассказывать по причине того, что он goals видит, а процессы не видит.

А так - да, первый часть второго
источник