The Long-Tail Effect

You can always tell the cohesiveness of the architectural vision of a product, by analyzing its architecture. From what I have seen, a lot of products suffer from what I describe as the Long-Tail Effect. And the longer the product has been out in the market, the longer the length of this tail.

The long-tail is a graphical depiction of how deeply steeped a product is in its legacy past. In my view, this can be primarily attributed to a lack of a cohesive vision over time.

It is important to understand this aspect of product evaluation, especially if you are considering hanging on to your acquisition for a long period of time. You have to find the right balance between product maturity and its architectural cohesiveness. In my view, the long-tail ends up negatively skewing the Total Cost of Ownership (TCO). The more steeped a product in its past, i.e., the longer the tail, the more the effort that is required to maintain the product over time.

Aligning Architecture with Business Strategy

Over time, I have come to realize that architecture is not purely Information Technology (IT) functionality, in the traditional sense of viewing IT. It is strategic in intent; hence it needs to draw directly from business strategy. The other thing that I have realized is that architecture ends up lasting longer than business strategy. The fact that decades old legacy systems like Mainframe/COBOL, etc are still deeply entrenched within organizations supports that claim.

Business strategy, on the other hand, continually evolves over time, in response to the changing competitive landscape. If architectural efforts are not properly tuned with the business strategy, architecture ends up constraining instead of enabling the achievement of business strategy. Once again, taking the example of Mainframe/COBOL, such systems are geared towards batch processing of information. Going forward, if the organization wants to start monitoring its activities in real to near-real time, it will be constrained by the capabilities of its existing Mainframe/COBOL systems.

My understanding is that the following should occur, to ensure the proper alignment of architectural efforts with business strategy.

1. Architects should participate in the business strategy process
2. Architects should have their interpretation of business strategy, validated by business strategists
   
3. Architects should focus on tackling only those challenges that directly affect the implementation of the business strategy
4. Architects should continually assess the relevance of their initiatives against the business strategy
   

Frank Gehry - Pritzker Prize Winning Architect

Software Architecture is a relatively new field when compared to Building Architecture. Needless to say, software architects frequently look at the field of Building Architecture, to seek inspiration and to draw analogies. One of the notable building architects that I have been impressed with is Frank Gehry. It is funny the way that I first became aware of him. I was watching Arthur, a show on public television, with my son. There is this episode where Frank Gehry helps Arthur and his friends design a new tree house. Their tree house gets destroyed, and Arthur and his friends start debating over what to do. They run into Frank Gehry at the local ice cream shop, who then asks each one of them to come up with the new design ideas for their new tree house. The kids go about doing that and then present their design ideas to Frank. Some of the ideas are quite out there, which get ridiculed by the group. This is where Frank makes a statement that really stuck to me. He says, "Who says that a building has to look like a box?".

If you look at some of his work, like the Pritzker pavilion, Dancing house in Prague, Guggenheim Museum, Chiat/Day Building, you would really understand what he means by that statement. His work makes you drop all preconceived notions of what a building should look like. I think that this is equally relevant in the area of software architecture. On top of that Frank has a reputation of completing his projects on time and in budget. This can be attributed to his approach that states:

1. Prevent political and business interests from interfering with design, to arrive at an outcome that is as close as possible to the original design
2. Get a detailed and realistic cost estimate before proceeding
3. Maintain close relationship with the implementers

What is Enterprise Architecture?

The last few years, I have been predominantly working on large scale projects. These projects have a high impact either on account of their scope (enterprise wide) or on account of their cost. Previously, the area of Enterprise Architecture (EA) had been somewhat of a mystery to me. Even though I was dealing with some of the aspects that were related to EA, I wasn't clear on what it really meant. On top of that, there was that ongoing debate on SOA vs EA, which still continues. So, I started looking at the various frameworks like Zachman and TOGAF, which definitely helped put things into perspective.

In that same spirit of inquisitiveness, last week (May 15-18, 2007), I attended the Enterprise Architecture Workshop by Bredemeyer Consulting. My biggest takeaways from that experience were:

1. Enterprise Architecture is nothing else but Architecture done at the enterprise level.
2. There will always be challenges around you. Focus on tackling only those challenges that directly affect the implementation of the business strategy.
3. There is no such thing as too low a level. If delving to the lowest level of detail is important for the success of your initiative; Do it.

Role of Architecture in these times of Outsourcing

Outsourcing in the IT world is a reality. Given that the IT department has always been viewed as a cost center, more and more companies are looking at outsourcing, to contain and to better manage IT costs.

In my view, Architecture is a strategic capability. There is tremendous risk in outsourcing this capability. Outsourcing a strategic capability will deplete the associated knowledge within an organization. It will impact an organization's ability to leverage its strategic capabilities to quickly react to new opportunities. If the Architecture capability does not exist within an organization or if it is not mature, work with the vendor(s) to develop this capability.

Also, outsourcing contracts are never open-ended. They are for a specific duration. If SLAs are not met, organizations have the option to not renew the contracts. Given that, it only makes sense to retain strategic capabilities and to leverage them in contract negotiations.

The following paragraph is from an article by IBM that talks about the benefits and the risks associated with outsourcing.

"The IT experts brought technology standardization and disciplined project methodologies to their clients. Indeed, all the firms valued learning from their vendors about standard technology components and project methodology. But they also noted that, while vendors were learning about their business, vendors could never know their business as well as their own people. Thus, the firms needed to retain—or develop—a competency in applying technology to meet strategic goals."