| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
architecture
|
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Sunday, April 21, 2002Real 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?
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] Posted to architecture, services @ 11:11:24 AM ( comments)
Updated 8/22/2002; 5:26:05 PM
