SOA Standards, Tools, and Teen-age Crushes on Vendors

Loraine Lawson

One of the things I try to do as a business technology blogger is to watch out for marketing trends so I can give you a heads up, preferably before the vendors' sales teams come calling.

 

So when I read analyst JP Morgenthal's recent tirade about SCA-service component architecture-I knew I had a winner.

 

SCA is not particularly new, mind you. It's been around since at least 2005, when IBM, Oracle, BEA, Progress Software, Red Hat., SAP, Siemens, Software AG, Sun and a number of other vendors collaborated on the specifications.

 

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."

Michael Rowley of Active Endpoints-the co-author of the book Morgenthal mentions in his post-took exception to this and several other of Morgenthal's arguments against SCA. In a response post, he writes Morgenthal "misunderstood some of the key characteristics of the new standard," and that SCA does not encourage dependency upon tools:

"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:

 

 

Then you can decide for yourself.


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.



Add Comment      Leave a comment on this blog post
Jul 27, 2009 1:52 AM JP Morgenthal JP Morgenthal  says:

Thank you for the fair and objective treatment of my blog entry.  Readers should know I strive to A) provide accurate portrayal of my level of knowledge in the area and B) continue to watch and report where I have cause to change my opinion.  To that end, I tried the link above for the piece entitled "'What every architect should now know about the Service Component Architecture (SCA)"  and I get a page that says "Spam not appreciated"

Reply
Jul 28, 2009 2:35 AM Patrick Avery Patrick Avery  says: in response to JP Morgenthal

http://www.theenterprisearchitect.eu/archive/2009/03/11/what-every-architect-should-now-know-about-the-service-component-architecture-sca

Copy and paste that link into your browser and it should work. If you just click on it, it will give you that spam message.

Thanks for the heads up.

Reply

Post a comment

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Subscribe to our Newsletters

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


 
Resource centers

Business Intelligence

Business performance information for strategic and operational decision-making

SOA

SOA uses interoperable services grouped around business processes to ease data integration

Data Warehousing

Data warehousing helps companies make sense of their operational data