« Migrating to Subversion IV | Main | 503 Service Unavailable »

Right Services, Wrong Tools

An entry on the nature of appropriate tools in document and service oriented systems, the importance of understanding the nature of the IT market and the need for good engineering irrespective of architecture. Finally some speculation on where an SOA backlash might come from.

Wrong tools, wrong place.

And, unfortunately, the tendency for developers to immediately see in their minds "distributed objects with angle brackets" instead of "services", and lo and behold, Web services are destined to suck. Vendors, please: don't make it easy for developers to make the same mistakes. I know it makes for a great sales story on the show floor, but have some dignity and try to Do the Right Thing instead--make the fact that this is a service more explicit, don't let developers build distributed object systems (this time using WSDL instead of IDL) again. - Ted Neward

Ted's right insofar as the tools tend to work from the objects out and that's known to be a losing approach; you should work from the documents in (but I can't believe this is news at this stage). Another, bigger consideration, is that the document oriented approach reduces the overall need for development tools. Potentially this afflicts anyone running with "a tools will save us" business model for distributed systems. Which is quite a few people.

Right tools, right place.

The upside is that we still need good tools, they're just not critical for development. Where Service Oriented (or Document Oriented or Webservices or REST style) systems do need better tools is post-deployment. There is a entire layer of application/document level monitoring and alerting needed to realize ROI on Services and make them viable. Think of it as SNMP or Syslog for Level 7 and above. This is what you see when you get past evangelism and early adoption and into the business of rolling out and running services. Since many people are still at the point of talking about and planning doing SOA we can expect this to take a while to sink in across the industry. In any case, saving 30c on the dollar during development but losing 10c on the dollar post-deployment because there is no visibility is something of a false economy.

Even so, this ignores the "rich" (complicated), but fundamentally important relationships that exist between tech analysts, tech press, vendors, system integrators and the enterprises buying the solutions. That whole ecosystem is strongly based on development tools provision (and let's face it, good demoware), irrespective of what the current needs of buyers are. I think you can look at this in two ways. First, as this huge, huge, market opportunity to deliver winning solutions and products. Second as being inevitable that systems are built out based on whatever the tools at hand allow; even if that is a precisely backwards and actively harmful methodology.

SOA != Architecture + Tools

One nightmare scenario for SOA deployments is a complete rupture between architecture and engineering, or where engineering becomes "deprecated". Here we would see more and more consultants saying just what Ted is saying (good advice), but where the tools and the development practices are stuck in a non-complimentary paradigm. Or worse, that SOA hype persuades enough people that the need for robust construction of software is somehow eliminated. Personally, while I'm seeing plenty of decent architectural thinking of late, the engineering thinking is practically non-existent, and this is reflected more or less in the use of inappropriate tools and methodologies.

After you ship, what then?

Aside from my concerns about an engineering void, if there is a backlash against SOA, it may come to pass when the cost of running, changing and managing these things is found to be exhorbitant. And I mean a real backlash, where people kill projects and stop going to the market, not the current buzz of "'SOA' is so overused, let's, like, drop the 'A'". Never mind that even the bigger enterprise IT divisions are not neccessarily equipped to be running globally visible utilties and services and that "maintenance" (as we like to call it), has always been the bulk of IT cost. Services by being much more visible and relevant to the business (that's the point, remember?) will make such costs apparent. Your CEO could be even left thinking these things are more expensive that past approaches, where the cash bleed was somewhat less obvious.


June 3, 2004 09:36 AM

Comments

Trackback Pings

TrackBack URL for this entry:
http://www.dehora.net/mt/mt-tb.cgi/1308