services
| toolbox | services | architecture | finance | payments | identity | xml | klogs | perl | books |

daily link  Sunday, April 21, 2002

Matt Sergeant: "So it seems google's new API has everyone going all gaga over it. Well I for one am sick of hearing about it."

Paul Prescod: Questioning the Google API"Although there is widespread rejoicing at the existence of such a tool, some "Google watchers" are disturbed that this new API is in some ways less functional then the HTTP API that Google made private several months ago." [Simon Fell]
permalink Posted to services @ 9:53:32 PM ( comments)

James Snell and Sam Ruby are in disagreement about versioning of web services interfaces.

James Snell: What would a two-way Google API look like? Have a nice vacation, James.
permalink Posted to services @ 9:45:53 PM ( comments)

Dave Winer: What's next after the Google API? and The Mind of Google: "Web services can make you think, make you want more."

I agree. I would like to be able to use simple interface for online payment system: transfer(from, to, date, amount, memo). More than two years ago I got involved with web services, because I though it'll help me to implement online payment system. Now it's time to pay back.
permalink Posted to services @ 9:24:15 PM ( comments)

Real Time Enterprises: A Continuous Migration Approach (PDF). Must read. "The goal of this paper is to define the "ground rules" of an IT transformation from the stark reality of legacy applications forward to the promise of the future. In fact, the goal should not be a radical transformation but rather continuous migration of systems, transforming the organization into an adaptive enterprise. It is easy to define the ideal "new" world, particularly with the promise of Web services, but harder to achieve a practical reorientation towards such a goal."

"The inflexible structure of conventional systems has long been the subject of loud complaints by top management. Today’s customer expectations, evolving business models and technology trends demand the need for adaptability. It is important to accept CHANGE AS A PROCESS, rather than as an EVENT."

Now it's getting interesting. Just recently I was thinking about similarities between adaptation of teams and organizations and adaptation of complex systems.

From James Highsmith's Adaptive Software Development (p.20): "Adaptation is a pattern of continuous change that exists in contrast to the periodic dicrete change process found in many organizations. The difference between beginner and expert skiers provides a vivid analogy. The beginner traverses the slope until he or she encounters the trees at the edge. For skiers, trees provide a significant incentive to change (turn). However, the expert skier is always changing, always turning, always on edge, always accepting to the challenge down the hill. The beginner skier is more like traditional organization, utilizing existing practices until the threat (or actuality) of encountering trees is so great that he or she (or it) has to change. Adaptive organizations, like advanced skiers, treat continuous change as the norm -- and their practices reflect that actuality."

How do we design adaptive systems? What are main differences between dynamic, volatile and adaptive system and monolitic, solid and stable one? How can we shift focus from creating a system that will last forever, toward creating a system that will be easy to change tomorrow or tonight?
permalink Posted to architecture, services @ 12:08:34 PM ( comments)

Stemming The Software Spending Spree"Corporate politics and poor leadership had much to do with the sorry state of application architecture--or the lack thereof. Divisions and departments were allowed to pursue independent technology strategies and went in a thousand directions. Sacrificing economies of scale, companies permitted completely decentralized purchases of complex products that resulted in an exponential increase in complexity and inertia." and "Things likely will get even worse before they get better. The need for data to transverse multiple applications is increasing as customers focus less on discrete software modules and more on the entire process, thanks to collaborative efforts. As businesses move toward real-time computing and away from batch jobs, and as business processes cross application boundaries, the stress on frail integration links will only grow more acute." [Web Services Strategies]

Web Services Infrastructure (PDF). "Practical applications of web services technologies fall into three groups: Plug-in functionality, Remote infrastructure services, and Enterprise application integration." [Loosely Coupled]
permalink Posted to architecture, services @ 11:11:24 AM ( comments)


Copyright (C) 2002 Paul Kulchenko Click here to send an email to the editor of this weblog. Updated 8/11/2002; 7:06:19 PM