This post originated from an RSS feed registered with Java Buzz
by Bill de hÓra.
Original Post: The Service Garden
Feed Title: Bill de hÓra
Feed URL: http://www.dehora.net/journal/atom.xml
Feed Description: FD85 1117 1888 1681 7689 B5DF E696 885C 20D8 21F8
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 if this is the way things are going. (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. It has to mean reconfiguration or data driven change. But that suggests a consequent investment in engineering things to be changeable that way in the first place. 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, something we are singularly useless at in this industry? 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. There is a need to work and diagnose directly on live systems, as reckless as that sounds. This is where the bulk of systems costs reside. 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. We need more organic metaphors that capture and reflect what's happening in business and in government. An out of control service envrionment 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. 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. Thankfully this issue is gradually coming onto the radar, but I speculate we'll see specification churn over the next two years as the feedback rolls in. 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. To take an example, what does it mean to keep enterprise software and systems fabric adaptive over five years or a decade? How about fifty year uptime? This goes beyond software process and suggests a commercial model that is not found in either T&M or Fixed Price contracts. Note that this is not the same kind of work you see admins doing to keep systems up - we're talking about going in and changing functionality as is needed with minimal ceremony - doing it as soon as the business dreams it up, not a year later. Living software. It seems that for now, rip and replace is moving out of software systems and into business and software process models....
Previous Topic
