Комментарии 13
Цифра в тему:
Нет, микросервисы - не в тему сшивания 1С бухгалтерии с OS ERP системой.
Какой-то бессвязный набор лозунгов
Сдается мне, что конкуренты 1С не взлетают из-за проблем с методологией, а не с технологиями...
Мухи, мёд, говно и пчёлы.
п.1 Модульность/микросервисы и прочее разделение. Если процессы взаимосвязаны, то разделение их на несколько систем повлечет доп. затраты на интеграцию. "Модули должны дружить" не из-за технической архитектуры, а из-за бизнесовой, т.к. данные перетекают по процессам из модуля в модуль. И если модули делают разные команды, то и на выходе - окрошка. Иногда на кефире, а иногда на квасе, но всё не сбалансировано.
п.2 Единые стандарты уже есть. Тот же CommerceML, например. А куча "сервисов передачи данных" просто потому что одно и то же в разных кейсах удобнее связывать разными протоколами. При этом формат данных может даже быть одинаковым, а способы связи - разными т.к. все живут на разной инфраструктуре.
Смысл статьи в чём? Давайте все перейдём на сэндвичи, потому что их можно собрать по желанию и перестанем есть щи?! Будем использовать только газовые плиты как стандарт, чтобы сковородки не выбирать?!
По первому пункту предлагаете набивать штат компании еще полусотней человек, которым будут платить еще меньше и только по окладу, чем если бы они работали в условных "консалтингах" для обслуживания разных организаций.
Ну окей, пусть будет один неповоротливый механизм внутри одной компании. Только это приведет к затянутому онбоардингу, как это происходит, например, в тех же компаниях энергетической отрасли (как Россети из поста).
..., а способы связи - разными т.к. все живут на разной инфраструктуре.
Что Вы имели в виду под "разные инфраструктуры"? Ну и под "способы связи разные"?
Спасибо.
Когда в конце 80-х еще в СССР пришли западные компании они называли эту проблему "островки автоматизации" и на презентациях рисовали море с островками "Бухгалтерия", "Отдел кадров", и т.п.. Тогда же пришел в наш советский обиход термин ERP (есть еще смежный термин EAM - Enterprise Assets Management).
На мой взгляд это наивно ожидать что производители софта будут о чем либо договариваться что повлияет на их монопольное положение на рынке. То же самое можно сказать про потребителей софта, но в том смысле что у каждой индустрии, а их много, свои требования и свое понимание какой софт им нужен. Индустрии финансов и производству колесных пар для вагонов нужен на столько разный софт что никакая страндартизация не получился.
А вот где стандартизация действительно нужна так это в самом ИТ. В самом деле на сегодня имеется такое множество подходов, возможностей и продуктов (инструментов) для ИТ что отдельно взятый ИТ-шник за всю жизнь со всем этим добром не сможет даже ознакомиться.
Почему это происходит. Очень просто ИТ это бизнес в котором делаются деньги. Деньги делаются небольшим набором американских софтверных гигантов и фирм пониже рангом. Каждый из участников ИТ рынка стремится создать свою нишу и оторвать свой кусок пожирнее. Что значит "создать нишу"? Придумать проблему, накрутить вокруг нее некую идеологию (коючевой фактор) и наклепать на этой идеологии серию продуктов.
Пример из комментируемой статьи SAP HANA. Это что панацея? Да нет конечно. Есть масса решений проблем другими средствами. Да и вообше, зачем понадобилось SAP еще и базу данных придумывать и внедрять. SAP работает и на DB2 и на Oracle и еще на чем-нибудь. Ответ SAP решает задачу расширения и закрепления за сабой клиентской базы.
Таких примеров можно привести много. Во многих "современных" продуктах для ИТ просматриваются давно известные проблемы и решения, лишь названные иначе (Claude это тожке самое что в 70-е, 80-е называлось Data Center, у которых по факту имелись и PaaS и SaaS только называлось это иначе).
Я ни в коем случае не ретроград. Я действующий ИТ-шник и мне 70 лет недавно исполнилось. Я за новое и более эффективное, но я против иммитации и спекуляции в борьбе за рынки сбыта. И я против того чтобы в России насаждалась зависимость от идеологий западных ИТ вендоров. Нам эта идеология даолжна быть чуждой. Мы раньше могли свою иметь и должны к этому вернуться. Я это знаю потому что последние 25+ лет работал и работаю в Канаде на большую канадскую фирму.
Из истории стандартов в ИТ. Перевод на русский язык из Википедии (кстати слово архитектура в обиходе ИТ-шников тогда примерно и появилось, но им пользовались более адекватно чем в эти дни):
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-лоскутные одеяла?