Lecture 11: Assessing Existing Systems & Solution Options

        Learning Objective: Transition from architectural theory to strategic planning. Learn how Enterprise Architects conduct system studies, evaluate application characteristics, and select the appropriate integration solution.
    

1. The Role of the Enterprise Architect

Up until now, we have explored how technologies like ESB, APIs, MOM, and iPaaS work. However, in the real world, you do not start with a blank slate. Organizations already have dozens or hundreds of existing systems.

Before writing a single line of code, an Enterprise Architect must conduct a System Study to assess the "As-Is" architecture and design the "To-Be" integration landscape.

2. Evaluating Application Forms & Characteristics

Not all applications can be integrated in the same way. The first step in an assessment is categorizing the existing systems based on their form and characteristics:

1. COTS (Commercial Off-The-Shelf)

Software bought from a vendor (e.g., SAP ERP, Microsoft Dynamics). You cannot change the source code. You are restricted to the APIs, database views, or file export formats the vendor provides.

2. Custom-Built Applications

Software built in-house. You have full control over the source code. You can easily add new REST APIs, embed Kafka producers, or change the database schema.

3. SaaS (Software as a Service)

Cloud applications (e.g., Salesforce, Workday). You have no access to the database or the servers. Integration must happen via the internet using vendor-provided APIs (usually REST or GraphQL).

4. Legacy Systems

Old, monolithic systems (e.g., Mainframes, old AS/400 banking systems). They usually lack modern APIs and often rely on Batch File Transfers (FTP/SFTP) or raw database links.

3. The Integration Pattern Decision Tree

Once you understand the characteristics of your applications, you must choose a solution. Gregor Hohpe, author of Enterprise Integration Patterns, defines four primary styles of integration. Selecting the right one is a matter of evaluating real-time needs, coupling, and system constraints.

Figure 1: Enterprise Integration Pattern Decision Tree (Adapted from Gregor Hohpe)

4. Documenting the Solution: The ADR

After studying the systems and using the decision tree, the Architect must document their decision so developers understand why a specific technology was chosen. This is done using an Architectural Decision Record (ADR).

Code Example: An ADR Document (Markdown/Text format)

Below is a standardized template showing how an integration decision is formally documented.

# ADR 005: Integration between Legacy ERP and Cloud CRM

**Date:** 2026-03-16
**Status:** Accepted
**Context:** We need to synchronize Customer profiles from our On-Premise Legacy ERP (Oracle 10g) to our new Cloud CRM (Salesforce). The CRM users need customer data updated near real-time to make sales calls. The ERP is a COTS application that does not expose modern REST APIs, but it can trigger database events.

**Decision:** We will NOT use File Transfer (FTP) because the business requires real-time updates. 
We will NOT use direct REST APIs because the ERP cannot generate HTTP requests natively.
We WILL use an iPaaS Agent connected to the ERP Database to detect changes (Change Data Capture), format the data into JSON, and push it asynchronously via a Message Queue to Salesforce.

**Consequences:** * Positive: Loose coupling. The ERP performance is not impacted by CRM downtime.
* Negative: Requires purchasing and configuring an iPaaS secure agent inside our firewall.
* Constraint: Data mapping logic will reside in the iPaaS, not in the applications.

        Discussion Prompt for Students: Imagine you are the Enterprise Architect for a local government agency in Bali. You are instructed to integrate the Population Database (Capil) with the Hospital Management System. The hospital needs real-time validation of patient IDs, but the government database is heavily restricted and cannot handle more than 50 requests per second. How do you choose a solution that provides fast hospital check-ins without crashing the government database? (Hint: Discuss caching, rate-limiting API Gateways, and replication).
    