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?

Assessing organizational capabilities from a grassroots level

The classic big picture view of the organizational capabilities requires a certain vantage point from where the picture is drawn. It requires visibility into some of the esoteric areas within an organization. Quite often the big picture is either fuzzy or incomplete. On top of that there are solutions in progress that require a good understanding of the capabilities of the organization.

In my view, one way to work around such situations is by individual initiative and commitment. If the capability domains are known, try striking a conversation with the key players within those domains. You will be surprised at the quality of information that comes out. Sometimes these conversations help dispel some well-known myths and help establish certain lesser-known facts. This is also a good starting point to identify the missing pieces from the big picture. Conversation-chains help discover other key capability domains. Finally, cross referencing such information obtained from the different capability domains promotes a better understanding of what we seek.

Need an Architect to baby-sit my requirements

A common perception of an architect is that of an alpha geek, the go-to guy for all technical problems. Often architects do evolve from deep technical backgrounds, and do tend to carry that air around them. It is not surprising when that impression ends up fortifying the common perception.

Being stereotyped that way doesn't really help when you want to progress up the value chain. You get to hear things like, "We never thought you would be interested in the business side of things". It then becomes a tough uphill battle to get into the space where solutions to business problems are being crafted.

Can an Architect be an effective Project Manager as well?

When you look around in the job market, you see job postings that require both Architectural and Project Management expertise. Typically these postings are from companies that don't have an established architecture practice but that recognize the importance of architecture.

The question that comes to my mind is, 'Can an architect be an effective project manager as well?’ From what I understand, after having worked as an architect and after having dabbled with project management, the general attitude of the practitioners within these fields is very different. As an architect, you are trained to abstract complexity, and to only delve into details that are architecturally significant. As a project manager, you are required to delve into the lowest level of detail and to work out their dependencies.

Maybe there are projects of a certain scale where having an Architect/Project Manager works out to be more cost effective.

HP's Ecosystem and its bearing on Enterprise/Software Architecture

I was listening to a podcast by Businessweek that interviewed Sam Lucente, who is the Vice-President of Design at Hewlett Packard. He talked about the concept of universal design, also referred to as HP's Ecosystem.

In the conversation that ensued, he talked about 3 approaches. The first, Design to Simplify that allows to drive reusable design elements. The second, Design to Differentiate that relates to how to differentiate oneself in the marketplace. The last, Design to Innovate that helps create new markets and new business models. In terms of articulating contributions to the bottom line of the company, Design to Simplify had a direct impact whereas Design to Innovate was the most difficult to articulate.

In my view, these approaches are equally applicable to the realms of Enterprise/Software Architecture. Not only that, these approaches appear to be evolutionary, in the order as described above. For companies that are still exploring the value of having an architecture practice, the most attractive value proposition would be to use architecture as a means to create reusable elements.

The next steps in the evolution of an architecture practice would be where it helps a company to Differentiate and to Innovate.