On the adoption of open source

I have been working with open source products for quite a few years now. These have predominantly been Java based frameworks and other products. It used to be that there were only a handful of such products, which were available in the past. That picture has now changed. If you were to look at SourceForge, for instance, that site hosts over 130k projects.

With this rapid proliferation, one would be inclined to believe that the development community, in general, have wholeheartedly adopted open source. However, that might be an overly optimistic statement. The arguments that I have heard against open source are:

• The future direction of such products might not be in line with direction of the adopters.
• The adopters would still need to know the internal workings of such products, to understand their limitations and to quickly troubleshoot any issues.
• The needs of the adopters are so unique that they cannot be completely fulfilled by any open source product.

I am not sure if this movement has had a polarizing affect but I do believe that there have been different levels of open source adoption. At one end of the spectrum you find companies that have adopted open source to the fullest extent. At the other end of the spectrum, you find companies that have either resisted, been indifferent, or have marginally adopted open source. If you were to plot open source adoption on a graph, with the adopters and the non-adopters at either ends, the curve would be positively skewed towards people that have completely adopted open source. The curve would also have a long tail, towards the non-adopters, indicating the different levels of adoption.

Enterprise Architecture and SOA

Zachman Framework analyzes EA from the various perspectives (Planner, Owner, Designer, Builder, Subcontractor) and abstractions (What, How, Where, Who, When, Why). Bredemeyer Consulting describe EA as business capabilities architecture, focusing on the triad of people, process, and technology. TOGAF describes how to set up EA by iterating through the various phases of their Architecture Development Method. In short, EA is all about seeking an alignment between IT and business, to make IT more pliable to the business needs.

Technologically, SOA is an extension of the age-old component oriented architecture (COM, CORBA, EJB, etc). Fundamentally, it has a similar set of challenges and benefits. Exposing a service as a Web Service primarily focuses the attention on how the data is interchanged, and on a plethora of supporting standards. Exposing services the Jini way, which I might add is more mature than web services, lets you interchange behavior along with the data.

Conceptually, SOA focuses on the business processes, hooking together different services to create fluid processes. It seeks to align the various services to business processes, to help create a flexible and an agile IT.

In my view, there are similarities in the intent behind both EA and SOA. The approaches, however, may be different.

On Frameworks and Data Mapping Tools

In my view, frameworks like Spring provide the following benefits:

• Allow for cleaner separation of layers
• Automatically apply certain well established design patterns
• Externally configurable (see below)
• Structured to support plug-and-play of components

I understand that too much of XML can be quite confusing. For instance, I had the same issue with all the action-mappings within Struts. However, I soon realized the reason why such frameworks were configuration intensive, be it XML or annotations. Most of these frameworks are general purpose in nature. For instance, you could use Spring to run a web application, an RMI application, or a batch application. Being configuration intensive is what makes these frameworks more flexible, for use in different environments. You cannot therefore blame such general purpose frameworks for being configuration intensive. It is the users of such frameworks that are responsible for balancing flexibility against manageability. That also applies to the use of features like Dependency Injection, externally configurable transactions, etc.

I have a different opinion on O/R mapping tools like Hibernate and TopLink. In the past, I had worked with TopLink to quite an extent. What I realized was that such mapping tools were a good fit if the domain object model was the driving force behind the relational data model. Any other way, and you had mapping issues. Also, at that time TopLink did not support stored procedures, and the applications relied quite heavily on them.

A good alternative would be a data mapping framework like iBatis. You write the SQL, and iBatis executes it for you, without you having to write a single line of JDBC related code. Along with that, it also manages all database related resources (statements, connections, result sets, etc) for you.

Structuring innovation within a group

I was listening to a podcast interview with Rosabeth Moss Kanter, who is the Ernest L. Arbuckle Professor of Business Administration at Harvard Business School. One of the ideas that were discussed, was that of the Innovation Pyramid. I believe that this strategy has broad applicability, not only can it help structure innovation at the enterprise level but also within a group or a division. Here is what she had to say about this innovation strategy.

"The innovation pyramid is an innovation strategy that works at three levels. The lion's share of the investment underwrites a few big bets at the top: clear directions for the future. The second level is a portfolio of promising mid-range ideas driven by designated teams. At the bottom of the pyramid are early-stage ideas or incremental innovations that permit continuous improvement.

Influence flows from top to bottom—the big bets encourage smaller wins heading in the same direction. But success can also flow from the bottom to the top—3M's Post-it Notes is one such example.

Senior managers can use the innovation pyramid to gauge current efforts, recalibrate as ideas prove their value, and ensure there is activity at all levels."

Designing interfaces the iPod way

Recently I started using the iPod, to listen to podcasts, on my way to and back from work. The one thing that I find most fascinating about this device is the simplicity of its user interface. You have a touch sensitive dial to work with the volume, and around that are buttons to play/pause, forward, rewind, and a button to view the menu. I am sure that on the inside the product has a lot of complex engineering but on the outside, all the elements of its user interface are very basic and very functional in nature.

Why can't the same principles be applied to the software world? Why is it that any time that I look around there is a new API, with its own unique way of working with it? Why can't the APIs be as simple and as elegant as the iPod user interface?