Note: You are experiencing only the raw content of this site, without the intended layout and design. Either your browser has ignored the Cascading Style Sheet (CSS) files for this site, or you are using an outdated browser which does not support Web Standards. Learn more.

EDS' Next Big Thing Blog: Read and Respond to What the EDS Fellows Say About Technology

Read and respond to what the EDS Fellows have to say about the future of technology on EDS' Next Big Thing Blog on eds.com.

Concrete Code

by Charlie Bess

In a recent issue of eweek, there was an article by Darryl Taft called Concrete Code that discussed the architects role shifting from hand crafted code to the assembly of code from existing services.

It was a decent article from a tactical perspective and did touch on some of the strategic issues, but my view is the shift is more fundamental than what was described. It compared the future architect to behaving more like a bricklayer or plumber, assembling solutions (business value) from existing components.

My difference of opinion comes from what tools the architects will be using. The author describes the architect using AJAX, Microsoft ATLAS and SOA. Those seem to me to be more like the mortar for the assembly.

The tools that will be used will be at the higher level of workflow, model driven architecture and simulation spaces. Tools like WWF and standards around workflow and business modeling are maturing. I've written before about some of the reasons why there is more to this shift than what the industry press is talking about. I guess, there will need to be some catastrophic failures (because of shallow models and business & technical understanding) before these topics are fully discussed.

Published Monday, February 20, 2006 6:50 PM

Subscribe to this post's comments using RSS

Comments

Posted by Dennis Howlett Tuesday, February 21, 2006 5:25 AM

I sincerely hope we're not talking 'concrete.' That's how we've gotten to the point of inflexibility that all these shiny new TLAs are meant to resolve isn't it?

Important to remember the press is interested in news not analysis. Big distinction.

Posted by Charles Bess Tuesday, February 21, 2006 3:18 PM

You're getting at my issue with the article as well. I think there is a whole other dimension of flexibility that we are going to have to deal with in the future than was covered by this article.

Posted by James Taylor Tuesday, February 21, 2006 7:22 PM

I think that the other technology that will make this possible is business rules management technology. This allows the development of components that can be evolved by the business and so bring agility to the environment where reconfiguration of the overall environment is not the issue but changing how something specific is done is.

Posted by Dennis Howlett Wednesday, February 22, 2006 2:58 PM

To James point - I've seen something along those lines though I doubt the developers would want to see it pidgeon-holed that way.

Hyper fast track development of relatively small processes but which are easily configured or evolved to suit customer requirements. Not sure how complex these apps could get but then I think there's a case for saying there are certain processes that should be concreted over - eg - do I really need to reinvent GL/AP/AR? Is it core?

Posted by Michael Stein Thursday, February 23, 2006 8:44 PM

I never understand articles like this. We've been seeing them for years - the idea that software development will be radically "deskilled" in the near future.

Ten years ago people were saying we will not really need developers in the future because programs will be assembled out of prewritten components. What did they mean? Where did they think the components would come from? Or did they think the market would just accept one treeview or one editor control and that would be that?

Now that components are old hat, they say the enterprise will not need developers, 'cause someone will just string together services. Well, someone writes the services, no? And there will be ten competitors for each one. And more to the point, someone needs to understand the service APIs well enough to "string them together"

I'll grant that typical app makes use of more and more third party code written by more and more separate development groups. But that's about all the change I've seen.

Posted by Charlie Bess Friday, February 24, 2006 2:29 AM

Michael, I don't think we will get rid of programmers for quite a while, but I do think programming will stratify. There will be head down coders (but more of those will be in low cost locations). Just that very fact will require better requirements than what most organizations are used to documenting. There will also be assemblers. Those people will still be programmers and understand architecture... but in a different way than what 3GL programmers do today. The same could be said about the need to think of work flowing in parallel streams. Those that can make the shift first will have an advantage.
I know what you mean about it looking likely over a decade ago, but progress does march on and the possibilities get more likely and the processing power is there to make it happen.