SOA applications: Why businesses are using SOA, skills architects need

Use of SOA applications has regained popularity. Matt Brasier speculates why, and offers advice about the skills architects will need to use SOA.

Why did SOA's popularity dip, and why are businesses still using it now? What SOA skills are most in demand?

Matt Brasier

Service-oriented architecture was used too much, so a combination of overzealous sales from product companies and overuse of SOA applications within organizations contributed to the false impression that SOA could solve any problem. SOA is about enterprise services that expose features across the enterprise that are hard to deal with. It still fits there, but it has to be done at a high level, and it has to be put into the right places in architecture and integration and services.

It's quite common that organizations will invest in a technology, then try to use that technology for every problem. So, people have used and will use SOA in places where it's not necessarily the best fit. Then they'll find it doesn't fit and blame it, saying SOA isn't a good technology because it couldn't solve the problem. Likewise, people will try and use enterprise service buses in ways they weren't intended to be used.

SOA can be used to solve difficult integration problems among large systems, where you need to define interfaces, particularly in those going between different organizations or different departments within an organization, where you need to define the responsibilities and contracts between those parts of the organizations.

SOA is viable today because there still are so many different ways of doing things within it.

SOA is viable today because there still are so many different ways of doing things within it. The technologies that fall under the SOA umbrella and the enterprise-service-bus umbrella are so diverse.

As for SOA skills, in my work I see architects being a bit weak in handling problems with nonfunctional requirements, like performance, scalability, general stability and the ability of the application to stay up and deal with the user load. My advice is that they should better learn what the business requirements actually are in terms of number of users and response times.

I think that SOA skills have been put aside in the last five or 10 years because of the increased popularity of feature-driven development methodologies. The new focus has been on getting the feature into the application, testing that it works in a single-user environment, then signing it off as complete. With this focus, the collection, implementation and testing of nonfunctional requirements often get lost.

What architects are overlooking is that applications may work fine and be feature-complete with small amounts of data and a small number of users. Too often, however, they've never been tested in larger environments. So, when customers come to do that, they find that an app doesn't work because the architecture isn't right or they've made other poor decisions.

There's overuse of technologies like AJAX (Asynchronous JavaScript and XML), where you can do some nice, quickie things with some asynchronous stuff on your page. It all looks very nice if you have a few users on your site; but when you have 10,000 users, all of them sending a request every second to update a MessageBox on a screen, that load becomes a lot harder for the back-end servers to handle.

In this situation, I think it's important to build up SOA skills for handling nonfunctional requirements and collecting requirements correctly. Get away from a features focus. Learn how to focus on business problems that need solving. That's the approach that works and makes an architect valuable.

Editor's note: This answer is excerpted from an interview with Matt Brasier, a professional services consultant, conducted by Executive Editor Jan Stafford.

Follow us on Twitter at @SearchSOAand like us on Facebook.

Dig Deeper on Distributed application architecture