Please forgive me if this question is dense.
Background: We have several internal applications that integrate at the database. We are looking at how to break that up, and it seems like moving to an architecture where each application exposes its functionality through services, instead of calling other apps' databases, makes the most sense. This seems like a service-oriented architecture to me. As I look around for info on getting started with a service-oriented architecture, I see a lot of talk around this article: SOA Is Dead; Long Live Services. And I also see this from Martin Fowler & Jim Webber: Does My Bus Look Big In This?.
Question:
SOA is a clever idea, but an enormous hype around it made people writing "SOA IS NOW DEAD". This is not true, just as sentence "Structural programming is dead everybody do OOP now!" is also not always true: sometimes structural code is the only option, but the decision should be made on evaluation, and not on hype. The same is true when talking about SOA: sometimes you will need SOA, sometimes you will need services.