I might sound like a troll, but I would like to seriously understand this deeper. The place I work at has started to use the term MOA, versus SOA as we believe it drives more clarity and want to compare it to the true goals of SOA.
A Mission Oriented Architecture is an approach whereby an application is broken down into various business mission elements, with the database, file assets, batch and real time functionality all tightly coupled in terms of delivering that piece of the functionality. The mission allows the developers to focus on a specific piece of functionality to get it right, and to build it with the ability for that piece to scale as an independent entity within the overall application. By tightly coupling the data, file assets and business logic you achieve the goals of working on a very large problem in bite size pieces.
Some definitions of SOA mix it up with what is essentially a method call on a web service versus a true “service”. As an architect, I have always found it fun getting everyone on the same page regarding SOA.
Is it better to call it a “mission” versus a “service”?
2
Sounds like a bad idea to me.
The whole point of SOA is to design your architecture around simple, composable, loosely coupled services that can be used to achieve not just your current “mission” but also the future “missions” that may emerge (as they always do….).
If you tightly couple everything around a specific “mission”, then you’re just back in the bad old methodology of building a new, project-specific, maybe over-engineered, incompatible software stack for each application. And you’ll probably soon find yourself creating a messy web of point-to-point integrations between them as new requirements emerge.
There’s nothing wrong of course about having a “mission” in itself – in fact it’s a very useful way to stay focused on what actually creates value. But you shouldn’t fall into the trap of structuring your application architecture around it.
P.S. Don’t confuse SOA with “web services”. That’s one way of implementing a remote service, but it’s perfectly possible to do SOA without them. For example, you can implement a loosely coupled service pattern perfectly well with Java interfaces in a JVM process.
1
NO, I don’t believe you should push to change the terminology from SOA to MOA. Unless you believe you convince the entire world to update all references to SOA.
You are right, when you say that people working together must use terminology that is understood to mean the same thing for everyone. In your mind Mission Oriented Architecture sounds like a better choice, but when I read this question I thought you were talking about applications that launch rockets to the moon. Clearly if I was to work with you, you still can’t assume that I will have same interpretation of the term that you already have.
SOA isn’t a term that your team or your company came up with. If you want someone to get educated (no matter how fun it it) in what SOA is, you can start by having them read external links:
- http://en.wikipedia.org/wiki/Service-oriented_architecture
- http://msdn.microsoft.com/en-us/library/bb833022.aspx
But when someone joins your team, or an third-party company integrates with you they are going to get this:
- http://renewableplus.blogspot.com/2012/06/mission-oriented-architecture-moa.html (it’s a coincidence that there’s actually a picture of a rocket on that page. That was just one of top google hits that I found after I wrote the above stuff)
2