Composite UI for Service Oriented Systems – Fallacies Part III

This blogpost is part of a larger blog post series. Get the overview of the content here.

Interoperability is easier when you only have two similar platforms like .NET and Java. Today we have a variety of languages, platforms and tools such as Ruby, NoSQL and more. Sooner or later your systems needs to interop with other platforms and tools.

Interoperability does work but is usually hard and the costs involved should not be underestimated. It is important to plan for interoperability and budget for it.

Maintenance and support of big ball of mud systems is difficult and expensive. These system often have ripple effects of changes, meaning changing one part of the system affects other parts. Having one single gigantic database in place doesn’t help either. This creates unnecessary coupling. Often these systems are not scalable, if you try it you create more problems than you solve.

Apply loose coupling and modularization internally between your software components. Start thinking about and designing for scale out in advance, or you just may end up being stuck with scale up.

Sorry to tell you but it is almost never finished. Maintenance, bug fixing and extensions/features get usually still added to the system. Maintenance costs over the lifetime of a system are greater than its development costs.

Design for maintenance. Up front developer productivity matters less. Design for upgrades. “Click Once” doesn’t count. Versioning is hard even at the conceptual level. Don’t expect technology to solve it for you.

Where do you want to centralize it and why? If you centralize it you have to keep latency in mind, how do you validate client input and especially these days with multiple languages involved (i.e. JavaScript, C#, T-SQL…) centralization is not possible. What do you do if the business logic changes? You might need both the old and the new version around for some time.

Logic will be physically distributed, just live with it. You can still centralize it in the development view if necessary. When you organize your code by feature it is pretty easy to find the parts which belong together.

Now that we are aware of the fallacies of distributed computing let us step back and look into a traditionally built distributed system. This will be covered in the next post.