•  03-07-2019
  •  | 
  •  

Question

I've been resisting making any personal career investment in learning anything about this acronym because my particular field of work doesn't require it. I am curious if it would be worth my time or if it is another computing fad that will eventually die down.

Was it helpful?

Solution

It is a fad in the sense that for a while there will be those that will say "everything needs to be SOA from now on". Then after a while the good things from SOA will remain, whereas the more controversial or less useful will die down.

OTHER TIPS

It's both.

Service Oriented Architecture, from a real engineering point of view, has pluses and minuses. It's loosely coupled, which is good, because having "small pieces, loosely joined" is the solid design strategy that worked for Unix, and has many proponents among software engineers.

However, like any other software, it requires very careful design: you can have a bad SOA just like you can have a bad anything else, and since the field is newer, the best practices aren't as well fleshed out yet. It also typically exhibits much worse performance than other architectural approaches. At this point, most big players (like Google) seem to think it's best suited for interop between different systems (their APIs are practically the definition of SOA), but not for the internal architecture of a single system (they use their own Protocol Buffers for that).

SOA is a fad when it comes to managers who don't really know anything about engineering. They like it because a) it sounds new and hot, and b) it has the word "service" in it, which makes them feel useful. Ask half of them what the difference between a "service desk" and a "service oriented architecture" is, and they'd be hard pressed to tell you.

It's a terrific way for tool vendors to get you to buy a lot of stuff (e.g., ESB), consultants to invoice a lot of billable hours, and Gartner to pump out more Magic Quadrants.

I think it's not really a "fad"; it's more evolution of an idea that's been around since the arrival of networks: distributed components. CORBA and DCOM were both distributed component architectures that were proprietary. SOA uses HTTP as its common wire protocol that can go through port 80 in firewalls. All the other standards like XML, WSDL, etc. are attempts to make these discoverable and automatically understood by clients. It's important to understand the ideas behind it all and not be too caught up in the hype.

It seems to be working for Amazon, Yahoo!, etc. There might be something in it for mere mortals like us, too.

I see some worries:

Latency comes with distributed components. If everything's a service, communicating through an enterprise service bus for better decoupling, how can it be fast? We might be in danger of creating a beautiful, decoupling, pig of an enterprise.

Design is hard. No one can agree on what constitutes a service. How many should your enterprise have? Tens? Hundreds? Thousands? How fine grained must they be?

If your employer has traditionally funded work by a project model, how can long-lived services fit into that mold?

The most important thing to realize about SOA is that it's not really a technology, it's a way to organize IT infrastructure as a bunch of reusable services that can be combined, rather than the current norm of a bunch of applications that require extra effort to integrate when necessary.

Of course, making this work requires technology, but "learning" or buying that technology is meaningless if you don't (re-) organize your IT that way.

I think the basic idea of SOA is sound and here to stay (though it may not be useful in every context). SOA-as-a-technology, on the other hand, is a buzzword fad that will die.

Personally I'd say it is a fad. The cloud is big at the moment, just like Mainframes, but then desktops came along and took over. Now we are going back to big iron...

I work for a medical device and software manufacturing company, and SOA is not a fad here, it is a necessity. Progress in this front is slow because of legacy systems, and cost of creating such a fairly open system.

Another angle to this discussion is whether your company plans to create a suite of products or just a single product.

There is no such thing as a fad in terms of concepts or ideas, if someone thought about it and that something proved as a good solution, than it is not a fad. Although if you buy a Ferrari and run it on a dirt track with the hand-break on,of course it is a fad. Loose coupling is vital today, any experienced consultant or programmer that had worked directly with a customer will tell you that things are always changing, nothing stands forever as it was discussed during the first analysis, in my experience SOA principles had proven their worth. 100% of my customers that used to work with other programmers told me that at one point the other guy decided to start over at a certain point or stated that a certain request is impossible to implement. SOA is the best solution for difficult customers, and most customers are difficult, what you have to do though is maintain the sense of measure. ESB is a good thing if you have 100 branches in 30 countries and plan on growing fast. The so called software consultants of nowadays and software salesmen in my opinion are guys that never had written a line of code in their lives, they've never seen themselves the process of analysis,development,delivery,change request management and all the loops and stumps on the way that's why in the eyes of the real software people they seem to be talking bogus. Of course they talk bogus, but that is because they do not know what their are talking about, not because the thing they are talking about is bogus. As time passes and web based apps and cloud computing are taking over more and more SOA will be stronger and stronger, as there is no alternative to systesm-to-system communication, considering the multitude of platforms,operating systems,programming languages and of course programmers. Don't let your self misguided by the fuss made by the ignorance of others that like it just because they like the word.

As for the slowness problem, I'll give you a tip: Try communication via JSON, you won't believe your eyes ;).

Assuming you mean 'Service Oriented Architecture', there are applications for which it is useful, but it's going to come and go like every other fad. As with any market of this type there is a window where there is a skill shortage. If you get in at the right time you can do quite nicely out of it. By the time it's being hyped in the mainstream media, you're probably too late as every other Tom, Dick and Harry will be descending on whatever market opportunities are out there.

If you work in a field where SOA is relevant, by all means get your head around it.

In many ways, it's just the same concepts as distributed applications, which have been in and out of fashion with quite a few generations of technologies (SNA, Sun RPC, DCE, CORBA, EJB, DCOM and now Web Services).

In other ways, one can see orchestration systems as a means of integrating components into a whole application. If you have a series of components that do expose usefully designed services you can build a nice, flexible application architecture.

Once the dust settles the obvious killer apps of SOA will be exactly that - obvious. I'd say the window where one can charge disproportionate consulting fees for knowing how to spell SOA is probably closing now. Learn it if you want to use it for something or see a useful synergy with other skills or experience where it might combine to make something saleable. Otherwise get an overview of it and dig deeper when you need to.

If a "fad" is "a fashion that is taken up with great enthusiasm for a brief period of time; a craze." then SOA is not a fad. SOA has been around for a while now - ever since SOAP-based RPCs (i.e. XML Web Services). It's been quite a few years since then, and instead of dying off, SOA has only flourished in its WCF incarnation. So I'd say SOA is far from a fad.

I don't think it is really a fad. It is just that creating open systems that can interact with others systems is more difficult than creating closed systems. I think that that will always be true.

There is also always a performance penalty if you transfer data with standardized 'protocols' like XML Soap.

SOA is not a bad technology actually I think it is usually implemented wrong and misinterpreted. There are scenarios that really SOA fits best.

But there are some places to avoid SOA. FYI one of the drawback of SOA is, it is usally slow.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top