This post originated from an RSS feed registered with .NET Buzz
by Udi Dahan.
Original Post: SOA, mediation, and the holy code
Feed Title: Udi Dahan - The Software Simplist
Feed URL: http://feeds.feedburner.com/UdiDahan-TheSoftwareSimplist
Feed Description: I am a software simplist. I make this beast of architecting, analysing, designing, developing, testing, managing, deploying software systems simple.
This blog is about how I do it.
Ronan Bradley of www.WebServices.org predicts the failure of SOA solutions based on "coded frameworks". To say I disagree would be an understatement. There is one section in particular that disturbs me: "My aversion to code is not based an abstract principle. Rather, each line of code the organization develops is custom for that organization and (unfortunately) sometimes for that project. As a consequence it must be maintained and evolved over time. Furthermore, the knowledge about what that code does must be maintained in the organization and evolved over time. This is a potentially huge cost and distraction for IT organizations, which need to focus on solving business problems rather than maintaining integration code." 1. Custom code is not necessarily integration code. 2. Some business problems are about getting access to legacy data stuck in some proprietary format. 3. IT maintains and develops code. That's why it exists. I worry that people will start thinking of SOA as "buy product from vendor, drag and drop, done". Developers will always be writing code. Let's go back to the pipe-dreams of business-rule systems. You know, those hyper-flexible monstrosities that end-users (of all people) would define the rules. Why don't we, as an industry, JUST GET OVER IT. There will always be code, as in custom code. Code without a solid design is a maintainence nightmare. Design without architecture is the right solution to the wrong problem. Architecture without requirements is answering the right question asked by the wrong person. Nothing has changed. Developing software will continue to be hard. And no matter how many three letter acronyms you throw at it, software development will continue to be hard. If you don't look at the whole lifecycle, you're bound to optimize the small, and ruin the large. Are we done with the hype yet? Can we all just get back to work?...
Previous Topic
