« Ugly | Main | Use Cases and Service Cases »

The Service Garden

The more technology we have installed, the harder it is to change your business. [...] Now, customers are looking for simplicity, integration and security across releases. They want standards-based software that doesn't require the labor expenditure of the past. Software CEOs have two choices: They can try to impose their proprietary methods on the market or they can adopt a new service-based approach to providing and maintaining software. - Ray Lane

I just came across this piece from Ray Lane. In it he talks about renovation and innovation in software, how renovation is becoming very important to businesses. In Propylon we're extremely focused on avoiding rip and replace, but industry wide there are issues that need more consideration. It seems that for now, rip and replace is moving out of software systems and into business and software process models.

  1. (Re)Engineering. It's hard to see how to make enterprise systems adaptive and flexible without a corresponding effort in engineering behind and between the service boundaries. By engineering I mean whatever is needed to keep software soft, something that isn't going to be derived from the architecture alone. Responsiveness to business change can't in the long run mean cranking out ever more code or throwing away what's already there - that's a losing approach. But that suggests a consequent investment in engineering things to be changeable that way in the first place.
  2. Maintenance. To some extent, renovation is maintenance in drag. But suppose you have an exposed service running 24x7. Chances are if it's been up for any length of time it's become more or less critical to its callers. This has all kinds of process and management implications - like on the fly upgrades of running systems. Or how about versioning? Scaling up? What about scaling down? Hardware and infrastructure provisioning? I don't see the classic dev to staging to live cycle being sufficient - your live callers won't be on the staging platform. The sane approach seems to consist of gradually ramped rollouts and beta programs.
  3. Metaphors. If the industry is going down this road, the old building construction and factory metaphors as we have taken them might become redundant - worse they might become problematic. An out of control service environment is more like bindweed than a tenement block; and having a service track the business is more like pruning a rose bush than laying down a patio.
  4. Standards and specifications. Attempting to do any of this on internet scales has resulted in a generation of web services specifications written before the issues were fully understood or even acknowledged - ultimately those specs were derived from what was known about distributed middleware not a web of services. Service oriented, as people are learning, is not middleware writ large.
  5. Business models. There's no end of discussion around software licensing with respect to customers and especially with respect to open source. There's somewhat less around services and system delivery. Renovation and system reuse (exposure by service) imply different commercial arrangements to the models we're used to. This goes beyond software process and suggests a commercial model that is not found in either T&M or Fixed Price contracts.

May 25, 2004 11:28 AM

Comments

Chris Dent
(May 26, 2004 09:30 AM #)

Big time agree with your point 4.

I was at www2004 in New York last week. I was rather stunned by the complexity of in-progress web services standards. You're correct: they are well in advance of true understanding and are modelled on existing middleware and even old-school enterprise architectures.

The happiness of a services world, to me, is that it breaks free from those models and allows a greater level of flexibility. Things like Choreography and Conversation smell like they are putting the pain back in.

I admin that that bad smell comes from intuition, not complete investigation, but...stinky is stinky!

Trackback Pings

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