The short explanation of SCA is that it's a set of specifications describing a model for building service-oriented applications. OASIS oversees the specifications, and there's a lot more to it. The details, however, fall more in the domain of enterprise architects or systems engineers than executive IT or tech-minded business leaders.

But here's what IT and business leaders do need to know about SCA: Vendors love it, and they'll be pushing tools that rely on it-even though SCA can be detrimental to your SOA efforts, according to Morgenthal:

"My subjective opinion based on all the factors that I currently have at my disposal is that SCA is a step backwards in software engineering. It's an abandonment of the SOA principles that have failed because of lack of investment in proper architecture toward a pure programming model driven by software engineers. Thus, the goal here is once again to allow poorly-designed systems to be built by software engineers with very little architecture experience so they can claim to have some attributes of SOA."

He's particularly annoyed by SCA's dependence upon tools, which he sees as encouraging IT staff to become too focused on tool proficiency, instead of problem-solving:

"Businesses would do well to stop hiring resources based on individual technology skills (except if you're hiring a consultant, because that's what you're buying) and start hiring based on the individual's ability to think your business to success. Years ago, mid-80's, when I was interviewing for positions, businesses used to take pride in testing how programmers thought about problem solving. Today, they look for buzzwords."

"As we were working on the standard, we primarily talked about the development experience for a developer who is just using a text editor. We did this because we understood that you can't make fundamentally complex technology simple by creating layers of development tools. The place where that approach usually falls apart is in debugging-especially debugging after deployment. If a technology is truly simple, as SCA strives to be, then it should be possible to create it in a text editor. Tooling still can be useful, but just as a productivity accelerator."

I have no idea whether or not SCA encourages dependency on tools. To be honest, I suspect developers like tools of their own accord-regardless of whether or not any standard encourages tools. I know I do.

I think the bigger and more interesting point with the tool question is that businesses shouldn't be hiring people based on which particular software tool they can use, but rather on skills that aren't as easily taught, such as an ability to think about how to serve business needs.

What I like about Morgenthal's column-beside his use of terms such as "backwards yahoos" and "dumbass alley" -- is that he doesn't just offer criticism; he says exactly what three steps IT leaders should take to ensure their building "maintainable, sustainable and reliable" systems.

He elaborates on how each would work, but in a nutshell, he would prioritize and rationalize applications from an enterprise perspective, put a qualified chief architect in charge of all software projects, and "get vendors out of your organization."

That last point may seem extreme, and certainly Rowley disagrees that this is what SCA would do. I suggest you read both pieces, and then check out the following more neutral resources:

But I think there's a larger point here that's worth reiterating, particularly in IT divisions with a nearly-teenage infatuation with vendor brand names. Take control of your own ship. Don't let vendors lock you into solutions or standards you don't really need.

IT Solutions Builder
TOP IT RESOURCES TO MOVE YOUR BUSINESS FORWARD

Which topic are you interested in?

Mobile

Security

Networks/IoT

Cloud

Data Storage

Applications

Development

IT Management

Other

What is your company size?

What is your job title?

What is your job function?

Searching our resource database to find your matches...

Subscribe to our Newsletters

Sign up now and get the best business technology insights direct to your inbox.

Advertiser Disclosure:
Some of the products that appear on this site are from companies from which QuinStreet receives compensation. This compensation may impact how and where products appear on this site including, for example, the order in which they appear. QuinStreet does not include all companies or all types of products available in the marketplace.