2008-10-14: IEEE SysJrnl GEOSS Issue

From Datafedwiki

Jump to: navigation, search

Back to Data Developments

Contents

[edit] Fritz: A Conceptual Framework for Assessing the Benefits of GEOSS

[edit] Abstract

Compare this to Ecosystem Services, Atmospheric Services Climate Services


The aim of the Global Earth Observation System-of- Systems (GEOSS) is to improve the information available to decision makers, at all levels, relating to human health and safety, protection of the global environment, the reduction of losses from natural disasters, and achieving sustainable development. Specifically, GEOSS proposes that better international cooperation in the collection, interpretation, and sharing of Earth observation information is an important and cost-effective mechanism for achieving this aim. While there is a widespread intuition that this proposition is correct, at some point the following question needs to be answered: how much additional investment in Earth observation (and specifically, in its international integration) is enough? This leads directly to some challenging subsidiary questions, such as how can the benefits of Earth observation be assessed? What are the incremental costs of GEOSS? Are there societal benefit areas where the return on investment is higher than in others? The Geo- Bene Project has developed a “benefit chain” concept as a framework for addressing these questions. The basic idea is that an incremental improvement in the observing system (including its data collection, interpretation and information-sharing aspects) will result in an improvement in the quality of decisions based on that information. In turn, this will lead to better societal outcomes, which have a value. This incremental value must be judged against the incremental cost of the improved observation system. Since in many cases there will be large uncertainties in the estimation of both the costs and the benefits, and it may not be possible to express them in comparable monetary terms, we show how order-of-magnitude approaches and a qualitative understanding of the shape of the cost and benefit curves can help guide rational investment decisions in Earth Observation Systems.

[edit] Intro

GEOSS and an assessment of it seem to be more important than ever since two major drivers of Earth Observation Systems have dramatically changed over the past few decades. The first is the understanding that there are powerful biospheric and socio-economic processes that operate at scales greater than the nation. An example of the former is the phenomenon of global climate change and of the latter is the globalization of trade. These can have important (even dominant) consequences for the wellbeing of the inhabitants of a particular country, but cannot be observed, understood or predicted by systems that confine themselves to national boundaries. As a result, the major powers have developed Regional or Global Observation Systems, largely for their own purposes. Smaller, poorer, and less technologically-advanced societies have been unable to do so, and depend on what they can glean from local observations and what is made available from global systems. Clearly, there are cost efficiencies to be gained by integrating the efforts of all nations at this scale, and benefits to be had from distributing the information more broadly. The strong development of international collaboration in weather observations, through the World Meteorological Organization, is a case in point. The second driver of change in Earth Observation Systems is technology. There are now ways of observing the Earth that were previously impractical (such as measurement of the sea-surface temperature in remote parts of the ocean), and for sharing, through information and communications technology, unprecedented volumes of information, very rapidly and broadly. These two drivers have created the conditions for the emergence of GEOSS, based (both out of necessity and good sense) on the preexistence of an elaborate set of partial or smaller scale subsystems.

As previously indicated, many studies illustrate the potential benefit which could be gained from an improved weather forecast system: with respect to mitigating natural hazards [49], increasing crop yield [1], food trade [9], or road safety [2]. These studies attempt to measure the value of improved weather informationinabsoluteterms. Theyshowthatsimulationmodelingcan provide insight into the relationship between improved weather information and the resultant economic gain. Other research has attempted to use contingent valuation (willingness-to-pay) as an alternative to the usual cost avoidance approach, incorporating the commercial sector (for example, television and film companies, recreation and sports, agriculture, hotel and catering, and institutions such as sports and hospitals).

the GMES study explicitly investigates the impact of an existing and functional GMES system versus the nonexistence of such a system (termed the “without GMES scenario”), and notes that GMES is the European contribution to GEOSS. The GMES study is the only current extensive study which tries to assess the benefit of the European part of GEOSS. The Pricewaterhouse Coopers study undertook a strategic as well as a quantitative analysis. The strategic analysis looked at strategic benefits in order to determine what GMESas a strategic and political investment is trying to achieve. In a second, so-called “bottom up” study, which encompassed a quantitative as well as a qualitative assessment, the macro-economic benefits and economic efficiency savings were assessed, largely through consultation of key stakeholders.

Value of Information (VOI) theory has been developed by economists working in fields as diverse as stock market trading and manufacturing. Aworking paper by Macauley [35] attempts to apply the VOI theory and methods to show how space-based EO can improve natural resource management. This study found that the value of space-derived data depends largely on four factors: 1) how uncertain decision makers are; 2) what is at stake as an outcome of their decisions; 3) how much will it cost to use the information to make decisions; and 4) what is the price of the next best substitute for the information. Reference [35] describes three groups of methods in which VOI can be measured. In the first group, the value of information is measured by gains in output or productivity. In the second group the value of information is inferred under the hypothesis that it is capitalized into the prices of goods and services (hedonic pricing). The third group tries to estimate the value of improved information based on the contingent valuation. In contingent valuation approaches, stakeholders are asked how much they would be willing to pay for certain categories of information.

[edit] Benefits Chain


Fig. 1. Benefit chain concept. In the benefit chain concept benefits as well as costs must be considered. The concept looks at incremental changes of costs and benefits with respect to the already existing observing system (e.g., national). A logical causal benefit pathway (in steps if necessary) is established and much of the analysis is semi-quantitative (’is the benefit an order of magnitude greater than the cost’) or qualitative (what is the shape of the cost-benefit curve).

The logic behind the benefit chain concept is that through global cooperation in EO systems, improved information (in terms of quality, quantity or topical coverage) will become available to the decision maker. Better-informed decisions will lead to a societal benefit relative to the probable outcome without improved information.

We postulate that it is not possible to go from an incremental increase in effort in the observation system to an incremental gain in human wellbeing in a single step, given the multiple factors that influence human wellbeing. It is necessary to build a plausible causal chain that establishes a prima facie case that all or part of the benefit is traceable to the EO system change. At a minimum this logical chain has two steps: demonstrating that the improved observations have some impact on decisionmaking; and then that the resultant decisions led to an improvement in wellbeing (see Fig. 1).

The benefit chain concept can be examined per societal benefit area or sub-benefit area. It can be also applied to particular GEOSS activities, such as the coordination of space observations, or standardization of communication protocols. However, the more indirect the benefits, the more difficult the value of information will be to assess. The particular role of GEOSS is the “globalization” of the observing system. The particular question which must be asked in this context is whether global collaboration can either reduce the costs, or increase the benefit, of EO systems. If this can be demonstrated, and the incremental ben-efits are judged to exceed the incremental costs, then the effort involved in establishing collaboration in global EO systems can be justified, even if the total EO system costs exceed the total benefits, or if the total costs and benefits are unknown. Basically, all that needs to be known is whether the incremental effort is moving things in the right direction, or not.

Given that the world already has a large investment in EO, and that GEOSS is explicitly built upon this framework, it is also inescapable that we should be looking at the incremental cost of enhancing the system, rather than the total cost.

[edit] D. Potential to be Realized Through GEOSS

These improvements brought about by GEOSS can occur in a number of different ways: though technical improvements in the field of observations, both in-situ and satellite-based; through greater reliabilityandinformation contentgained in the synthesis, modeling, and interpretation of data; and through facilitating the delivery of information to the end user, in a form that suits their needs. In the field of satellite observations, international coordination of space platforms and the instruments they carry, along with the data systems that distribute the information, would improve the reliability and frequency of observations, the number of spectral bands that can be realized, and the spatial resolution that can be achieved. A denser and better-located network of interconnected and intercalibrated in-situ sensors would increase the timeliness, coverage and reliability of information on the many topics that cannot adequately be observed froms pacealone

The particular emphasis of GEOSS is to foster international collaboration and international standards defined by the Open Geospatial Consortium (OGC). As outlined in the 10-year implementation plan, the success of GEOSS will depend on data and information providers accepting and implementing a set of interoperability arrangements. These standards allow the information flow of geographic feature (e.g., Web Feature Service) or raster data (e.g., Web Map Service) over the Internet. On the one hand these standards allows simple searching facilities of the standardized metadata catalogues, making data flow more efficient and therefore reducing costs. On the other hand, a chain of OGCWeb services can be invoiced using standard web chaining mechanisms to produce value-added products. These value added information products are produced by automated procedures involving different data and process servers on the internet [41].

[edit] Durbha: An Information Semantics Approach for Knowledge Management and Interoperability for GEOSS

[edit] Abstract

GEOSS is built on current international cooperation efforts among existing distributed earth observing and processing systems. The goal is to formulate an end-to-end process that enables the collection and distribution of accurate, reliable earth observation (EO) data, information, products, and services to both suppliers and consumers worldwide. EOs are obtained from a multitude of sources and require tremendous efforts and coordination among different governments and user groups to come to a shared understanding on a set of concepts involved in a domain. Semantic metadata play a crucial role in resolving the differences in meaning, interpretation, and usage of the same or related data. Also, the knowledge about the geopolitical background of the originating datasets could be encoded in the metadata that would address the diversity on a global scale. In distributed environments like GEOSS, modularization is inevitable. In this paper, we describe the need for an information semantics-based approach for knowledge management and interoperability between heterogeneous GEOSS systems. Further, considering the magnitude of concepts involved in GEOSS, we explore the possibility of using modular ontologies for formulating smaller interconnected ontologies.

[edit] Intro

EO data integration is broadly dependent on the resolution of conflicts arising from the following [1], [2]:

  • data sets stemming from the same data-source with unequal updating periods;
  • data sets represented in the same data-model, but acquired by different operators;
  • data sets which are stored in similar, but not identical, datamodels;
  • data sets from heterogeneous sources (across geographical boundaries), which differ in data-modeling, scale, thematic content, contexts, and meaning.
  • Data sets that are influenced by socio-political and cultural backgrounds.

The resolution of such conflicts depends on the reconciliation of both syntactic and semantic heterogeneities in the data. Although the metadata standards (e.g., FGDC and ISO) alleviate to a large extent the syntactic heterogeneity of the data, a problem that is still not completely solved is heterogeneity in the process of converting this data into information and actionable intelligence [3]. Semantic metadata plays a crucial role in resolving the differences in meaning, interpretation, and dusage of the same or related data.

The heterogeneities are mainly due to the syntactic issues (e.g., logical data models, i.e., relational versus object-oriented or geometric representations, i.e., vector/raster), schematic heterogeneity (e.g., database models, different generalization hierarchies, spatial reference systems, or cartographic standards including variable minimum mapping units and mixed units), and semantic aspects [8]. It has been noted that semantic heterogeneity is the source of most information integration problems. This occurs because of the differences in meaning, interpretation, or usage of the same or related data.

[edit] Martin: Using Architecture Modeling to Assess the Societal Benefits of GEOSS

[edit] Abstract

An enterprise architecture for the Earth Science activities of the National Aeronautics and Space Administration (NASA) was developed to assist in assessing the capacity of scientific instruments in meeting the needs of society. It can also help them develop the right investment strategies and help scientists and engineers in their planning for system development, especially for complex space-based environmental sensors. This architecture model can be easily extended to the Global Earth Observation System-of-Systems (GEOSS). In fact, it was constructed with GEOSS in mind to ensure that NASA’s observation systems can be readily mapped into the GEOSS structure. The architecture contains about 3000 elements that are involved in earth science research: observation sources, sensors, environmental parameters, data products, mission products, observations, science models, predictions, and decision-support tools. The science models use observations from the space-based instruments to generate predictions about various aspects of the environment. These predictions are used by decision-makers around the world to help minimize property damage and loss of human life due to adverse conditions such as severe weather storms. The architecture is developed using both traditional and nontraditional systems engineering (SE) tools and techniques. This paper will describe additional methods needed for the SE toolbox.

[edit] Intro

THE GLOBAL Earth Observation System of Systems (GEOSS) qualifies on all seven attributes for a system-of-systems (SoS):

  1. operational independence of the component systems;
  2. managerial independence of the component systems;
  3. geographical distribution;
  4. emergent behavior;
  5. evolutionary development;
  6. self-organization;
  7. adaptation.

These attributes were synthesized by Sage and Biemer [1] from other research and studies [2]–[12]. Most SoS that have been described in the literature have four or five of these attributes. Therefore, it is worthwhile to study those SoS instances that have all the attributes present. Modeling of SoS has been addressed by some [12], [13]. Metamodeling of SoS has been addressed rarely [13], [20]. Recently, there has been a growing interest in SoS concepts and strategies. However, it still remains a difficult venture for most. To address this weakness in the systems community some have proposed the formation of an international consortium on SoS engineering [14]. This paper describes the efforts at NASA to architecturally model and characterize their systems of systems with the intent to expand this model to incorporate the multi-national portfolio of Earth observation systems.

[edit] Butterfield: A System-of-Systems Engineering GEOSS: Architectural Approach

[edit] Abstract

There is an increasing need to perform systems-of-systems engineering (SoSE) in a global environment. A new SoSE Process has been developed which is a significant breakthrough in the development of large complex systems and net-centric systems-of-systems (SoS). The SoSE Process provides a complete, detailed, and systematic development approach for military and civil SoS. This architecture-centric, model-based Systems Engineering Process emphasizes concurrent development of the system architecture model and system specifications. It is applicable to all phases of a system’s lifecycle. The significant benefits of developing a system architecture model for GEOSS using the SoSE Process are described. An example of how the process would capture the architecture model of GEOSS is presented.

[edit] Intro

AN ARCHITECT translates problem domain concepts of the customer into the solution domain concepts of the developer and user. For the system to be built as envisioned, the architect develops a system architecture model to communicate the vision and track construction against it.

To manage this new developmental complexity, engineers must have available more detailed and comprehensive systems engineering processes and tools. The use of these new processes and tools will enable engineers to more efficiently and effectively develop a balanced system of system’s solution....a system is “an integrated composite of people, products, and processes that provide a capability to satisfy a stated need or objective”

First, a system is a composite of several pieces, which may include one or more components, comprised of people, products, and processes. Each of the components in a system brings its own capabilities and limitations, which include specific interfaces that exist between the individual components within the system as well as the components and the environment in which it operates.

Consider a specific example for illustration of a system verses an SoS. An example of a large complex system is a commercial airplane, where an integrator is responsible for bringing together individual systems, such as galleys, lavatories, controls and displays, and engines, to develop a transportation machine. None of these subsystems acts independent of one or more of the other subsystems in creating its services. An example of an SoS is our national air traffic management system. The very complex aircraft, while it can provide transportation in its own right, are parts of a SoS which is the national and international traffic control. In fact there are many systems within the airspace SoS—those for communications, weather observation and dissemination, etc—which operate interactively to produce an effect transportation capability.

[edit] What is Sos?

Features of an SoS are that the component systems can operate independently to produce products or services satisfying their customer objectives. The SoS may connect systems through interoperability arrangements that do not require tight coupling or strong integrations. This, in turn, leads to the attribute that an SoS maintains its inherent operational character even as system components join or disengage from the SoS. The Global Earth Observation System of Systems (GEOSS) is a good example of a complex SoS. SoS is: “A System-of-Systems (SoS) is a “super-system” comprised of elements that are themselves complex, independent systems which interact to achieve a common goal” [1].

Since the SoS does may not have absolute control over the component systems, the SoS must be a dynamic and open environment so that component systems, functions, and behaviors may be added or removed during its use with significant impact to the SoS framework.

(INTERNET IT mad it possible)Over the last decade, advances in information technology have made possible processes that enhance the ability of individual hardware platforms or systems to interoperate with one another. Consider networked computers and the internet, where various diverse computing systems interact for data creation, processing, and display. Computer languages have been developed to facilitate their interoperability using techniques such as software and the internet, the potential exists to seamlessly share sensor and display information, coordinate information flow, or provide subsystem-like functionality as part of a greater “SoS.” Clearly, as information technology has extended operational capability to include the utilization of disparate resources by sharing remotely located components, the need to understand how previously disparate, independent systems interoperate has become even more critical.

The SoSE process described in this paper uses a disciplined, enterprise wide effort to integrate systems, operations, and information- based tools and processes. Fig. 2 outlines how the integration of disparate technologies provides a unique product that creates system synergies across complementary interfaces. The SoSE process described in this paper uses a disciplined, enterprise wide effort to integrate systems, operations, and information- based tools and processes.

The SoSE process must therefore stress increased awareness of interoperability and risk management because of the dispersed nature of SoS components and the constraints imposed by the legacy features of these components Integrated Monitoring System. A first perspective is a large scale system that integrates various independent observation, modeling, and data management systems. Using this perspective, local control over observation systems continues to allow resource utilization to produce the data and information necessary to serve local needs efficiently and effectively by keeping decisions local. As long as the interfaces for integrating data transmission are maintained, and key parameters are reported for the collective good, the SoS is maintained so that integrated observation and modeling can proceed.

Data Sharing System. A second perspective is that the GEOSS is a system for converging worldwide monitoring systems. Under this perspective, the objective is to post all available data that is gathered to a centrally available resource like the internet, and permit access to use the data for the respective user’s purpose. The interoperability of these systems and the cross-purpose utilization of the data are dependent on the manners in which data are made available to end users. Data ownership rights and intellectual property claims provide some of the motivation for providing data from observing systems. Conversely, liability as a result of data misapplication, timeliness, sensor error, or unavailability could restrict dispersal. Methods for addressing these concerns are important to this perspective.

Supporting Society. The third perspective involves meeting social and political needs by using global observing data. As previously mentioned, multi-use of specific data, as in thewater oxygen example, could provide social benefits in regions affected by those impacts. Disparate data areas such as land observation, ecosystem, biodiversity, weather, water, climate, energy, health, and disasters, can be made available to local, national and regional authorities to address the concerns of their respective constituencies. This information can drive local policy, planning, and project implementation that impacts the countries or regions industry, welfare, and general quality of life.

An all-volunteer organization-driven SoS like GEOSS will not have high operational control of the systems that comprise the SoS. All of the contributing data systems will be voluntary participants in the GEOSS SoS. Therefore, the GEOSS SoS architecture must be developed with a robustness that allows the SoS to operate with a minimum loss of overall effectiveness as systems drop in and out of the SoS.

[edit] E Christian: GEOSS Architecture Principles and the GEOSS Clearinghouse

GEO recognizes that national systems and international programs coordinate or manage Earth observation systems under existing mandates. Accordingly, the GEOSS Plan asserts that GEOSS must be a “system of systems.” This means that GEOSS must not attempt to subordinate component Earth-observing systems under central control. Rather, all component systems contributing to GEOSS must continue to operate within their own mandates.

On its own, each component system is so different that its available resources are difficult for external users to discover or use. GEOSS must enable these component systems to leverage each other’s resources. The GEOSS Architecture is the primary mechanism to achieve such synergy among the contributed GEOSS components.

A major challenge for GEOSS is to tackle interoperability barriers specific to Earth observations: arranging for open and rapid data sharing, combing observations from different sources, turning data into information through models and other analysis tools, arranging for rapid acquisition of observations as events unfold, and so on.

[edit] Architecture

Fig. 3. Architects are concerned with designing ways to fit components together

Systems architects, like architects in other fields, are concerned with designing ways to fit components together to achieve a larger purpose (see Fig.3). Just as an architect may design a city with diverse components such as housing, factories, and offices, the architects of GEOSS must accommodate diverse components

GEOSS component systems encompass many scientific disciplines. GEOSS components also range from primary data collection systems to systems for creation or distribution of information products. GEOSS component systems span scales from national to global and employ observing techniques from in situ to remote sensing. Most significant from an architect’s perspective is that GEOSS component systems do not have common management

The wide diversity and essential independence of GEOSS component systems calls for a particular style of systems architecture, which is a style that emphasizes “interoperability.” Systems are “interoperable” when their differences are not a barrier to accomplishing a task that spans those systems. In the wildland fire scenario described above, real-time fire warnings must be interoperable with routine monitoring and background maps, and alerting systems must be interoperable across a range of communications media. Interoperability among diverse systems is based on separate systems interoperating through standard interfaces and other interoperability arrangements. Support for standardized arrangements is the basis for interoperability among credit card systems, for example. In GEOOS, perhaps the most apparent standard interface is the interoperable search service used, for example, in the GEOSS Clearinghouse

At the system-of-systems level in GEOSS, interoperability allows each system to operate within its own mandate, while also contributing synergistically to serve global goals. At the intersystem scale, interoperability allows systems to interoperate even though they are developed and operated independently. At the scale of a single system, interoperability means that a system is constructed from modular components. Such a modular system is more robust, more easily changed, and better able to use off-the-shelf, less expensive components. Given the expansive objectives of GEOSS, it is necessary that the GEOSS Architecture be embraced broadly. This means that the GEOSS Architecture must be mainstream and minimally prescriptive. The higher the number of barriers to participation, the fewer the number of participants. Ideally, the GEOSS Architecture should define just those “few things that must be the same so that everything else can be different”. The focus of GEOSS is on how systems work together. GEOSS itself will not constrain how any component system operates within itself.

[edit] Implementing SOA

to GEOSS are to share observations and products with GEOSS as a whole. To enable resource sharing, the GEOSS Architecture uses a style of systems interoperability known as “Service Oriented Architecture.” A “service” is the basic unit in a service-oriented architecture. The concept of a service is straightforward. Using the analogy of a restaurant, a service in operation is like a waiter handling a dinner order from a customer (see Fig. 4). Just as a customer is not expected to give step-by-step instructions to the kitchen, a service allows clients to specify their requests precisely, but it does not allow clients to specify the exact procedure for satisfying the requests. This is a very important feature for broad interoperability. Clients have no more control than necessary, and clients need not be concerned with the details of execution. The GEOSS Architecture is most evident at the points of interoperability among the various systems contributed as GEOSS Components. “Interfaces” are the primary touch points between component systems—a way to plug one system into other systems. GEOSS interoperability emphasizes interfaces, defining precisely how system components can interface with each other. This minimizes impact on component systems other than where each system interfaces to the shared GEOSS architecture

In the wildland fire scenario described above, there are various interfaces among the different systems in use. Many of these interfaces are implemented as services in the GEOSS Architecture sense. For instance, background maps of terrain, vegetation, and roads are typically available through the standardized service for map display. These maps can be overlain with real-time fire warnings from a standard Internet news feed service. Finally, warnings for any hazard can be communicated across all available media using the standard format for alerts.


GEOSS overall is made up of contributed systems operating within their own mandates. GEOSS adds value to these component systems to the extent that they leverage each other’s resources through standard interfaces and other interoperability arrangements. That synergy among diverse and independent systems is how GEOSS makes Earth observation data and information more accessible, comparable, and understandable. As stated in the GEOSS Plan, the “success of GEOSS will depend on data and information providers accepting and implementing a set of interoperability arrangements, including technical specifications for collecting, processing, storing, and disseminating shared data, metadata, and products” [1]. Any newly contributed GEOSS Component must implement GEOSS interoperability arrangements as registered at the time when it is contributed.




Fig. 4. Service in operation is like a waiter handling a dinner order.

At the system-of-systems level in GEOSS, interoperability allows each system to operate within its own mandate, while also contributing synergistically to serve global goals. At the intersystem scale, interoperability allows systems to interoperate even though they are developed and operated independently. At the scale of a single system, interoperability means that a

Because the GEOSS Architecture is an instance of a service-oriented architecture, the GEOSS Plan addresses how service interfaces are defined. If a service interface is like a power connector, a service interface definition is like the specification for making plugs and outlets (see Fig. 5).

Fig. 5. Service interface is like a power connector.

Software engineers have several ways to define a service interface at present, e.g., CORBA, Common CORBA, Object Request Broker Architecture;Web Service Definition Language (WSDL); electronic business Extensible Markup Language (ebXML), or Unified Modelling Language (UML). Because these interface definition languages are not equivalent, GEOSS has not specified one standard for service interface definitions. The GEOSS Plan states: “systems interoperating in GEOSS should use any one of four open standard ways to describe service interfaces.” In the wildland fire example, the standard for displaying maps is defined using one of these interface languages.

Today, building adaptors to achieve interoperability between systems can be frustrating. Even though most systems have network service interfaces, often such services are poorly documented. It is crucially important to have service definitions; it is less important that all service definitions are expressed the same way. Still, it is inconvenient that software designers must sometimes translate between service definitions. When the field of software design converges on a single standard, GEOSS service interoperability should be updated accordingly.

[edit] GEOSS Clearinghouse

GEOSS Clearinghouse acts as a cross-cutting catalog among registered resources, including services and standards as well as data and information. GEOSS Clearinghouse provides registry services with a description of each of the formally contributed components of GEOSS, metadata about the various data and information holdings in each of the contributed components, technical specifications for using the services exposed by the contributed components, and descriptions of key interoperability standards in use across the contributed components of GEOSS.

[edit] Conclusion

[edit] Other Links


Key Question: “What few things need to be the same so that everything else can be different?” - Michael Tiemann, CTO of Redhat

A CIO looking into migration from legacy to modern systems asked: What few tings ....Its a remarkable question ; of architecture, platform, and that technology is a supporting rather than a limiting factor. Applicable risk analysis, cash management


Boy does that go to the heart of the standardization/hub/network-effect problem in short order. While it is a good question from a public-good point of view, from a private-good/capitalist point of view the more likely question is “What things can be …”

Happiness - non rival good Harlan Cleveland's sharing transactions..

Happiness is not like ice cream. When I eat a spoonful of ice cream from the quart in the fridge I’m taking that spoonful away from the rest of my family. Happiness isn’t like that, if I’m a bit more happy it doesn’t follow that the rest of my family is denied some happiness.

Economists, who like most scientists would rather make up complex terms than steal ice cream from their children, have a term for that. Ice cream is a rival good, and happiness as a non-rival good. Men are very clever at converting non-rival goods into rival goods. I figure this is because they spent years locked sibling rivalry. “I’m taller than you.” “Oh, yeah, well I’m thinner.” “So, what’s so great about thin!”

Optimizing Commonalities and Differences What few things need to be the same so that everything else can be different? This question, poised by Michael Tiemann, CTO of Redhat, is at the heart of many of the decisions facing IT today. This question defines the power of web services as well as the move toward managed desktops in corporations. Finding the balance in this question is a critical decision facing technologists as they develop enterprise architectures and operating models so that IT can serve the business.


Personal tools
Workspaces
Clicky Web Analytics