Pull to refresh
18
0
meteozond @meteozond

User

Send message

Вот обычный человек будет себя хвалить - ему же не поверит никто. Тут же начнутся "где пруфы" и прочие "чем докажешь". А писаки (в хорошем смысле) умеют так похвалить себя, что тебе тут же захочется пойти и купить их произведение.

Что я могу сказать - если за этим и вправду стоит один человек - удачи Вам всяческой в попытке выпрыгнуть из крысиных бегов в мир чистого творчества. Ну и сохранить рассудок, если попытка будет удачной.

Ну а если это очередной проект талантливых маркетологов... да и фиг с ним.

Откуда в итоге жидкость-то взялась понятно?

Раздел теперь выглядит по-другому :(

а можно дать ссылку на эту официальную страницу? если не сложно

А как Вы поняли, что это форма именно гугла?

Я такую же могу сделать...

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

Меня лично это научило, что надо вникать в детали и не бояться расстраивать руководителя тем, что его влажные мечты противоречат законам физики.

Не в этом дело, слежка нужна, что бы найти повод...

Я так понимаю, это полезно для разработки под разные версии python?

Как-будто события из параллельной вселенной... П ро ТРИС много слышал. Насколько раз пытался занырнуть - безуспешно. Видимо требуется существенный ресурс для освоения. Не хватает такого инструмента в разработке, а то везде велосипеды...

Задача — цифровизация немаленькой группы компаний. Масштаб и интенсивность деятельности — обязывают.

Имеется множество как микросервисов, так и монолитов, не считая коробок, партнерских и легаси систем. В этих системах практически нет данных, которые не нужны другим (точнее людям в других системах и сервисах). По сути все — MDM. Все данные во всех системах становятся Master (контрагенты, сотрудники, учетки, номенклатуры, документы, товары, продажи и т.д.). Естественно в этом богатстве есть данные, которые меняются реже и нуждаются в отдельном процессе заведения — одни вынесены в НСИ системы, но грань эта призрачна (этакий градиент).

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

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

Варианты одного из таких правил — Как оперировать сущностями если они отличаются в разных системах я и предложил в предыдущем комментарии.

По второму пункту. Справочники соответствия и справочники правил соответствия — это данные о том как объекты одних систем соотносятся со справочниками других. Такое на мой взгляд допускается в том случае когда мы пытаемся сопоставить смежные области, например перечень услуг показываемый клиентам и деятельность регулируемую государством. Но никак не в контрагентах, которых в наших масштабах и так немало, а если будут еще и справочники соответствия — вообще туши свет.

Что касается третьего — вопрос продажи в конечном счете поднимается всегда. Какой бы крупной/мелкой не была организация. Лишних денег не бывает. Тем более в кризис. Чаще не целиком, а отдельными решениями — по-этому и важно строить архитектуру так, что бы любой компонент мог быть заменен. И не важно по необходимости или при продаже и развертывании в урезанном окружении. Продают конечно те системы, работа в которых характеризуется не глубиной разделения труда а его количеством. В крупных конторах работает с системой 10 человек в мелкой — 1. Это не отменяет потребность в ней для этого одного человека. Наличие же понятного интерфейса интеграции сделает линейку продуктов более привлекательной и повысит шанс что приобретая одно решение клиент будет приобретать и другие.
Можно обернуть такой сервис таким образом, что бы он соотвествовал требованиям. Для этих задач есть же целый класс систем (не могу вспомнить название) детектирующих изменения и ведущих историю изменений за теми системами, что этого сделать не могут.
Разумеется архитектору на одном решении фиксироваться не стоит, но для команд должны быть прописаны четкие правила для как минимум для 80% случаев. Если такие правила не установлены, обязательно найдутся люди, решающие свои задачи за чужой счет (и не важно «лапки» у них или они «равнее» всех). Особенно в больших холдингах. Я это вижу сплошь и рядом.

Я не верю в регламенты. Сколько не прописывай отвественность — крайним, как в поговорке становится или стрелочник или последний или вообще никто. Отвественность должна ественно проистекать из построенного процесса. Кто виноват — источник и никаких других вариантов.

Возвращаясь к моему вопросу, может быть вы дополните список, который я сформулировал для себя:

1. MDM + создание связанных сущностей типа Контрагент и Юрик со ссылкой на первого при необходимости.
2. Справочники/правила соотвествия.
3. Создание прокси-сервисов, которые как бы предоставляют стандартный интерфейс для легаси и коробочных систем.
4. Полноценное ETL решение, перенаправляющее и приобразующее сущности по необходимости на лету.

P.S. Еще не надо забывыть, что инвестируя в разработку стейкхолдер держит в голове потенциальную возможнось продавать результат в виде коробок, SaaS или PaaS. Как полностью так и покомпонентно. По-этому полностью ксатомные интеграции изнутри отдельных сервисов — на мой взгляд недопустимы.
По контрагентам — очень хороший пример, но встают следующие вопросы:

1. Кто в таком случае должен вести справочники/правила соотвествия? Не будет ли это попыткой решить недостатки архитектуры одной системы (или архитектуры в целом) неоправданным усложнонением?

2. Кто будет отвечать за объект за разные части которого отвечают разные системы? Больше похоже на то, что это все же разные но взаимосвязанные объекты

2. Что делать если интегрируется коробочное решение, доработка которого невозможна или нежелательна? Реализовывать некую прокси, которая будет в этом ELT выполнять функцию трансформации? или полноценный ETL?

3. Какие еще есть решения кроме MDM и справочников соотвествия?
Очень важный и хороший цикл. Разбирая проблемы плохих интеграций, как раз пытаюсь сформировать для себя ответ обозначенный в теме. С нетерпением жду продолжения. Большинство утверждений плюсую со страшной силой.
Хочу обратить внимание на другой аспект проблемы — неравнозначность систем, стимулирующих разработчиков более важных, решать свои проблемы за чужой счет. Выталкивая реализацию или заведомо плохие решения в другие — менее важные системы. Что усугубляется желаением руководства быстрее получить результат, оставив тех долги будущим поколениям.
Мне кажется, тему надо эскалировать в питонячем сообществе, как вариант тут.
Потому что принудительное выведение из строя старых и стимулирование замены их новыми — это форсирование деления (пусть и краткосрочное). Кроме того, процесс деления протекает неравномерно — активнее делятся наиболее пострадавшие клетки. Если считать в среднем по больнице то да, ко времени смерти общий лимит конечно выбранн не будет. Однако, регулярное латание сердца таким вот способом, принося краткосрочное улучшение, в итоге приведет к его скорейшему отказу. Не говоря уже о том, что многие возрастные болезни как раз связаны с потерей клеток.
Это примерно такая же ловушка как пиллинг — кратковременное улучшение состояния эпидермиса в угоду долговечности.
Ну да, проблему предела делений данный метод не устраняет. Даже наоборот, происходит сокращение длительности жизни в угоду временного улучшения состояния организма.
Не хватает чехла с батареей и экраном, а если клавиатуру добавить, так вообще бомба :)
Я свою Аврору уже год жду — они только к производству приступили )

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Date of birth
Registered
Activity