Looking for proponents of tightly coupled design versus SOA

Question

This is kind of a weird question which I inflicted on myself. We're having a bit of a debate at work about how to implement what is in effect pretty much a Service-Oriented Architecture (SOA), with some warts that aren't worth getting into. Namely, it's a bunch of little simple services (mostly, legacy wrappers aren't so little) that'll be used to build SaaS web apps.

Anyway, one of the debate questions is whether to use a shared-nothing approach and have each service communicate with the others via that service's API, or whether to develop some type of shared API library that would be imported by the various services to directly communicate with one another. The latter may remind people of CORBA.

So, my suggestion to the team was that for everyone who feels strongly -- a few of us -- go research and make a well-cited case for how we personally want to implement the system. THEN, to hopefully reduce confirmation bias and enlighten everyone, make a well-cited case for how we DON'T personally want to implement the system. Then we all get back together and hash it out.

My problem is that I'm finding the idea of tightly-coupled, CORBA-like import-a-library design pretty hard to search for, other than CORBA examples anyway. Are there proponents of doing it this way, particularly as opposed to a decoupled SOA architecture? Or just general proponents of the idea in this day and age? I'm in favor of a shared-nothing architecture where each service has its own well-defined API, and now I need to make a presentation for what I am not in favor of, but I'm having trouble even finding any supporting evidence or information that isn't from the pre-SOA era.

Answer 1

Like most "X vs Y" questions, the answer is it depends.

Decoupling is not a silver bullet. While it has many benefits (reusability, modularity, testing, easier maintenance etc...), it can lead to over-engineering of a solution (hence possibly taking longer to create and add more barriers to entry/understanding) and usually has some impact on performance. It is also good to avoid decoupling/abstracting just for the sake of it (unless its quite easy or "low hanging fruit"). Otherwise, make sure you have some decent use cases to support it.

A lot of this depends on your project type, schedule and performance targets. Instead of asking which x is better prior to considering your project, its much wiser to ask how each x can be applied to your project in a concrete and meaningful way, and judge it based on that.