Wednesday, September 12, 2007


Appliances seem to be a hot topic at the moment; manufacturers are falling over themselves to come out with an appliance that sits in the data centre with minimal management overhead and levels of performance that are unsurpassed. This ranges from specialised XML accelerators to Google's appliance.

There is a natural trade off between the flexibility of a conventional server and the utility of an appliance; as a natural sceptic I remain unconvinced that in most cases it makes sense to use an appliance, but I am open to persuasion :-)

Sunday, August 05, 2007

Enterprise Architecture?

Architecture seems to be a heavily overloaded term at the moment; as Martin Fowler notes, the title "architect" can cover a wide spectrum of roles. In my own experience I have seen the term architecture to mean everything from am abstract arrangement of requirements to a rack diagram showing the configuration and cabling of a number of servers. Accordingly one of my stock interview questions when hiring people is "what is architecture?". I won't embarrass anyone by repeating some of the answers I have had, but in general I am surprised by the number of people claiming to be architects who struggle with this question.

Drilling down the current buzz term is 'enterprise architecture'. However even for this term there is a variety of interpretations, even if there is a de facto definition of the term; the following is taken from wikipedia:

Enterprise Architecture is the practice of applying a comprehensive and rigorous method for describing a current and/or future structure and behavior for an organization's processes, information systems, personnel and organizational sub-units, so that they align with the organization's core goals and strategic direction. Although often associated strictly with information technology, it relates more broadly to the practice of business optimization in that it addresses business architecture, performance management, organizational structure and process architecture as well.

My own experience is that organisations are putting together enterprise architectures today, because that is what everyone in the industry says is required. However in most cases due to the absence of a business strategy enterprise architecture defaults to technical architecture - a description of an IT solution, perhaps phased over some period of time.

The situation is confused all the more by software architecture for enterprise applications. This is the architecture as captured by Sun's Certified Enterprise Architect qualification, and also as described in books such as Martin Fowler's Patterns of Enterprise Application Architecture.

Common to most of these ideas about architecture is that there is an abstract representation of a target IT solution, to some business problem. Therein lies the key difference from the rack diagram - there is no abstraction, it is a wiring diagram rather than a building plan. Which is why I don't think of the rack diagram end of the scale as architecture.

Wednesday, June 27, 2007

Build vs Buy

I was asked recently about build vs buy. Specifically what was my opinion? Without thinking about it I betrayed my software background by saying that the pendulum had swung too far towards buy, whereas with modern approaches to software engineering the risk involved in build is much less than it once was provided the requirements are well understood.

However since then I have had a chance to reflect on this and I think to answer this question requires a little more nuance. Broadly speaking there are three categories of problem to consider:
  • Problems that can be solved by a commodity off the shelf product.
  • Problems that can be solved by configuring an off the shelf product.
  • Problems for which no off the shelf product exist.
The first category is a no brainer: there is no sense in writing your own word processor when there are several mature products on the market. Typically any unique business requirements for such problems will be sacrificed at the altar of the cost savings of commodity software.

The second two categories are more interesting. In my experience the biggest problem in IT projects is identifying and agreeing the business requirements. The first category resolves this by using the product to determine the requirements, but neither of the other two help with this. Modern products such as SAP and Siebel have such flexible data models that they can be configured and adapted to do pretty much whatever you want.

I'm not saying that organizations should go out and write their own ERP systems from scratch, but on the other hand I have worked on several projects where only a small part of the capability of such a large package is being used, so there is minimal value in buying rather than building in these circumstances.

The bottom line: if you don't understand your business requirements, build or buy makes no difference!