Why would you make your product SOA compatible?

Question

You have a good software product, so why would you make it SOA compatible?

Answer 1

You may want to do this to provide a looser coupling between your data services and your application layer. This will give more flexibility to reuse the service components for other products and allow you to change the underlying service architecture if need be without the need for your application to even know about the change.

Having said all that, I would first want to have an actual business use case that warrants making the switch before making the change. Changing simply to keep up with the latest buzzwords is just a waste of money. If you're starting a new project, however, you may want to consider a service-based architecture if it makes sense for your application.

Answer 2

That's a very difficult question to answer without more detail about your "good software product", but speaking in sweeping generalities:

• If you implement an SOA scheme on your product, more developers will be able to consume the API services provided by your product because web services work across almost any development platform.
• If your product is already a web application that publishes certain data, you might discover that you have readers/consumers of your data that are interested in doing analysis or building additional applications that you never thought of or may not ever have the available time to build.

Answer 3

If you want your product to be integratable with other applications and your customers have actually voiced this wish / requirement then I would consider it, but otherwise it might be a big waste of time and money, especially if doing it might cause some lengthly architectural refactoring to make it work. But with no clear reason, it probably doesn't make sense to follow a trend just because others maybe doing it. Your customers will let you know when this is necessary.

Answer 4

In my opinion, only one good reason: you need interoperability between different platforms or technologies. Otherwise, save yourself a lot of grief and "just" make a well-mudlarized architecture - tell your boss it is SOA if that's what he wants to hear. Don't do it because you might move to or use other platforms in the future - you don't have an interoperability problem yet.

Answer 5

The fact is: you don't need to.

SOA structure is very complicated to achieve. It requires care and organization style that I believe most companies will not have. (I'm glad if yours has such organization).

Tomas Erls talks about Contemporary SOA and Web Service First Generation. WS-I is the traditional web service style such as asp.net web services. Actually this traditional web services doesn't mean any service oriented; And what happens is people build simple web services and call them SOA.

Contemporary SOA, I believe, is an entire system structured based on services. Inside this "ecosystem", services would call each other to perform some tasks.

SOA analysis is painful and you need care. To build an ecosystem like that, you need to be prepared from the first moment.

Engineering service interfaces (contracts) is also paradigm. If you put some Lean Thinking at your belt, you should cut some desire to make state-of-art design. If your system already works, fine! If someone will need integration in possible future which you don't know yet about it, don't do it now. But if your system is born to be consumed, them you think about it.

Best