Комментарии 20
Цифра в тему:
Нет, микросервисы - не в тему сшивания 1С бухгалтерии с OS ERP системой.
Какой-то бессвязный набор лозунгов
Сдается мне, что конкуренты 1С не взлетают из-за проблем с методологией, а не с технологиями...
Мухи, мёд, говно и пчёлы.
п.1 Модульность/микросервисы и прочее разделение. Если процессы взаимосвязаны, то разделение их на несколько систем повлечет доп. затраты на интеграцию. "Модули должны дружить" не из-за технической архитектуры, а из-за бизнесовой, т.к. данные перетекают по процессам из модуля в модуль. И если модули делают разные команды, то и на выходе - окрошка. Иногда на кефире, а иногда на квасе, но всё не сбалансировано.
п.2 Единые стандарты уже есть. Тот же CommerceML, например. А куча "сервисов передачи данных" просто потому что одно и то же в разных кейсах удобнее связывать разными протоколами. При этом формат данных может даже быть одинаковым, а способы связи - разными т.к. все живут на разной инфраструктуре.
Смысл статьи в чём? Давайте все перейдём на сэндвичи, потому что их можно собрать по желанию и перестанем есть щи?! Будем использовать только газовые плиты как стандарт, чтобы сковородки не выбирать?!
По первому пункту предлагаете набивать штат компании еще полусотней человек, которым будут платить еще меньше и только по окладу, чем если бы они работали в условных "консалтингах" для обслуживания разных организаций.
Ну окей, пусть будет один неповоротливый механизм внутри одной компании. Только это приведет к затянутому онбоардингу, как это происходит, например, в тех же компаниях энергетической отрасли (как Россети из поста).
..., а способы связи - разными т.к. все живут на разной инфраструктуре.
Что Вы имели в виду под "разные инфраструктуры"? Ну и под "способы связи разные"?
Спасибо.
"инфраструктура" - система технического обеспечения работы систем автоматизации. Например, часть систем могут быть обеспечены локальными серверами/СУБД, часть в облаке, часть представлена сторонними сервисами.
"способ связи" - протоколы, форматы и методики, позволяющие взаимодействовать разным системам автоматизации между собой. Например http-сервисы, файловый обмен через FTP, доступ к СУДБ по ADO и т.д.
Вот значение слова "разные" в русском языке:
"Разные значение" в русском языке может относиться к нескольким понятиям, в зависимости от контекста. В первую очередь, это может означать различные значения слова или фразы (полисемия) или разные варианты смысла, которые можно извлечь из текста. Также это может указывать на разные, несхожие друг с другом вещи, предметы или людей.
Я выделил жирным то что имеет отношение к моему вопросу. "... локальными серверами/СУБД, часть в облаке, часть представлена сторонними сервисами... " и "..http-сервисы, файловый обмен через FTP, доступ к СУДБ по ADO и т.д. .." все это может быть прекрасно совместимо, т.е. быть схожим и прекрасно коммуницировать.
Если Вы знаете историю ИТ то должны знать что изначально все в ИТ было очень плохо совместимо друг с другом даже в рамках одного и тго же производителя средств ИТ.
Сначала фирма ИБМ выпустила серию компьютеров S/360 совместимых друг с другом и по разным моделям этой серии и по будущим моделям так что сегодня, 60 лет спустя, прграммы написаные в 1964 году выполняются на IBM z17 (апрель этого года) без проблем.
Мало того. В 90-е годы, в конкурентной борьбе с ИБМ, были предложены т.н. "open standards":
"Open standards are technical specifications or guidelines for data, systems, and software that are publicly available, freely usable, and developed through a collaborative process. They promote interoperability, allowing different systems and products to work together seamlessly. Open standards are crucial for fostering innovation, competition, and the exchange of information. "
Все что Вы перечислили создано в рамках "open standards". И проблемой это не является. А если и является, то это уже проблема "open standards".
Из своего опыта могу Вам рассказать что работая на ИБМ мэйнфрэйм, у меня нет проблем коммуницировать ни с Оракл, ни с Линукс, ни по http, ни по ftp, FTPS, sftp, ни в доступах к базам данным в облаках ни к "сторонним сервисам".
Есть только проблемы с людьми, которые выдумывают несуществущие технические проблемы. Стадарт есть стандарт. FTP, http, ODBC, etc... это стандарты и они работают. Надо только уметь ими пользоваться.
Есть только проблемы с людьми, которые выдумывают несуществущие технические проблемы. Стадарт есть стандарт. FTP, http, ODBC, etc... это стандарты и они работают. Надо только уметь ими пользоваться.
Читать RFC и спецификации скучно. Гораздо интереснее смотреть индусов на Ютубе, пылесосить Stackoverflow или "вайб-кодить". А некоторые не могут жить без велосипедов... 😁😁
все это может быть прекрасно совместимо, т.е. быть схожим и прекрасно коммуницировать
а я где-то писал, что "разные" - это несовместимые? Если Вам так удобнее замените на слово "различные", от этого правда не сильно смысл фразы поменяется. Мой посыл был в том, что идея автора исходного поста типизировать все интеграции ("ПДД для IT") утопична. Это как с Вавилоном - можно научить системы "говорить на одном языке", но при этом понимать и эффективно взаимодействовать с друг-другом они не будут, если не строить изначально эффективное взаимодействие. А оно может быть и на разных языках.
Мы вот с вами на одном вроде языке общаемся, а понять друг-друга не можем!)))
Если посмотреть на ландшафт средств современного ИТ то можно увидеть кучу аналогов и еще кучу казалось бы срелств общего применения, например. БД, но с разными уклонами.
Есть несколько крупных вендоров продукты которых между собой совместимы, но с продуктами дрругого вендора не очень то и. Горе тому бизнесу у которого разные функции реализованы на продуктах разных вендоров.
А вендоры специально делают свой продукт в чем-нибудь да несовместимым. Их цель отхватить сегмент на рынке.
Кроме больших вендоров есть сотни помельче и зачастую их продукты просто по разному называются.
Как с этим всем живут я не понимаю.
Когда в конце 80-х еще в СССР пришли западные компании они называли эту проблему "островки автоматизации" и на презентациях рисовали море с островками "Бухгалтерия", "Отдел кадров", и т.п.. Тогда же пришел в наш советский обиход термин ERP (есть еще смежный термин EAM - Enterprise Assets Management).
На мой взгляд это наивно ожидать что производители софта будут о чем либо договариваться что повлияет на их монопольное положение на рынке. То же самое можно сказать про потребителей софта, но в том смысле что у каждой индустрии, а их много, свои требования и свое понимание какой софт им нужен. Индустрии финансов и производству колесных пар для вагонов нужен на столько разный софт что никакая страндартизация не получился.
А вот где стандартизация действительно нужна так это в самом ИТ. В самом деле на сегодня имеется такое множество подходов, возможностей и продуктов (инструментов) для ИТ что отдельно взятый ИТ-шник за всю жизнь со всем этим добром не сможет даже ознакомиться.
Почему это происходит. Очень просто ИТ это бизнес в котором делаются деньги. Деньги делаются небольшим набором американских софтверных гигантов и фирм пониже рангом. Каждый из участников ИТ рынка стремится создать свою нишу и оторвать свой кусок пожирнее. Что значит "создать нишу"? Придумать проблему, накрутить вокруг нее некую идеологию (коючевой фактор) и наклепать на этой идеологии серию продуктов.
Пример из комментируемой статьи SAP HANA. Это что панацея? Да нет конечно. Есть масса решений проблем другими средствами. Да и вообше, зачем понадобилось SAP еще и базу данных придумывать и внедрять. SAP работает и на DB2 и на Oracle и еще на чем-нибудь. Ответ SAP решает задачу расширения и закрепления за сабой клиентской базы.
Таких примеров можно привести много. Во многих "современных" продуктах для ИТ просматриваются давно известные проблемы и решения, лишь названные иначе (Claude это тожке самое что в 70-е, 80-е называлось Data Center, у которых по факту имелись и PaaS и SaaS только называлось это иначе).
Я ни в коем случае не ретроград. Я действующий ИТ-шник и мне 70 лет недавно исполнилось. Я за новое и более эффективное, но я против иммитации и спекуляции в борьбе за рынки сбыта. И я против того чтобы в России насаждалась зависимость от идеологий западных ИТ вендоров. Нам эта идеология даолжна быть чуждой. Мы раньше могли свою иметь и должны к этому вернуться. Я это знаю потому что последние 25+ лет работал и работаю в Канаде на большую канадскую фирму.
это знаю потому что последние 25+ лет работал и работаю в Канаде на большую канадскую фирму.
И Вас ещё не «съели» индусы? А то знакомый DevOps сейчас в Канаде и жалуется на притеснения со стороны кшиариев и вайшьи... Получил от меня совет принять индуизм или буддизм, но почему-то не следует ему, а всё тоскует по березкам.
Я тоже "скучаю по березкам". И мне уже немного осталось скучать.
Что до индусов то в моей сфере ИТ - ИБМ мэйнфрэйм - их нет. Это, наверное, за пределами их способностей. Я вообще уже несколько лет единственный специалист в моей канадской фирме по мэйнфрейм. Полгода назад правда по одному из проектов вместо меня наняли некоего перца по имени Златко. Серб? хорват? болгарин? Я не знаю. Но заменить меня так и не получилось.
Здесь, в Америках, мы, из России, весьма уверено себя чувствуем. Нас мало, но на серьезных позициях нас никто не может преодолеть. Ни индусы, ни канадцы с амерами. Но, опять же, нас мало. А индусов много.
Где я работаю есть русские, украинцы, белорусы. Все устойчиво трудятся помногу лет. Но, да, выше полевых труженников все больше и больше странных имен и фамилий. И это не таджики, узбеки и азеры. Но их много и что они делают не очень понятно. На нижнем уровне у нас коренные англосаксы и европейцы типа нас. Китайцы тоже отстой на самом деле. Вьетнамец недавно появил, фамилия NG, Нгуйен, понятное дело. но ментально он англосакс. Здесь все перемалываются если не в первом поколении, то во втором в англосаксов. Умеют анлосаксы это делать. Нам еще учиться и учиться. Но это не наш путь.
Из истории стандартов в ИТ. Перевод на русский язык из Википедии (кстати слово архитектура в обиходе ИТ-шников тогда примерно и появилось, но им пользовались более адекватно чем в эти дни):
Systems Application Architecture (SAA), анносированна в 1987 году, представляет собой набор стандартов для компьютерного программного обеспечения, разработанного IBM. Инициатива SAA была начата в 1987 году под руководством Эрла Уиллера, «отца SAA». Целью было внедрение SAA в операционные системы IBM, включая MVS, OS/400 и OS/2. AIX — версия операционной системы UNIX от IBM — не была целью SAA, но имеет совместимость с семейством SAA. SAA не определяла новые стандарты, а выбирала из существующих руководств и программного обеспечения IBM. IBM также приобрела некоторое стороннее программное обеспечение у таких разработчиков, как Bachman Information Systems, Index Technology, Inc. и KnowledgeWare, Inc. Они должны были быть внедрены единообразно во всех средах, совместимых с SAA. Стандарт был «разработан для того, чтобы прикладные программы выглядели и работали одинаково во всем диапазоне персональных вычислительных систем компании, процессоров среднего уровня и процессоров System/370». SAA был назван «сложным, непонятным и потенциально трудным для изучения». Позже, при Лу Герстнере, IBM тихо прекратила использование парадигмы «SAA». К 2001 году о SAA говорили в прошедшем времени. Однако многие из отдельных компонентов SAA все еще используются по состоянию на 2014 год.
Собственно и в 2025 году этот стандарт используется там где он был внедрен, но уже в новых версиях.
Компонетами SAA являются:
Common Programming Interface (CPI) стандартизировал компиляторы и интерфейсы прикладного программирования среди всех систем, участвующих в SAA, с целью предоставления «общего интерфейса программирования для всей линейки компьютерных продуктов IBM — ПК, System/3x, System/370. Это подразумевает, что в рамках SAA программа, написанная для любой машины IBM, будет работать на любой другой».
Целью Common User Access (CUA) было обеспечение «общего пользовательского интерфейса для всей линейки продуктов IBM. Пользователь, использующий ПК, должен видеть те же меню, клавиатуры и процедуры, что и на терминале 3270».
Современному читателю, особенно российскому, термин "терминал 3270" не говорит ни о чем потому можно понимать этот фрагмент фразы как "одинаково с...". Терминал 3270 на то время был более выразительным средством визуализации чем, например, экран ПК под MS-DOS.
Стандарт Common Communications Services (CCS) определял методы, с помощью которых взаимодействовали гетерогенные системы. CCS зависел от Advanced Program-to-Program Communications, также известного как APPC или LU6.2, Systems Network Architecture (SNA) PU2.1 или Low Entry Networking для одноранговых сетей и SNA Management Services для управления сетью.
Позднее, в 1999 году с распростроненнием использования TCP/IP был разработан и внедрен
... IBM Enterprise Extender (EE) — стандартный транспортный интернет-протокол для высокопроизводительной маршрутизации трафика IBM Systems Network Architecture (SNA) по IP. Enterprise Extender аналогичен протоколу управления передачей (TCP), но независим от него. Трафик EE и TCP может передаваться по одним и тем же соединениям.
Ну и конечно же нельзф не упоминуть про уще одну архитектуру ИБМ:
Systems Network Architecture (SNA) — это фирменная сетевая архитектура IBM, созданная в 1974 году. Это полный стек протоколов для соединения компьютеров и их ресурсов. SNA описывает форматы и протоколы, но сама по себе не является частью программного обеспечения. Реализация SNA осуществляется в форме различных пакетов связи, наиболее известным из которых является метод виртуального телекоммуникационного доступа (VTAM), пакет программного обеспечения для мэйнфреймов для связи SNA.
Закончу обзор краткой цитатой про приложения SAA:
Common applications (СA) OfficeVision был SAA-совместимым преемником PROFS и AS/400 Office для «автоматизации офиса». Семейство инструментов разработки AD/Cycle было предназначено для упрощения разработки приложений SAA.
Application Services были преcтавленны:
Document Content Architecture определила формат для документов, которыми обменивались различные текстовые процессоры и другое программное обеспечение
Intelligent Printer Data Stream (IPDS) был языком описания страниц, как Xerox Interpress или Adobe PostScript
SNA Distribution Services (SNADS) для хранения и пересылки документов
Document Interchange Architecture (DIA) для электронной почты
Distributed Data Management Architecture (DDM) для обмена файлами и в качестве базовой архитектуры DRDA
Distributed Relational Database Architecture (DRDA) для обмена реляционными базами данных
Из вышеприведенного нельзя не согласиться что стандартизация ИТ на Западе была поднята на довольно высокий уровень уже 40 лет назад. СССР на уровне пользователей в те времена еще не был готов к выходу на этот уровень, но в передовых научных центрах этот опыт был известен и изучался. Скорее всего он был бы освоен, продукты были бы украдены и локализованы. Но случалась революция 1991 года и все пошло другим путем.
Не сказать чтобы на Западе эта стандартизация получила широкое признание, но уже по совсем другим причинам. ИБМ преследовалась антимонопольным законодательством и опираясь на него (были и другие причины) конкуренты ИБМ смогли разрушить монополию ИБМ в ИТ, а вместе с этим и стандартизацию в виде SAA.
Цитаты эффективных менеджеров как обычно показывают их некомпетентность.
История про завод порадовала. Эта история не про ЕРП, а про бесполезных людей и плохое внедрение.
ERP-головоломка: почему российские компании до сих пор шьют IT-лоскутные одеяла?