Обсуждение

Хотелось бы про "энергетическую" основу модульности услышать. С одной стороны - часто возникает желание развинтить монолитную систему на компоненты/модули - чтобы иметь гибкую взаимозаменяемую архитектурную конструкцию. С другой стороны - чуть не в геометрической прогрессии растут организационные затраты на ее поддержание - интеркоммуникации между "владельцами модулей", сложности в проектировании, арбитраж в поисках причин нештатной работы, а если у владельцев компонент разнятся ценности (инноватор/консерватор) - политика ценообразования - условия саппорта - компетенция команды - то факап обеспечен. Чувствую становлюсь лютым врагом аппологетов интеграционных платформ и решений с их бесконечными data transformation's и MDM data services .. Доктор, это лечится ? ;-)

Так между модулями как раз и возникают все эти data transformations. А внутри модуля всё родное (или такие же data transformations, только которые не мы пишем, а которые там давно работают и не нами отлажены). Дальше важное замечание: вы как раз и написали, что любая межмодульная связь имеет цену (абсолютно конкретную цену проекта интеграции данных, абсолютно конкретную цену времени задержки при передаче данных -- и т.д.). Если бы этого не было, то модулем была бы отдельная подпрограмма, а не приложение, и не какой-нибудь комплекс CAD/PLM в одном месте и ERP с наворотами из той же программной линейки одного вендора или EAM с ещё большими наворотами совместимых "из коробки" программ в другом.

Спасибо. Небольшое уточнение - т.е получается что "неявная модульность" - в виде хорошо отструктурированых подпрограмм, работающих на едином инормационном поле (структуре БД) вполне себе жизнеспособна и удачна по сравнению с той же функциональной архитектурой построенной из слабо-связанных компонент "из коробки". А где тот самый, важный характеристический признак выбора первого или второго. Кажется что он должен быть "ортогональным", не из серии ИТ - деньги, "мода", оргструктура, компетенция команды.. При их равенстве - подпрограмма однозначно убивает интеграцию. (Это чем то напоминает бортовые ЭВМ, в некоторых даже нет по-моему операционки - т.к. крутящаяся прикладная задача и так содержит ее функции - типа многозадачности, обработки прерываний, файловую систему, GUI.. ) BIAN даже провозгласил в 2012 году "zero integration" принцип - посоветовав производителям ПО (для банков) - делать компоненты по единой канонической метамодели со стандартным пакетом интерфейсов и сервисов.

Я не очень понял суть вашего коммента: вызов подпрограммы всегда обозначает максимальную связность всего со всем, но даже в фортране был какой-то аналог базы данных в виде common blocks (ежели вам это что-то говорит). В zero integration я не верю: вообще, интеграция -- это когда системы делались в расчёте на то, что они будут работать вместе. А между модулями, которые проектировались безо всякого знания друг о друге, говорят -- федерирование (подчёркивая более слабую связь).

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

Вообще-то это всё долго обсуждалось на треке по федерированию систем Ontology Summit 2012, я там как раз был сопредседателем с одним из директоров OMG. Мы там и стандартов разных на эту тему кучу пересмотрели. Бытовое (расхожее) использование слов "интеграция" и "федерация (федерирование)" не волнует -- оно нетерминологично, хоть "склеиванием" называй, а когда начинаешь разбираться, что же там такое, то тут оттенки смыслов и предпочитаемое словоупотребление и выползают. Ну, и фиксируются в современных стандартах и докладах на конференциях. Язык, он живёт.

ну мне в общем-то всё равно, что там постановило ЦК КПСС. я говорю о том, как в реальной жизни эти термины используются. слово "интеграция" не предполагает ничего. любые системы могут быть интегрированы. слово "федерирование" подразумевает одинаковость систем по какому-то признаку, который, собственно, и используется для федерирования.

Это мне всё равно, каким словарным запасом пользуются знакомое вам словарное комьюнити. Меня же волнует то, что обсуждают профи как раз по интеграции/федерированию, это ведь мой ежедневный хлеб. Федерирование ссылается не на одинаковость систем, а на их относительную независимость прежде всего. Федерированные системы обычно могут и сами по себе неплохо работать, в автономном режиме. Но да, слово "интеграция" большинством людей используется чохом, означая всё вплоть до взятия интеграла. Ибо всем этим милым людям не приходится разбираться в видах склейки-сборки-стыковки-объединения-интеграции-федерирования-согласования-взаимоувязки-и т.д. систем. Вот тут чуть больше информации (а в слайдах ещё пара терминологических наводок: http://levenchuk.com/2012/03/02/ontology-based-systems-federation/).

моё коммьюнити состоит из профессионалов мирового уровня, типа James Hamilton, если тут мерянье пиписьками началось.

По поводу терминов - дело нотации, и каждый из вендоров - IBM, Oracle и пр стремится в интеграции стать маленьким ЦК КПСС ;-) Ведь что такое интеграция - это по сути сервис, прослойка - который ищет себе место под солнцем, вклиниваясь на поляну функциональных программ/модулей. Если они достаточно умны и гибки - они сами могут реализовать новую функцию, "всосав в себя" деньги за проект. И наоборот - там где модули консервативны - всякие побочные транспорты/шлюзы/обработчики расцветают пышным цветом - как плесень на руинах. Чистая экосистема в условиях ограниченного пищевого ресурса - выживают "простейшие" и "всеядные" и "быстроразмножающиеся" :-)

Для меня James Hamilton ведь ничем от вашего собственного ЦК КПСС не отличается. Есть semantic community (люди, которые одинаково понимают предметную область), есть speech community (которые пользуются одним словарём), это подмножество semantic community. У меня может быть надежда, что мы из одной speech community и просто про разные словари договариваемся с этой "интеграцией", но одинаково понимаем предметную область (какие в ней объекты, как они там себя ведут). Но, похоже, нет: у вас какие-то свои задачи, свои объекты предметной области, а я говорю про какие-то другие задачи, другие объекты другой предметной области. Меня интересует разнообразие ситуаций, при которых две или более (возможно, информационных, а возможно и нет) систем должны провзаимодействовать. Мне нужно больше слов, чем одно. И есть огромное количество людей, для которых это тоже так. Про эти semantic и speech community тоже в стандартах написано, например в OMG SBVR. Ну, и в стандарт это попало отнюдь не потому, что группка стандартизаторов вдруг выдумала эти термины (слова) для сочинённых ими концептов (понятий, каждое из которых может в разных языках и жаргонах обозначаться разными словами). Опять же, мне сам OMG SBVR неважен, но люди там потрудились разобраться, и дали хоть какие-то определения (ибо стандарт собрал спецов именно по созданию словарей). Эти концепты определены и в разных других стандартах, словарях, используются разными тусовками, а в разных языковых комьюнити называются ещё и разными словами (например, speech community я назвал языковым комьюнити, а мог бы речевой тусовкой: слова разные, а концепт один и тот же). Вот, например, semantic community занимающихся manufacturing enterprise interoperability. Решили они как-то по-английски (ибо все принадлежали к разным speech community) договориться таки о терминах, поэтому выпустили стандарт ISO 11354-1 Advanced automation technologies and their applications — Requirements for establishing manufacturing enterprise process interoperability — Part 1: Framework for enterprise interoperability В нём, в частности, написано в пункте 5.4.1 There are three approaches to achieve enterprise interoperability: -- integrated, -- unified, -- and federated. These three approaches were first identified in ISO 14258. Это я не к тому, что я застрял именно на этом стандарте и буду настаивать на этих определениях. Нет, это просто иллюстрация использования разных слов для обозначения разных способов организации взаимодействия. В вашей тусовке, как я понял, все способы обозначают одним словом, в других тусовках одного слова не хватает. Следующим комментом -- фрагмент из этого стандарта, чтобы уж хоть какое-то содержание в этот разговор внести.

5.4.2 Integrated approach In the integrated approach a common form shall be used to represent the exchanged entities. This common form shall be sufficiently expressive to capture those details that affect interoperability of the items to be exchanged, rather than the process or system as a whole. The common form is not necessarily an International Standard, but needs to be agreed by participating enterprises in order to elaborate these entities and build systems accordingly. EXAMPLE Examples of developing interoperability using an integrated approach are ISO 10303, ISO 19440 and OASIS/UNCEFACT ebXML The integrated approach assures consistency and coherence of the interoperating subsystems by focusing on the components that need to interact. These components are then designed and implemented using a common form (or standard) so that interoperability is seen as a designed-in quality. Interoperation between these various components is therefore obtained a priori without any interfacing effort. Subsystems that are integrated in this way have distinct and individual structure, behaviour, or boundaries, but their combined behaviour is perceived to be as one entity and is achi eved by collaboration and coordination through the use of the common form. 5.4.3 Unified approach In the unified approach, a common meta-model, which is applicable for the participating entities and used as a common reference to map existing models’ syntax and semantics, shall be identified and detailed. This meta-model provides at least a reference vocabulary, but could be a complete ontology. Such a meta-model is not an executable entity. Instead, it s hall provide a means for semantic equivalence to enable mapping between entities. Using this meta-model, a translation between the constituent entities is then possible. However, that translation might involve the loss of some informati on because the participating entities can have different extensions or instantiations of the same meta-model. NOTE 1 The unified approach is particularly suitable when developing interoperability for collaborative or networked enterprises. To be interoperable with networked business partners, a new company maps its own model or system to the neutral meta-model without the necessity to make changes on its own model or system. This approach has an advantage over the integrated approach because of the reduced efforts, time and cost in implementation. It is also suitable for a situation where a large company needs to interoperate with SMEs. Normally an SME works with more than one large company; to interoperate with different companies, the unified approach can be a suitable solution in that it facilitates coordination without requiring conformance to potentially conflicting processes or environments. NOTE 2 In the re-engineering situation, syntactic alignment can be achieved through a unified approach that uses a mapping function to create missing elements of the exchange items, but semantic alignment between partners can be very difficult. Therefore, re-engineering is more applicable to developing intra-enterprise interoperability. В следующем комменте как раз federated будет.

5.4.4 Federated approach In the federated approach, there is no sufficiently capable common form or meta-model to guide the interaction between enterprises that need to interoperate . The lack of capability is often related to different terminologies or methodologies that need to be resolved by business entity interaction. While there can be a common understanding between the business entities, in the federated approach, no business entity imposes their own models, languages and methods of work. To establish interoperability, parties shall accommodate and adjust their operations. Interoperation can be supported by providing a priori information about the capabilities of the entities to be involved in the exchange or by employing agents to discover the needed information. Support for the a priori case can be provided by establishing entity capability profile s that hold syntactic and semantic information on both entity inputs and outputs. Interoperability can be established by mapping corresponding input and output information of the entities and identifying inconsistencies. Any remaining inconsistencies shall be resolved by manual interventions. This approach is more suitable for peer-to-peer situations, where each enterprise has resources for negotiation and compromise. The approach is particularly adapted to virtual enterprises, where diverse companies combine their resources and knowledge to manufacture a product for a limited duration. NOTE Using the federated approach to develop enterprise interoperability is most challenging. A main research area is development of a mapping factory that can generate on-demand customized “anybody-anywhere-anytime” mapping agents among existing systems. It is worth noting that a specific support for the federated approach is seen in entity profiles, which identify particular entity characteristics and properties relevant for interoperation (e.g. ISO 15745 and ISO 16100).

>>Я обычно, рассказывая про понятие "система", говорю, что в инженерии "система" и "модуль" чуть ли не синонимы. И, конечно, хороший дизайн -- это правильное проведение границ системы, при котором отнюдь не "всё со всем связано". Каждое соединение имеет цену, и хорошая модульность позволяет эту цену снизить именно за счёт того, что уже не "всё со всем связано". Есть хороший про/контр-пример: перед тем как вводить в эксплуатацию самолет А380, для всех конкретных аэропортов на проводилось тестирование инфраструктуры возможность их приема. В одном из них случился инцидент - при рулежке на взлет самолет задел законцовкой крыла мачту освещения. Проблема, но не смертельная. Запасную деталь привезли попутным рейсовым самолетом. Крыло "люминевое", на заклепках. Отклепать/приклепать законцовку - для трех инженеров - было три дня работы. А вот попозжей авиаобщественность вдруг взбурлила и произвела сравнение. Для "черного" крыла 787го в случае аналогичной проблемы потребовался бы целый балет. Специальным самолетом привести целое крыло, отстыковать (целиком!) поврежденное, пристыковать новое, произвести надлежащие проверки, увезти тем же спецсамолетом мусор на свалку, ибо "высоконагруженные композитные детали неремонтнопригодны"(tm). Т.е. для N*10 инженеров работы на М*10 дней , плюс привлечение нештатных средств, плюс длительный простой самого аппарата. Казалось бы и "модульная конструкция" и "не все со всем связано", однако ж какой наблюдается рост издержек... Так что видимо для "хорошего дизайна" требуется проводить границы систем не просто "правильно" (т.е. "по неким правилам"), но еще и "разумно". Желательно, чтобы единичный модуль и сам был "унутре" модульным. Чтобы, при возникновении нужды, граница области "под фонарем", над которой требуется произвести некоторую деятельность, могла пролегать более-менее произвольно.

Вот-вот. Много-много самых разных спекуляций. Есть ведь и другая сторона той же медали: я, например, знаю, что с рынка из каталогов убирают простейшие прокладки, чтобы менять целый модуль, а не дешёвую прокладку. Даже принтеры с картриджами пытаются картридж модулем представить, а не сам тонер в картридже. Так что на каждый пример стейкхолдеров "большой модуль это плохо" можно привести пример стейкхолдеров с "маленький модуль это плохо". Ответ даст рынок, конечно (сильно искажаемый регулированием, как даже в случае тех самых тонеров). Либо за такие модули будут платить, либо не будут.

Пока границы системы не заданы (т.е. где она начинается и заканчивается), говорить о ней мало смысла. Задачка: где система в следующей цепочке: Частица -> Частицы -> Атом -> Атомы -> Молекула -> Молекулы -> Макромолекула -> Макромолекулы -> Органелла из макромолекул и молекул -> Органеллы -> Клетка ("Ткань") -> Клетки (нейроны и др), ткани -> Нервный ганглий (самая первоначальная модель мира на базе нервной ткани - безусловный рефлекс, обратной связи нет) -> Нервные ганглии (безусловные рефлексы. обратной связи нет) -> Отдел головного мозга, условный рефлекс -> Отделы головного мозга (появление "мозгового пространства" на базе головного мозга, "RAM"+"HDD", условные рефлексы, обратная связь есть) -> Первоначальная, вербальная модель мира -> Модели мира (мифологические, религиозные, личный опыт и т.д.), письменные ("HDD" - глиняные таблички, папирусы, книги) -> Научная модель -> Научные модели (RAM+HDD) -> Протомодель (ИИ и т.п.) -> Протомодели?

Таких цепочек может быть множество, при этом там красиво делается подмена носителя на информацию на этом носителе -- корректность этой подмены я бы обсуждал отдельно. У меня в лекциях вопрос о том, какой критерий используется для опеределения границ системы, задаётся специально. Если вы смотрели эти лекции, вам будет легко ответить на вопрос, где у вас тут спрятана система ;-)