Control Your Engine!

Imagine you’re building a car. You get car parts, including an engine, from various vendors [think COTS software] and different people help you put it together along the way [think contractors & subject matter experts across divisions]. You’re making progress – you have attached the wheels and can push the car through the product line [dev / test]. Now you’re reached the end of the product line. It’s time to start the engine and drive [pilot stage]. The engine turns but doesn’t start. After troubleshooting and double checking your work you find out that the engine [think messaging infrastructure] doesn’t work. The fuel tank is full [messages are sent from originator], the fuel line to the engine is full [message path is traceable], but the engine won’t process the fuel. When you ask for help from the engine integrators they blame the fuel line.

The engine is the mechanism that makes a car move in a similar way that a messaging platform makes software components work together.

The point of the analogy is to remind architects that in the environments where they are constrained by organization’s enterprise architecture the communication patterns and related infrastructure that glues their application may already be predefined. No matter how good the infrastructure products may be, blindly assuming that the people operating the infrastructure are able to configure it for your needs is a recipe for disaster. This is especially true for quality attributes of a system that require high volume of transactions.

In environments where you cannot control the communication infrastructure always design with a backup in mind.

Firebrand Architect on duty: CK

Comments

Popular posts from this blog

Why we do agile

Quality Attribute Refinement