Experts

Someone recently introduced himself to me as an “expert” in his particular area. I was somewhat taken aback by this as in Britain at least this is not a term we use lightly. As I reflected on this I reached two diametrically opposite interpretations of this word:

• Someone calling themself an expert is one of a handful of people in the world who knows all there is to know about this particular subject; if they aren’t able to answer a question (perhaps after going away to think about it on their own) no-one can.

• Someone calling themself an expert has such a weak understanding of the subject in question that they aren’t even aware of all of their areas of ignorance. In all likelihood such experts will answer questions inaccurately if they can answer them at all.

Note that experts in the former category don’t need to describe themselves in this way - it is obvious.

An Audience with Michael Dell

I recently had the pleasure of hearing Michael Dell speak in a briefing session organised by BCS ELITE.

Michael started off by giving his views about industry trends and the current economic situation. In particular he spent quite a lot of time talking about cloud computing and how Dell are working with large technology organisations such as Amazon and Yahoo. He talked about the emergence of private clouds - cloud based solutions with limited shared infrastructure to provide some of the benefits of cloud computing while at the same time assuaging concerns about security and integrity of data.

After Michael’s presentation there was a Q&A session. The questions varied from “are you getting too close to Microsoft” to “what would you do if you weren’t running Dell”. Michael answered all of these questions head-on, without any kind of hesitation. What really came across very strongly was his deep passion for technology - he very clearly would rather spend time with his engineers than with his bean counters. In this respect his attitude was similar to Bill Gates’s, when I heard him speak last year (albeit in a more constrained forum). It was great to hear Michael speak - my congratulations and thanks go to BCS ELITE for organising this event.

The Enterprise in EA

One of the areas of contention in EA in anything but the smallest organisation, is how to define the enterprise, i.e. the ‘E’ in ‘EA’. This may seem obvious - if you are in the business of manufacturing and selling widgets, then the enterprise is the business of manufacturing and selling widgets. However in these days of outsourcing, off-shoring and reconfiguration of value chains things are not so straightforward. Consider the following examples.

The first is Tesco. As a large and successful retailer its enterprise consists of taking products from suppliers and selling them to consumers via multiple channels (various store formats, online and catalogue). It provides back office functions in support of these activities. So what is the enterprise here? Are suppliers part of the enterprise? Are the different haulage companies used by Tesco part of the enterprise? Is the internal email system part of the enterprise?

As a second example consider a public sector organisation such as an NHS trust. It delivers care to patients, funded by the department of health. If it is a larger trust it may also undertake teaching and/or research. So does the enterprise in this case include the research systems? The teaching systems?

Finally, my own pet favourite example: a systems integration programme. Consider a prime contractor for the NHS National Programme for IT. A prime delivers the programme against the customer’s specification to the customer’s stakeholders. So in this case we have a confluence of the NHS enterprise, an individual trust’s enterprise and the prime contractor’s enterprise.

I think the first thing that becomes clear from these examples is the link between the enterprise and governance. As such I could choose the enterprise to be anything I want, but it is meaningless if I have no ability to measure and influence conformance against my target architecture. This potentially means that the enterprise can be broader than a legal entity. For example Tesco could include elements of EA in the contracts that they agree with suppliers e.g. use of standardised interfaces for communications, common business processes etc. Conversely it also explains the common situation of organisations creating EA teams but not providing any governance mechanism, which leads to a team that produces lots of good ideas which are then largely ignored by the rest of the organisation.

My second observation is more contentious: if the enterprise picture is highly complicated with multiple powerful stakeholders who have divergent interests, there is no point trying to have anything other than a trivial enterprise architecture, because parochial stakeholder interests will always defeat a federated, consensus-based governance model. In short, if it is a complex stakeholder environment, see what emerges rather than trying to impose a centralised EA.

Requirements and IT programmes

Requirements in any kind of IT-based engineering programme are difficult. The bigger the programme, the more difficult they are. This may seem paradoxical in world in which Google, Amazon and eBay are delivering high performance IT-driven businesses to massive audiences. Why is that?

I think there are three major reasons for this.

The first is the predilection for big-bang approaches with large programmes. This seems to be particularly prevalent in public sector programmes, where IT is driving business transformation, such as Aspire, NPfIT and DII. By adopting a big-bang approach it is not possible to attempt to scale up ideas from agile development around getting something working and then improving on it in stages. Conversely Google et al typically introduce new products and services initially to limited audiences as betas (e.g. gmail) and only gradually increase functionality until sufficient stability for full release has been reached.

The next reason, may be peculiarly British. The UK Office of Government Commerce has mandated the use of output-based specifications for procurement of large programmes. This is fine in itself since this approach ensures focus is maintained on end-user business benefits. However output-based specifications are not engineering requirements, so delivery of a service can not be measured against an OBS. Let’s consider an example to make this clear. The following requirement is from the OBS for the NPfIT, available on the Department of Health’s public web site.

The service shall be secure and confidential, and only accessible on a need-to-know basis to authorised users.

In the absence of precise definitions of “secure”, “confidential” and “need-to-know” this is a vacuous statement!

(Note that it may appear that I have selected this requirement as an extreme example in order to demonstrate the point, but in fact I chose this at random.)

I’m not suggesting that the requirements against which programmes are procured should go in to engineering levels of detail, but conversely these requirements are inadequate as a basis for engineering delivery. The approach that I have seen at first hand, and which worked successfully, is to use such OBS style requirements as the starting point for requirements elaboration. For a particular release of a service, the requirement should be elaborated to the degree that it is testable and implementable, and that should be agreed between customer and supplier as the basis for determining whether the requirement has been met or not. In long-term programmes the elaboration may alter over time (for example an encryption algorithm which was secure 10 years ago may not be secure today). The essence is that the OBS expresses the spirit of the requirements rather than the details; procurement requirements are not the same thing as engineering requirements.

The final reason is the use of COTS packages for delivery of such programmes. The challenge is that the delivered requirements depend totally on the capability of the COTS package. This is more an issue for business processes, since these tend to be intrinsic to specific packages. This is another reason why ideas from agile development can not be reused. Also, picking up on the previous point, the vagueness of an OBS means that the customer and COTS vendor could have very different (but equally valid) interpretations of what a requirement means.

Is this a real problem? Well, judge for yourself the success of these large programmes...

Building Architecture vs Aeronautical Engineering

Building architecture is often used as an example of what IT architecture should aspire to. There are a number of reasons for this: for a start, the term “architecture” is normally associated with buildings, and has really been adopted by IT in parallel with the emergence of the new discipline of abstracting large scale systems in order to be able to understand them. This close relationship with building architecture has been cemented by the work on architecture patterns, which takes as its starting point Christopher Alexander’s work on patterns in building architecture.

There are certainly some similarities between building and IT architecture. Both use tools of abstraction to manage complexity; for example building architecture uses plan and elevation drawings to understand the structure of buildings, and mathematics to understand how to construct buildings. IT uses architecture views (such as the ToGAF framework) to understand what needs to be built, and a variety of tools and processes in order to build these systems.

But what about after construction? How well does the metaphor hold then? I think at this point it falls apart; buildings are by and large static, maintenance is typically restricted to superficial changes such as painting and decorating. It is unusual for buildings to go through fundamental reconstruction. On the other hand, IT systems are living beasts, which are subject to constant change, of varying degrees. Sometimes it is addition of a minor feature or a new interface; other times it can be fundamental re-architecting of the entire system in order to accommodate new requirements, or in order to accommodate original requirements which were not properly understood.

In practice this means that in the case of building architecture, design documents and blueprints will gather dust post-construction, whereas for IT systems it is critical to have an up-to-date ‘as-maintained’ documentation set. (That said, in my experience organisations that do maintain such documentation are the exception rather than the rule.)

I think a better metaphor is aeronautical engineering, where the discipline involved in maintaining up-to-date documentation for in-life aircraft, associated systems and components is quite incredible. I was struck by this years ago when I worked on a project with Boeing re-engineering a tool they use - Wiring Illuminator - which helped maintainers to understand the individual wires and connected end-points in aircraft. Subsequently I worked on JSF where the life history of every single component was being maintained. Note that I am following well-trodden ground here: over 10 years ago Ross Anderson was pointing out that IT could learn much from the way that the aircraft industry deals with safety-related issues.

As the discipline of IT architecture develops I fully expect that the need to capture high quality ‘as-maintained’ documentation will be critical. Tim O’Reilly shrewdly observed that a key industry differentiator in the future will be service management organisations; I would add to that: it will be service management organisations who excel at ‘as-maintained’ documentation and baseline management.

What Should Go In The Cloud?

Cloud computing is all the rage. Vendors are falling over themselves to offer services from the cloud. Analysts are proclaiming that the cloud is the next big thing. So given that cloud based services provide economies of scale that most businesses can’t dream of, we should be pushing all of our services in to the cloud rather than provisioning them ourselves, right?

Let’s consider an example from the last programme that I worked on. In that programme a national single sign on (SSO) solution was provided as an external service (in the cloud in fashionable parlance). This ensured a single identity across NHS organisations, allowing users to cross organisational boundaries with a single identity. Great idea. One minor problem: if for any reason this external service was unavailable, users were not able to log in to any of their applications, and users already logged in had their sessions terminated. Unavailability of that single service impacted all other business applications.

What seemed like a great idea at the time, did not really stand up to scrutiny in practice. Of course hindsight is a great tool so I am not criticising the original design choice, but trying to learn from it. Using this example it is obvious that not everything should be in the cloud - operational considerations need to be traded off against financial benefits. So how do we decide what should go in the cloud and what we should deliver ourselves?

There are a number of dimensions to this. The first consideration is the business’s value chain. Any secondary activity in the value chain is a candidate for delivery via the cloud. For example, HR systems, intranets etc. What about primary activities? Instinctively these should be delivered internally. But if that is the case, how is it that salesforce.com has been so successful?? I think the answer is deeper: primary activities should be delivered from the cloud if they can so provide greater levels of quality and reliability than would be possible by delivering it internally. So for a large, mature organisation with a sophisticated IT operation, delivering CRM internally might make sense. For other organisations CRM via salesforce.com might make sense even though this is a primary activity for the organisation.

Returning to my SSO example then, for those NHS organisations for whom SSO is too complicated a task it makes sense to deliver this from the cloud. For larger, more sophisticated NHS organisations, internal delivery of SSO might be appropriate. That just leaves the problem of interoperability...for a later blog!

Massive IT Programmes

I have just recently changed jobs, joining Cognizant’s Advanced Solutions Practice, having spent the last three and a half years working for BT as Chief Architect on the NHS National Programme for IT. Moving on from that role has given me the chance to reflect a little on some of the challenges that I faced in that role.

The programme is frequently in the press, and has been labelled as a classic example of a failing IT programme. Though the press coverage has in general been ill-informed and inaccurate there have undoubtedly been problems with delivering the programme, for many reasons, which I will not get in to here. However some general observations can be made about massive IT programmes.

One of the greatest challenges in programmes such as this one is the sheer size of change involved in terms of both business and technology. The traditional programme and project management approach to dealing with the complexity that this scale brings is to follow a reductionist strategy, breaking the overall programme into smaller manageable parts. The difficulty with this is choosing how to slice and dice the large problem. Executed correctly this approach allows application of traditional programme management and systems engineering techniques to ensure delivery within acceptable parameters of cost, schedule and risk. The down side is that if the overall problem is divided incorrectly the small parts so obtained are as difficult to deliver as the overall programme. Moreover this approach assumes that such a division is possible.

What alternatives are there then? That is a difficult question to answer since this is really an embryonic and immature field. Historically the approach taken was to execute a small-scale pilot programme then scale this up to the size of the large programme, but that takes time and can cause loss of momentum. An alternative would be to take an evolutionary approach, similar to some agile approaches to software development: execute a solution with acknowledged flaws, and evolve this via a series of small iterations in to a solution that is ‘good enough’ to satisfy the key stakeholders of the programme.

Enterprise vs Solution Architecture

Following on from a previous blog, one of the things that I often see confused is the difference between enterprise and solution architecture. In particular I often see people confuse solution architecture with technical architecture, and enterprise architecture with solution architecture.

Wikipedia provides the following definition:

Enterprise architecture is a comprehensive framework used to manage and align an organisation's business processes, Information Technology (IT) software and hardware, local and wide area networks, people, operations and projects with the organisation's overall strategy.

I have highlighted some of the key elements of this definition. EA is about providing a framework that helps to align business processes, IT and people with the overall strategy of the organisation. This is typically captured by considering business process, applications, information and technology as independent views of the enterprise, and then mapping out how they will evolve over time (e.g. via the use of roadmaps, technical strategies and reference architectures). This can be depicted graphically:


Solution architecture is about delivering a project at a particular point in time. In the happy days scenario governance structures are in place to ensure that solution architectures are perfectly aligned with the enterprise architecture, so we can think of each solution architecture as being a ‘snapshot’ of the enterprise architecture at a particular point in time. Again we can model this graphically:



The reality is rarely as clean as the happy days scenario. Governance is more typically a mechanism for identifying divergence from the enterprise architecture, rather than a means of enforcing it, since delivery projects are normally under massive pressure to do the bare minimum to ensure delivery, rather than think of the longer-term implications of the choices made. Solution architectures are thus often misaligned with the EA at best; in some cases they are totally at odds with the EA. This is shown below:



More on governance in the future...

Business vs IT - Enterprise Architecture

I had the pleasure of attending a breakfast seminar this morning, organised by glue:. The subject of the seminar was "Managing IT Enabled Change". The theme was the idea of a common language to allow enterprise architects to talk to the business. The session was kicked off by glue:'s CEO Gareth Lloyd, who gave a very clear presentation of the context and in particular explained the need for a common language. After that Ceri Williams, also of glue:, provided some explanation of the meaning of a common language and how it fits in with EA, business strategy, business transformation and programme management. This was underpinned by Jes McPhee from Troux Technologies, who demonstrated how their tool can be used to support change analysis in support of business objectives. Finally Daren Ward, business architecture principal at Marks and Spencer, provided some real-world feedback on the use and applicability of business architecture.

While it was all very interesting and I enjoyed the presentations and the interchange of ideas, I had, and still have, a fundamental problem with the thesis presented. For me, enterprise architecture is precisely about ensuring that IT supports the overall business in achieving its goals. The glue: presentations, deliberately or unwittingly, talked about IT and 'the business' as though they were separate functions; in today's competitive environment it is not possible to get competitive advantage on any significant scale without having IT at the core of the business - 'the business' and IT should be indivisible.

That said, EA has largely been driven by the IT side of the world so there is still work to do in evangelizing the EA cause in organisations. And better tool support that talks about business problems and business issues, rather than servers and networks, is only to be welcomed.

The Resurrection of the Power Mac

For the last four years I have used a Power Mac G5 with dual 2.5GHz processors as my main machine at home. During this time the machine has been pretty much bullet-proof; it stays turned on most of the time (though in sleep mode when I am at work); the only time it has been switched off is when I have moved house! The one alteration I have made to it was to add an additional hard disk last year.

Last Tuesday without warning the machine stopped - it was not even a graceful shutdown. When I tried to restart it, though I could hear the fans spinning no video signal was generated. I tried the various boot options e.g. single user mode, boot from optical drive, none of which worked. Stumped I went to bed to think about it overnight. In the morning when I tried again, it booted first time. I put it into sleep mode and went to work. When I returned in the evening I started using and after 20 minutes or so it put itself into sleep mode. It repeated this several times until it just stopped again.

I decided to go back to basics so I disconnected all devices except the screen, keyboard and mouse, in case there was a hardware conflict causing the problem. That didn't help. At this point I was starting to get desperate, and concluded that there was probably a hardware fault on the machine. I therefore contacted a local company who are authorised for Apple service, and they suggested I bring the machine in and they could run some diagnostics for me. I couldn't do it until the weekend so I had a couple of days to try to resolve the issue myself.

As a vain attempt to do something useful I opened up the case and was greeted by several thick dust bunnies. There was nothing visibly wrong internally, but embarrassed at the thought of the service engineer seeing the amount of dust in the case, I put a brush nozzle on the end of our vacuum cleaner and sucked out all of the dust. When I looked more carefully I could see that the air ducts onto the CPU cooler (it is liquid cooled) were totally clogged up, so I used the vacuum cleaner to remove most of this dust. Feeling satisfied that I would not deliver a dust-filled machine to be repaired I put the case back together, and tried one last time to start it up.

Hey presto, it worked! That was 4 days ago, and I have not had a problem with it since then. The conclusion I have reached is that the CPUs were getting too hot which was causing the machine to shut down and then to refuse to start up until they had cooled down. I am guessing this is a feature built in to the chipset to prevent permanent damage. I have therefore installed Temperature Monitor so that I can avoid the problem in the future.

It gives a whole new meaning to the phrase "clean down the machine"!

Architects According to The Architecture Journal

I have been subscribing to Microsoft's Architecture Journal for over a year now. It drops into my letter box every two months and gives me something interesting to read on my train journey in to work. Normally (as one would expect) it is quite Microsoft-centric so it needs to be understood in that context, but nevertheless it can be interesting to understand how Microsoft technologies can be applied to problems, to understand best practices and to understand the emerging solution patterns around these technologies.

The latest issue (Journal 15) has the theme of "The Role of an Architect". Under this umbrella there are several articles that explore the nature of the architect role, and highlight some of the challenges involved in being an architect.

The first article is "We Don't Need No Architects" by Joseph Hofstader. It is an interesting article identifying the role to be played by architects in projects, and distinguishing the architect role from the role of developers. It makes a number of critical points about the skills that an architect needs such as the ability to think abstractly and conceptually, and the ability to understand and leverage patterns. However in my opinion it only answers a small part of the question; everything that the article states is quite true, but it only represents a small part of the architect's role.

The article does not distinguish between solution architect and enterprise architect, but implicitly it refers to solution architects. Within the solution architect role critical to success are the soft skills. For example:

• People - in anything other than the smallest organisation, a solution architect needs to work in a cooperative, consensual manner, ensuring buy-in for the solution architecture from all key stakeholders. Without this buy-in there can be no confidence that the solution as implemented will match the solution architecture.
• Politics - related to the previous point, there is an element of organisational politics that solution architects need to be aware of; I'm not suggesting that solution architects need to be Machiavellian and manipulative, but all organisations have politics and if a solution architecture is to be accepted by key stakeholders these political pressures and drivers need to be understood.
• Commercial - in principle commercial drivers should be captured as solution requirements that drive the solution architecture. The reality in my experience is that commercial drivers are never documented in that sense (and an organisation may not want to document such drivers) so a solution architect needs to be aware of these drivers when making architectural decisions. For example a difficult commercial relationship with a particular supplier might mean that an abstraction layer should be placed around that supplier's API to insulate the solution from a future change of supplier

So how much of the role is the IT architect role that Joe describes, and how much is soft skills? The answer depends very much on the size of the organisation and the size of the project; my own experience is that 80-90% is soft skills, but a very experienced enterprise architect I spoke to recently estimated 95%.

The Software Value Chain

I have read some interesting articles recently: "How Google Works" gives a fascinating overview of Google's pioneering approach to providing a high-performance service using commodity hardware. Similarly Amazon's Dynamo storage system provides an innovative approach to the problem of storing resilient persistent data without using an ACID database. What is striking in both cases is how industry norms are not just being ignored, but are being turned on their head. For many organisations the cost and risk of developing and maintaining a proprietary persistence layer would outweigh the performance benefits gained.

At first I thought that this was an issue of businesses whose core competence is not software choosing to effectively outsource these elements of their value chain e.g. by using a J2EE app server and an Oracle database. However thinking more about this there are lots of business who have a highly sophisticated approach to software who do not dare go against these industry norms. Why then do Google and Amazon innovate where others fear to tread? I see two reasons for this:

• By developing a custom infrastructure they maximise their competitive advantage since the infrastructure is tuned to precisely what the business needs, no more and no less. Amazon's Dynamo has been designed to exactly fit in with their business processes (e.g. a shopping cart) giving a performant and lean solution.
  
• The custom infrastructure is an enabler for business services through which they gain competitive advantage - how long would it take to serve up a standard Google query if the data was stored in an Oracle database?

Is this the way forward then? The reality is that most IT engineers are not as smart as those that designed Dynamo or worked out how to provide Google with a resilient infrastructure using commodity hardware. Standard platforms such as .Net and J2EE enable average engineers to deliver reliable solutions. Don't rush out to design a custom persistence layer just yet.

Airport Security and Scalability

Travelling through Heathrow terminal 4 in January I was interested to see that the shoe checking had been decoupled from the rest of the xray security i.e. there was an initial xray check followed in a separate area by a security examination of shoes.

This was an excellent example of a tiered architecture since presumably someone had done the analysis to show that bottlenecks in throughput were created by the shoe check. By separating out the shoe check it could be independently scaled (i.e. additional resources could be applied to the check) allowing overall greater throughput.

I was therefore bemused travelling through Heathrow's shiny new terminal 5 last week to see that the design had reverted to the monolithic single layer with integrated xray and shoe check. Yet another move forward for T5?

Build vs Buy Part 2

Following on from my previous post about build vs buy, I have thought about this a bit more. I have developed my own application to manage my bank account and credit cards over many years. It sucks data from my online banking service and online credit card statements, allowing me to reconcile transactions and plan our finances based on the bills we are expecting in the future. Recently I thought I would try a commercial package for this purpose, in order to save myself the effort of having to maintain my own code. However the package I bought required fundamental changes to my workflow which I wasn't prepared to make, so in the best traditions of IT projects I have abandoned the package and reverted to my home brewed solution!

Eee PC

I was lucky enough to be given an Eec PC last Christmas. It has taken me a while to get used to it, since its form factor is such that it isn't practical as a daily work tool. However it is so compact and lightweight that it is perfect for when I travel and I don't want to take a full size laptop with me. For example I take it to the tutorials for the MBA programme I am attending and use it to make notes which I can then quickly upload to my Powermac when I get home. Similarly I am typing this entry on said Eee PC from a hotel room in California where I am currently on holiday.

The Eee PC runs Xandros Linux, which is easy to use (that said I still prefer Ubuntu on my home server), though the shipped distro needs a bit of tweaking to get it to make the most of the hardware (I had to recompile the kernel with some additional settings). One drawback is that there are quite a few apps and config applets that aren't small form factor aware - this means that only part of the window is displayed and there are no scroll bars, so there is a certain amount of guessing about what some of the fields may say!

Apparently it is also possible to install Windows XP on the Eee PC, but the question is: why would you want to? :-)

Appliances

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 :-)

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.

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!

Zachman Lecture

I attended a two day seminar on the Zachman framework for Enterprise Architecture last week. I have read about Zachman before, and have even bought a book on the subject (which as an aside must be the work book ever written). However the seminar was presented by John Zachman himself so I thought it would be a good opportunity to get the message from the horse's mouth.

I was not disappointed; I have always thought of the Zachman framework as just being a means of classifying the various artefacts created during the development and maintenance of an enterprise's architecture. However John's compelling vision is that the Zachman framework is a schema for defining the primitive elements of enterprise architecture. He describes the framework as being the basis for enterprise physics, and draws an analogy with the periodic table. This analogy also allows him to justify the fact that not all of the models that comprise the cells in the framework have been articulated yet. Continuing the analogy, he argues that any architectural artefact needed will either be one of the primitive models in the framework, or a composition of these primitive models. By separating out the independent variables in the enterprise (represented by the columns, defined by interrogatives) the enterprise can support the flexibility needed in the information age.

One of the points made repeatedly during the two days was that in the absence of architecture models there are only three ways to support change:

1. Change by trial and error
2. Reverse engineer the models
3. Scrap the legacy solution and start again

Another interesting observation concerned the use of COTS; here the advice was to change the organization and/or business processes to fit the COTS package, and not vice-versa.

John's presentational style was very interesting; it was not a seminar in the sense of dialogue and discussion. It was more a high-powered intensive lecture, with a huge quantity of facts, knowledge and anecdotes delivered at breakneck speed.

All in all, it was an excellent lecture to attend. I left with a feeling that I need to change the way that I think about architecture, which is all I could really ask for.

Back in Britain

Having spent nearly six years abroad I returned to Britain in March of this year. Things have been a bit hectic but I have a few observations:

• Brits are obsessed with buying and selling houses; unlike anything else that you buy, house price growth is measured on a month by month basis. The press seems to think that anything other than rampant house price inflation is a sign of a weak economy.
• Being able to walk to a nice pub that sells decent beer is one of life's simplest pleasures.
• Bread is better in Denmark.
• Steak is better in Texas.

I will add other observations in the fullness of time...