Every large Czech company has an IT museum inside it. A mainframe from the nineties that nobody knows how to restart. A COBOL program whose author has been retired for five years. And somewhere in between, a dozen Java applications that need to talk to each other. That’s exactly what we tackle with our SOA approach — and here’s what we’ve learned.
The Problem: A Systems Goulash¶
Our typical client — let’s say a mid-sized insurance company — has roughly this technology landscape: a core insurance system on AS/400, CRM in .NET, accounting in SAP, a few Java web applications, and Excel macros that hold everything together. Literally.
Point-to-point integration looks simple at first. System A needs data from system B? Write a connector. System C needs data from both A and B? Two more connectors. But with 20 systems you have potentially 190 integrations, and nobody knows what flows where.
ESB as the Central Nervous System¶
Enterprise Service Bus is not a sexy technology — no startup writes about ESB on Medium. But for enterprise integration it’s the foundation. We use Oracle Service Bus (OSB) because most of our clients are in the Oracle ecosystem.
ESB gives us simple things: message routing, protocol mediation (SOAP, JMS, file, FTP), transformation (XSLT, XQuery), and most importantly — a central point for monitoring and logging. When something isn’t working, you look in one place, not twenty log files.
Canonical Data Model — An Investment That Pays Off¶
Every system has its own data model. The CRM has a Customer with an address as a string. The core system has a CLIENT with the address split into street, city, and postal code. SAP has a DEBITOR with a completely different structure. If you transform data directly between systems, you’ll drown in combinations.
That’s why we define a canonical data model (CDM) — a common language that everything transforms to and from. Yes, it’s work upfront. Yes, the meetings about the data model are boring. But every new system you integrate needs only one transformation (to/from CDM) instead of N transformations to every other system.
WSDL-First Approach¶
This may sound old-fashioned, but we always create WSDL contracts first, not code-first. Why? Because the contract is an agreement between teams. The backend team in Prague and the frontend team in Brno need a clear specification they agreed on before they start coding.
We validate XSD schemas through Schematron for business rules that can’t be expressed in XSD. We version services through namespaces (v1, v2) and maintain old versions for at least a year after a new one is deployed. Backward compatibility is critical in enterprise — you can’t tell a client “rewrite your code, we released a new version.”
Security: WS-Security¶
In regulated environments (banks, insurance companies) HTTPS isn’t enough. You need WS-Security for message-level security — payload encryption, digital signatures, SAML tokens. Oracle Service Bus handles this natively, but the configuration is… let’s say non-trivial.
On our last project we spent two weeks just setting up mutual authentication between OSB and the mainframe system using X.509 certificates. It works, but it’s not for the faint-hearted. Documentation for IBM MQ + Oracle OSB interoperability is sparse, to put it diplomatically.
Monitoring and Governance¶
Deploying SOA is one thing. Managing it is another. Without governance, your SOA landscape will devolve into the same chaos you were trying to escape within a year.
We have simple rules: every service has an owner (both business and technical), an SLA contract with defined response time and availability, and is registered in a service repository. We use Oracle Enterprise Repository, but honestly — even a shared Confluence space is better than nothing.
What I Would Do Differently¶
REST. I know that in my last article I defended SOAP. And for complex enterprise integrations that still holds. But for simpler services — lookup data, notifications, simple CRUD — I would choose REST today. There’s no reason to drag the SOAP overhead where you don’t need the WS-* stack.
And testing. We started addressing automated testing of SOA services too late. SoapUI tests should be part of the CI pipeline from day one. Regression tests for integration points are critical — one small change in one system and the entire integration falls apart.
SOA Isn’t Dead¶
The community talks about SOA being obsolete. For startups, maybe. But for a Czech insurance company with a mainframe from 1995, solid SOA integration via ESB is still the most practical way to connect systems that were never meant to talk to each other. And that’s exactly what we do.
Need help with implementation?
Our experts can help with design, implementation, and operations. From architecture to production.
Contact us