Service-Oriented Architecture SOA done right

Service-Oriented Architecture SOA? Ugh!

A few days ago I was talking to my friend, and LessAccounting advocate, Beth Damis, who runs Bookkeeping By Beth. She was studying for one of her classes and the topic was on Service-Oriented Architecture (SOA). As we talked through the study points and pretest questions, I was struck by that old feeling about how screwed up SOA is. I remember when SOA was invented and feeling very excited about it. I also remember the years of SOA implementations that were such a mess they didn’t make anything easier.

SOA Goes Bad

The reason SOA goes badly so often is the same reason that architecting a large project, and implementing the architecture without real world (writing of the code) goes bad so often, and is the same reason that estimating projects so often leads to missed deadlines and budgets: while it’s relatively easy (it’s at least learnable with experience) to see the forest through the trees, it’s almost impossible to see the forest, the trees, the leaves, the dirt, the twigs, the mountain side, and the people that will be driving or hiking through forest all at the same time. Seeing that level of detail, breadth, and depth requires the same clarity, insight, and wisdom that’s required to properly architect SOA or correctly estimate a project.

Making Service-Oriented Architecture SOA Work

Service-Oriented Architecture is an extraction done for scalability, easier to maintain code, and segregation of business logic by function. Since you can’t see all possible ends when you start, you’re basically guessing at how things should go. Yes, you are guessing, and saying you’re not takes more hubris than I’d care to have (and I have a lot). If you weren’t guessing, then the database schema at the end of a project would match the design spec at the beginning, and in the history of the world that’s never happened. To make SOA work you have to extract it from existing code. Only then do you really know what should go where. That’s one of the reasons the SOA extraction went so well at Amazon, took existing systems and extracted functionalities and end points.

It’s one of the things we’ve done during the redesign of LessAccounting. Our SOA doesn’t have an HTTP front end, but it’s the same principle with the same benefits. While talking with Beth, I had a loathsome taste in my mouth about SOA, but when it’s done well and for the right reasons, I like SOA a lot.

Related Post