Institute of Information Science - University of Miskolc

User Tools

Site Tools

Trace:
tanszek:oktatas:iss_t:software_integration

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
tanszek:oktatas:iss_t:software_integration [2026/02/15 22:11] – [Limitations] kneheztanszek:oktatas:iss_t:software_integration [2026/02/22 11:15] (current) – [Example] knehez
Line 3: Line 3:
 **Definition** **Definition**
  
-Software integration is a development process in which separate software systems—applications and components—are connected so they work together to form a new, unified system.+Software integration is a __development process__ in which separate software systems—applications and components—are connected so they work together to form a new, unified system.
  
-==== Phases ====+==== Integration activity phases ====
  
 **1.) Requirements assessment and planning** **1.) Requirements assessment and planning**
Line 24: Line 24:
  
 **Definition** **Definition**
-The term legacy system refers to IT systems that use older (possibly obsolete) technologies but are still actively operating and play an essential role in an organisation's everyday operation.+A __legacy system__ is an IT system that uses older (possibly obsolete) technologies but is still actively operating and plays an essential role in an organisation's everyday operations.
  
-Why use legacy systems? +Why do we still use legacy systems? 
-  * Long lifetime and stability: Many legacy systems have operated reliably for years or even decades. If a system functions well and is mission-critical, there is often no compelling reason to replace it. +  * __Long lifetime and stability__: Many legacy systems have operated reliably for years or even decades. If a system functions well and is mission-critical, there is often no compelling reason to replace it. 
-  * Cost considerations: Replacing an entire system can be extremely expensive. +  * __Cost considerations__: replacing an entire system can be extremely expensive. 
-  * Complexity: Legacy systems are often deeply integrated into other organizational processes and systems. +  * __Complexity__: legacy systems are often deeply integrated into other organizational processes and systems. 
-  * Risk avoidance: Organizations often avoid the risk of replacement+  * __Risk avoidance__: organizations often avoid the risk of replacement
  
-Why Are They Not Replaced? +Why are they not replaced? 
-  * Cost and lack of resources: Replacement is often not economically feasible, and risk estimation can be difficult due to strict security requirements. +  * __Cost and lack of resources__: replacement is often not economically feasible, and risk estimation can be difficult due to strict security requirements. 
-  * Disruption of business processes: Introducing a new system may significantly disrupt daily operations. Many organizations prioritize operational stability (e.g., banking institutions).+  * __Disruption of business processes__: introducing a new system may significantly disrupt daily operations. Many organizations prioritize operational stability (e.g., banking institutions).
  
 Solutions Solutions
-  * Gradual migration: Instead of replacing the entire system at once, organizations incrementally migrate to new systems by replacing specific components or functionalities. +  * __Gradual migration__: instead of replacing the entire system at once, organizations incrementally migrate to new systems by replacing specific components or functionalities. 
-  * Outsourcing maintenance and operation: Maintenance and operation of legacy systems may be delegated to external service providers, reducing internal costs and specialized staffing requirements.+  * __Outsourcing maintenance and operation__: maintenance and operation of legacy systems may be delegated to external service providers, reducing internal costs and specialized staffing requirements. 
 + 
 +==== Interesting Real-World examples of Legacy Systems ==== 
 + 
 +In many cases, legacy systems serve as the backbone of critical global infrastructure. Some of the most striking examples can be found in the financial sector. Major institutions such as //JPMorgan Chase// and //Bank of America// still rely heavily on __COBOL-based__ core banking systems running on __IBM mainframes__. COBOL, introduced in 1959, remains responsible for processing an enormous portion of the world’s financial transactions. During the __COVID-19__ pandemic, the continued reliance on COBOL became apparent to the broader public when U.S. government agencies urgently sought experienced COBOL developers to maintain unemployment benefit systems. 
 + 
 +Another remarkable case is the __airline reservation infrastructure__ originally developed for American Airlines in cooperation with IBM in the early 1960s. The SABRE system was one of the earliest large-scale real-time transaction processing systems. Although it has undergone continuous modernization, elements of its original architecture still influence its operation today. The system handles millions of transactions daily and demonstrates how evolutionary development can preserve legacy foundations while incrementally adapting to new technological requirements. 
 + 
 +__Public administration__ also provides compelling examples. The U.S. Internal Revenue Service (IRS) continues to operate tax processing systems that date back to the 1960s. Despite multiple large-scale modernization programs costing billions of dollars, complete replacement has proven extremely complex due to regulatory constraints, security requirements, and the critical importance of uninterrupted service. 
 + 
 +In transportation infrastructure, legacy technology can even affect physical operations. Parts of the London Underground’s signaling and control systems have historically relied on hardware and software developed decades ago. In some cases, replacement components had to be sourced from secondary markets because original manufacturers no longer produced them. Such situations illustrate not only software legacy issues but also hardware obsolescence and supply chain risks.
  
 ---- ----
Line 131: Line 141:
     ER[Emergency Department]     ER[Emergency Department]
  
-    MW[Message Oriented Middleware]+    MW[Middleware]
  
     PS[Patient Search]     PS[Patient Search]
Line 208: Line 218:
 ===== Data Sharing ===== ===== Data Sharing =====
  
-A simple approach to integration is data sharing. +A simple approach to integration is data sharing. Data sharing–based integration aims to transfer and share data between systems. This enables individual systems to access and utilize data stored in other systems.
- +
-Data sharing–based integration aims to transfer and share data between systems.  +
-This enables individual systems to access and utilize data stored in other systems.+
  
 Data sharing can take several forms: Data sharing can take several forms:
Line 222: Line 229:
 ===== File-Based Data Sharing ===== ===== File-Based Data Sharing =====
  
-The most fundamental method of data sharing. +The most fundamental method of data sharing. One application writes data, while another application reads data from the same file. The data files are stored in a central location — such as a shared folder (e.g., NFS) or an (S)FTP server. The information flow is unidirectional: A → B.
- +
-One application writes data, while another application reads data from the same file. +
- +
-The data files are stored in a central location — such as a shared folder (e.g., NFS)  +
-or an (S)FTP server. +
- +
-The information flow is unidirectional: A → B.+
  
  
Line 238: Line 238:
 The most common formats are: The most common formats are:
   * Plain text   * Plain text
-  * XML+  * XML, CSV, YAML
   * JSON (in modern systems)   * JSON (in modern systems)
  
Line 377: Line 377:
     DB2[(Replica Database)]     DB2[(Replica Database)]
  
-    A <--> DB1 +    A <-- read/write --> DB1 
-    C <--> DB1+    C <-- read/write --> DB1
  
     DB1 -- replication --> DB2     DB1 -- replication --> DB2
  
-    B1 <--> DB2 +    DB2 -- read --> B1 
-    B2 <--> DB2+    DB2 -- read --> B2
 </mermaid> </mermaid>
-==== Example ==== +Example: E-commerce platform and Warehouse Management System:
- +
-E-commerce platform and Warehouse Management System:+
 The e-commerce platform can be directly integrated with the warehouse database to provide real-time inventory information. The e-commerce platform can be directly integrated with the warehouse database to provide real-time inventory information.
  
Line 394: Line 392:
   * Platform-independent connectivity (e.g., JDBC, ODBC)   * Platform-independent connectivity (e.g., JDBC, ODBC)
   * Multiple instances of identical components may access the same database   * Multiple instances of identical components may access the same database
- 
     * Synchronization issue: Who processes the next record in the queue?     * Synchronization issue: Who processes the next record in the queue?
     * However, it can be an ideal solution for data collection scenarios.     * However, it can be an ideal solution for data collection scenarios.
Line 400: Line 397:
 ==== Limitations ==== ==== Limitations ====
  
-  * Not real-time by default.   +  * Not real-time by default. If one application writes to the database, another application does not automatically receive notification. 
-    If one application writes to the database, another application does not automatically receive notification. +    * Possible solutions: 
- +      * Database notification mechanisms (e.g., PostgreSQL LISTEN and NOTIFY) 
-Possible solutions: +      * Triggers 
- +      * Polling mechanisms
-    * Database notification mechanisms (e.g., PostgreSQL LISTEN and NOTIFY) +
-    * Triggers +
-    * Polling mechanisms +
   * Security considerations: Properly defined access rights are required (table access, permitted operations). Developers often restrict direct visibility of database structures.   * Security considerations: Properly defined access rights are required (table access, permitted operations). Developers often restrict direct visibility of database structures.
- 
   * Lack of well-defined interfaces — this approach provides only data-level integration.   * Lack of well-defined interfaces — this approach provides only data-level integration.
  
Line 430: Line 422:
   * When strict decoupling between systems is a design goal.   * When strict decoupling between systems is a design goal.
   * In highly scalable cloud-native environments where message-based communication is preferred.   * In highly scalable cloud-native environments where message-based communication is preferred.
 +
 +===== Integration Strategy Comparison =====
 +
 +^ Aspect ^ File-Based Integration ^ Database-Based Integration ^ Message Queue-Based Integration ^
 +| Coupling | Tight coupling (shared file format) | Tight to medium coupling (shared schema) | Loose coupling |
 +| Communication Style | Batch, unidirectional | Data-level sharing | Asynchronous message exchange |
 +| Real-Time Capability | No | Not by default | Yes (naturally asynchronous) |
 +| Scalability | Limited | Moderate | High |
 +| Monitoring | Difficult | Database-level monitoring | Built-in queue monitoring (DLQ, metrics) |
 +| Complexity | Low initial complexity | Medium | High |
 +| Transaction Support | No native support | Strong ACID support | Depends on message broker |
 +| Typical Use Case | Periodic data exchange | Shared enterprise systems | Distributed / cloud-native systems |
 +| Interface Definition | File format agreement | Shared database schema | Message contract / schema definition |
 +| Cloud-Native Suitability | Low | Medium | High |
  
tanszek/oktatas/iss_t/software_integration.1771193494.txt.gz · Last modified: 2026/02/15 22:11 by knehez