Wednesday, February 14, 2007

Open source vs. commercial software: The case for freedom

I have been thinking about the whole open source versus commercial software and realized that at their heart both offer the same thing : freedom!

The whole argument actually goes back to economics or rather formulation of economies: the concept of "gift economy" versus "money economy". Money economy promises freedom from patronage and privilege - "Any body can buy it as long as they have the money". On the other hand, Gift economy promises freedom to those, who for some reason cannot or do not wish to participate in the money economy.

In practice, a healthy mix is needed. It is no different from public and private mix required in business or providing mobility in a city. Consider a city where there is no public transportation, only form of mobility offered is through personal vehicles. You can already start guessing the mix of people who will live in that city. A typical modern suburbia.

On the other hand, a city where public transportation is the only means of mobility, chances are people will get stranded when the system breaks down, such as when operators or employees go on strikes. While the comparison is not entirely valid, many open-source projects are like "Soup nazi" kitchens, where your influence rests on your personal relationship with the committer. However, for a lot of customers with less than adequate money, it offers the ability to deploy technology within their budgets.

As for me, I would like to have the ability to switch a commercial stack with an open-source one, and vice-versa, based on the needs of the client. That is a luxury, however, that I can only dream about....

Saturday, February 10, 2007

Responsive buildings and software context

Building architects are now thinking of making responsive buidings, that change shape based on the context. Software architects have battled such designs since the advent of authorization policies, where the software looks, feels and responds differently in different contexts.

Finally the students of architecture are teaching their building masters a trick or two.

Thursday, February 8, 2007

Runtime software structures

Software architects need to start worrying about runtime software structures on a larger scale than they do currently.

The software landscape is changing from simple client-server models, to a mesh of connected systems, linked by real time calls across the network. As the world increasingly becomes a network of live systems feeding data to each other in real time, the software architects' emphasis will need to change from static structures to runtime structures. This is because devices and computational structures will be needed to constantly monitor several raw streams, for data that needs to be aggregated, compiled and analyzed.

Traditionally software architects focus on static structures while conceiving solutions. Classes, frameworks, libraries, etc, are all static structures that focus on how the written code is structured or layered. Runtime structures, in contrast, are dynamic and may change based on certain system events.

User community world over will start to realize, how their everyday choices impact real time supply chains. This may lead to a change in people's interaction behavior as well. As systems are getting linked, more and more users are interested in getting a dashboard view of the system.

Interaction design then changes from active (initiated by the user) to reactive (response to an event). In his book In the Bubble, John Thackara refers to this as "In the flow" and asserts that a process control paradigm will increasingly become more important.

This also involves a change in user mental models. An important aspect being talked increasingly in solution design is the concept of personal dashboards that would provide people with information they should be looking at or acting on.

All this is great. However, in my humble opinion, the system should force the users at some point to review past data and performance and make some critical decisions. This could be in form of change in policies, or change in the process itself.

An important question to ask is what will be this sub-system and how will vast amounts of information be analyzed and sorted. Lastly, but not less important,is the fact that if everything is reactive, then how do we engage the human operators to make decisions and develop foresight. In the environment where every action is a reaction to an event, what kind of institutions will this create and what will be the impact on social structures.


Sunday, February 4, 2007

Design options for reducing environmental costs of mobility

In my previous blog, I mentioned what I thought were key parameters in determining reducing overall mobility related costs in North America and rest of the world.

At a policy level, there is already a change in investment patterns made by departments of transportation. Departments of Transportation are responsible for investments in state highway systems. There is a growing realization that highway investments have to change from the single dimension of preservation of asset value to multiple dimensions of providing mobility, ensuring safety and reducing environmental costs.

However, that is no longer enough. In urban America, a very large number of people have commute distances that can be best described as intra-regional and not intra-urban. The same is true for container traffic. The option is then, to provide regional multi-modal systems. To be successful, regional multi-modal systems require integration of transportation systems at both ends of the system. Fo most commuters, it means a viable road based personal and public transportation systems for their sub-urban environment.

A similar strategy is required for goods transport. For intra-regional and inter-region transportation of goods, rail systems could become the system of choice rather than the huge fleet of road and air vehicles maintained by logistics organizations. It could also mean developing a market for smaller and more nimble logistics companies that are more regional in nature. These could offer collection, sortation and delivery systems at either end of the system.

Software architecture

How does it all tie back to software architecture? The question obviously is to design a software architecture to meet this requirement. The following stakeholders needs need to be met to meet the above goals.

1. System owners and operators - These are typically the owners of the system such as state departments of transportation.
2. Policy makers - These are national transportation bodies.
3. Local system owners and operators - These are urban bodies responsible for planning and running the system.
4. Individual system users - These are individuals who make travel decisions for planning commutes and making them.
5. Commercial system users - These are organizations who use the system for commercial reasons such as freight and logistics companies.