When choosing an integration architecture for an organization, many different patterns are available. Antti Toivanen compared them to food. What would you like to have?
Deliciously edible integration architectures are available today. New and old, good and bad architectural models are included. What kind of food micro service would it be? And how is SOA eaten? Who has already tasted the fresh mini service? Is it worth touching on the integration spaghetti?
In spaghetti, the systems - meatballs in the picture - are connected directly to each other. It looks delicious at first and is cheap to implement if you don’t have to think about the belly aches that follow for IT and maintenance after cooking - that is, the project. Architects also know this as point-to-point integration architecture. In larger portions, it is impossible to ingest even partially, as removing one meatball (system) from the plate will result in the others rolling on the breast. Smells bad and is messy. "Cheap, but tastes unbearably bad"
There are fewer unnecessary carbohydrates (connections) in a centralized architecture. Meatballs - or monolithic systems - stay in order and replacing them does not cause meatballs to roll into your arms. A traditional first integration dish from which gourmets will soon move on to the next dishes. A basic utility filler that also allows for centralized process control. However, centralized integration does not take away hunger as it does not scale. Centralized control is a good thing, centralized performance is not. In the picture, the middle meatball is called the integration platform. "A good appetizer but didn't go hungry"
In this dish, services have been detached into generic layers. The lowest are the systems and the second lowest are the connectors of the integration platform connected to them. The integration platform publishes business functions on the next floor as reusable services that can be utilized by business solutions or processes. Excessive granules in the service layer often stick to the throat of the business. Made with too much piety, SOA lasagna is also expensive and slow to produce. "Expensive and came a little dazed"
Business functions are enjoyed as completely uncoupled mouthfuls. Universal use is sacrificed above speed, and there are often several sushi services on the plate that are similar to each other. This dish does not include centralized control, but effectively takes hunger away at a reasonable cost. Often causes wonder, as few find the willingness to eat this dose. This is not served with ERPs and CRMs, but each mouthpiece - i.e. the micro service - owns its own business data - at least according to a strict interpretation. For some reason, it is often mixed into a mini-service style. A great choice when creating an entirely new service for which there are no ready-made applications. "Does this go with SAP? No."
Very sushi-like in texture, but the edible pieces are enjoyed in suitably small whole. Works well with existing business systems. Some see this as the right way to make SOA architecture suitable mouthpieces without the fuss of lasagna. Delivered from the integration platform. "Works - very good for the price."
Expensive specialty of culinary coders. After a terrible effort, there is not much to eat. Making a single call requires setting dozens of parameters with your own calls - this is usually only enjoyed with lots of Akvavit. Avoid by all means.
"I starved even though my fingers bleed."
What kind of architecture does your company eat?
Author has over 22 years of experience in area of enterprise system integration and integration architectures.