I think one thing I shall try next time I'm sitting on the more comfortable side of an interview, will be to ask them to write a half a page answer to some pratical type question. One common denominator I've found amongst those who can talk the talk is that they frequently express their true ability in the written word.

Translated for me by Esther de Lange

Het volgende document is een uittreksel van een uiteenzetting over de architecturale benadering voor een niet-technisch leidinggevend publiek.

               

De technologie met betrekking tot computers, computergebruik en computerisering werd op de werkplek jarenlang gezien als het domein van de verspreiders van mysterieuze kennis die totaal afgescheiden waren van de “businesswereld” waarin alle anderen zich ophielden. Deze scheiding tussen de businesskant en de IT-kant werd soms door beide kanten nog eens extra versterkt. De business gaf IT de schuld als dingen verkeerd gingen en IT gaf ‘de gebruikers’ de schuld, omdat ze maar wat deden en niet wisten waar ze mee bezig waren.

 

De laatste jaren is er echter aanzienlijk veel moeite gedaan om deze scheiding niet alleen te overbruggen, maar om deze zelfs geheel te laten verdwijnen. Dit vanwege de eenvoudige reden:  IT en ‘de business’ zijn één en dezelfde. Tijdens het werk van alledag heeft men te maken met enorm ingewikkelde technologie, of het nou gaat om een PC met standaard bureaubladsoftware, een smartphone die constant gebruikt wordt voor het internet of een medisch apparaat als een MRI-scanner.  Technologie is gewoon een verzameling werktuigen die een organisatie in staat stelt bepaalde activiteiten uit te voeren.

 

Er is een nieuwe generatie opgegroeid en toegetreden tot de beroepsbevolking die net zo bekend is met de grondbeginselen van de technologie als vorige generaties waren met pen en papier.  Ze begrijpen de taal van muis en pictogrammen, ze navigeren instinctief door websites en toepassingen, en het allerbelangrijkste, ze begrijpen dat verandering constant en onontkoombaar is.

 

Deze verandering in de gebruikerscultuur die de afgelopen tien jaar heeft plaatsgevonden wordt gemakkelijk over het hoofd gezien, omdat we gewend zijn geraakt aan deze snelle verandering en er gemakkelijk in meegaan. Een andere grote verandering die gemakkelijk over het hoofd wordt gezien betreft de technologie zelf. Ook al heeft er geen fundamentele revolutie zoals de PC of het internet plaatsgevonden, cultuurveranderende revoluties van decennia geleden, de technologie heeft op een ietwat subtielere manier wel gezorgd voor een uitbreiding van de mogelijkheden. De afgelopen tien jaar is de manier waarop mensen met technologie omgaan enorm veranderd. Dit heeft te maken met de toegenomen computerisering en de daarmee gepaard gaande toename van het computergebruik, de toename van computervermogen, van het gebruik van mobiele apparaten, het internetgebruik en van de computersnelheid.  Zelfs degenen die in de informatietechnologie werken zijn zich vaak niet bewust van de omvang van de verandering die heeft plaatsgevonden. Door deze verandering, zijn de verwachtingen die mensen van technologie hebben ook veranderd.  Directe toegang tot informatie en diensten is de feitelijke standaard, vooral onder de nieuwe generatie binnen de beroepsbevolking.

Deze veranderingen binnen de technologie en haar symbiotische relatie met de cultuur, vormen een uitdaging voor alle organisaties. Over het algemeen bestaat deze uitdaging uit:

·         Externe eisen – de uitdaging om de vraag naar dienstverlening van klanten buiten de organisatie tegemoet te komen.

·         Interne eisen–de uitdaging om werkmethodes aan te passen en nieuwe mogelijkheden te benutten.

 

Veel, of misschien wel de meeste, organisaties hebben aanzienlijk veel problemen gehad met het omgaan met de veranderingen. Ten eerste, omdat alleen al de omvang van de verandering soms moeilijk te bevatten is. Ten tweede, doordat de investering die nodig is om gebruik te maken van de nieuwe technologie wordt beperkt door een gebrek aan financiering. Het resultaat is vaak een “als-het-niet-stuk-is-hoef-je-het-ook-niet-te-makenbenadering”.

 

Maar deze benadering ziet een fundamenteel aspect van door technologie gedreven verandering over het hoofd. Geen enkele boer zou een door een paard getrokken ploeg blijven gebruiken in plaats van een tractor, omdat ze beide werken, dus waarom zou je iets veranderen? De voordelen in productiviteit zijn immers overduidelijk. Geen enkele consument blijft zwart- wittelevisie kijken, enkel en alleen omdat zijn toestel het nog goed doet. Technologie maakt verandering mogelijk en daardoor soms onvermijdelijk.

De architecturale benadering: Voordelen van het zien van het grote geheel

               

Er is nog steeds behoorlijk veel discussie en verwarring, zelfs binnen de IT, over wat een architecturale benadering inhoudt. Alsof ze willen bewijzen dat ze net zo immuun zijn voor verandering als iedereen, beschouwen veel IT-ers van de oude garde, architecten gewoon als senior developers met een vervelende houding. De meeste enterprise architecten, daarentegen, zouden zeggen dat hun werk maar voor een klein deel uit IT bestaat en dat veel van hun werk juist op het businessvlak ligt.  Ze moeten naar het grotere geheel kijken, naar de organisatie als een verzameling mensen, processen en systemen die met elkaar in verbinding staan en deze onderlinge verbondenheid betekent dat er geen op zichzelf staande oplossingen zijn.

Ontwerpen voor klanten, niet voor de IT

 

Dus wat betekent de architecturale benadering nu in de praktijk? We kunnen een vergelijking maken met de rol van een traditionele architect. De klant zegt: “Bouw een huis voor me met drie slaapkamers en een keuken.”  De rol van de architect is dan om te begrijpen wat de klant nu precies wil – hoe groot moeten de slaapkamers zijn? Voor wie zijn ze bedoeld? Moeten ze een eigen badkamer hebben? Moet de keuken een woonkeuken worden of heeft men liever een aparte eetkamer? Er zijn heel veel vereisten die uitgewerkt moeten worden, voordat de architect en de klant het eens kunnen worden over een ontwerp. Het ontwerp wordt vervolgens overhandigd aan een bouwbedrijf en de architect blijft bij het project betrokken als vertegenwoordiger van de behoeften van de klant.

               

Dit is dan ook de essentie van de architecturale benadering – om de scheiding tussen klant en bouwer te laten verdwijnen, tussen ‘business’ en IT.

 

Net zoals een traditionele architect werkt binnen een kader van technische kennis – de fysieke eigenschappen van verschillende materialen, het in acht nemen van veiligheidsvoorschriften, enz. – doet de enterprise architect dat ook.  Door de technologische mogelijkheden te begrijpen en uit te leggen aan de klant, biedt de architect de klant de mogelijkheid om betrokken te zijn bij het proces van ontwerp en ontwikkeling.

Oude en nieuwe modellen vergelijken

 

Wanneer nu een programma wordt gelanceerd over de gehele organisatie van een onderneming of over een groep organisaties, zullen er veel verschillende partijen zijn die allemaal verschillende dingen willen. Centraal binnen de benadering staat dan ook; begrijpen hoe men binnen één overkoepelende architectuur tegemoet kan komen aan de eisen van verschillende klanten. Dit is waar het begrip ‘hergebruik’ volledig tot zijn recht komt.  Verschillende onderdelen van een onderneming zullen altijd verschillende vereisten hebben, maar omdat ze allemaal passen binnen het grotere geheel van organisatorische activiteiten, zal er onvermijdelijk een overlapping zijn tussen vereisten voor verschillende projecten. De architectuur creëert bouwstenen door de onderdelen waaruit de verschillende projecten zijn opgebouwd van elkaar te scheiden. Dit zijn herbruikbare componenten waarmee opnieuw iets gebouwd kan worden.

 

Hier wordt duidelijk wat het grote voordeel is van de architecturale benadering ten opzichte van oudere methodes. Het traditionele IT-model was:  één oplossing voor één groep vereisten. Dus het plaatje zag er ongeveer zo uit:

·         Eén afdeling heeft een aantal vereisten. Hier wordt aan tegemoet gekomen met één op zichzelf staande oplossing.

·         Een tweede afdeling heeft een ander aantal vereisten.  Men komt met een andere op zichzelf staande oplossing.

·         Een derde afdeling heeft data nodig van de eerste twee afdelingen om te gebruiken voor weer een ander aantal vereisten. Weer wordt een op zichzelf staande oplossing geleverd en de benodigde data worden handmatig verkregen uit de eerste twee systemen.

 

Iedere keer als een afdeling met een nieuw stel vereisten kwam, werd er een nieuw systeem gebouwd met eigen ondersteuning en gebruikersgroepen.  Iedere keer als er data van het ene naar het andere systeem overgezet moesten worden of als er data uit twee verschillende systemen samengevoegd moesten worden, voerden handmatige processen en werkbladen hoogtij.

 

Iedere keer als er een verandering nodig was, hielden de makers van de verschillende systemen zich bezig met het bewerkstelligen van deze verandering en dit werd het businessmodel voor veel softwareproducenten. Ze maken ieder onderdeeltje van hun systeem specifiek voor iedere afzonderlijke locatie op maat en binden hun klanten aan zich met doorlopende ontwikkelings- en onderhoudscontracten, waarbij veel van de op maat gemaakte systemen continu worden aangepast. De softwarebedrijven kunnen de tarieven vervolgens zo hoog maken als ze willen, vanwege hun monopolie en omdat de klanten afhankelijk van hen zijn. Tarieven van zo’n 1700 euro per dag zijn niet ongewoon. Dit zeer voordelige businessmodel voor IT-verkopers betekent ook een hoge Total Cost of Ownership (TCO) voor hun klanten (zie hieronder).

 

En heel belangrijk, deze benadering betekent ook een zeer intensief gebruik van human resources. Degenen die het systeem bedienen en de IT-ondersteuning moeten apart worden opgeleid voor elk individueel systeem met elk zijn eigen hebbelijkheden.  Handmatige processen hebben meer mensen nodig voor het maken en bijhouden van werkbladen. En terwijl de kosten voor het upgraden of het vervangen van een onmisbaar systeem voor het bedrijf stijgen, raakt de op zichzelf staande oplossing steeds meer verouderd en kost het steeds meer moeite om deze in stand te houden.

 

De architecturale benadering daarentegen, legt de nadruk op standaardisering en hergebruik en ziet er ongeveer zo uit:

 

·         Eén afdeling heeft een aantal vereisten. De architect kijkt hoe deze vereisten passen binnen het gehele bedrijf. De geleverde oplossing is ontworpen met een gestandaardiseerde functionaliteit en klaar om geïntegreerd te worden met andere systemen.

·         Een tweede afdeling heeft een ander aantal vereisten.  De eerste oplossing kan worden uitgebreid om tegemoet te komen aan de nieuwe vereisten.

·         Een derde afdeling heeft data nodig van de eerste twee afdelingen om te gebruiken voor weer een ander aantal vereisten. Een nieuwe groep functionaliteiten wordt geleverd. Databeheer wordt toegevoegd om er zeker van te zijn dat er ‘één enkele bron van waarheid’ is.

 

Het uitgangspunt is om waar mogelijk uit te breiden en te hergebruiken.  Tegemoet komen aan de vereisten is een kwestie van het leveren van een dienst, en deze dienst kan worden aangepast en veranderd, wanneer de situatie verandert door nieuwe mensen aan het stuur. Daarom heet dit Service Oriented Architecture (SOA). Data worden van elkaar gescheiden en snel uitgewisseld tussen systemen, waarbij men altijd zeker is van een bron van master data die men kan handhaven als de enige bron van waarheid.

 

Veranderingen vinden dan plaats op één plek. Standaardisatie betekent dat ontwikkelingen op zo’n manier plaatsvinden, dat ze zowel door developers als gebruikers meteen worden begrepen. De strategie van Shared Information Services is om algemene technologieën te gebruiken, waardoor wordt gegarandeerd dat men voor ontwikkeling gebruik kan maken van vaardigheden die overal beschikbaar zijn; contractanten kunnen gemakkelijk worden gevonden en interne mankracht kan worden opgeleid. En, heel belangrijk, de afhankelijkheid van (vaak kleine) dure leveranciers verdwijnt.

 

De architecturale benadering vereist in eerste instantie dus wat meer tijd en inspanning, maar door naar het grote geheel te kijken wordt er uiteindelijk bespaard. Doordat de technologie standaard is en de toepassingen allemaal op dezelfde manier werken, kunnen mensen het systeem voor verschillende domeinen gebruiken en in stand houden. Zonder de handmatige inspanning om data tussen verschillende systemen uit te wisselen, is er minder mankracht nodig.

Het eindresultaat is dat de kosten om systemen te ontwikkelen, te leveren en te onderhouden veel minder worden. Een lagere Total Cost of Ownership compenseert ruimschoots de kapitaalinvesteringen die in eerste instantie moeten worden gedaan.  

 

 

The following document is excerpted from a paper explaining the architectural approach to a non-technical executive audience.

                For many years computing technology in the workplace was seen as the preserve of the peddlers   of arcane knowledge, removed and separate from the world of “business” that everyone else inhabited. This was a separation  that was sometimes actively reinforced on both sides of ‘the business’/IT divide. ‘The business’ blamed IT when things went wrong and IT blamed ‘the users’ for not knowing what they were doing.

But in recent years substantial effort has been made to  not only bridge that separation but to erode it altogether. There is a simple reason for this: IT and ‘the business’ are one and the same. Everyday work entails massively complex technology, whether it be a PC with standard desktop software, a smartphone constantly chattering on the internet or a piece of kit like an MRI.  Technology is just a collection of tools enabling an organisation to undertake a set of activities.

Generations have grown up and entered the workforce who are as familiar with the basics of the technology as a previous generation was with pen and paper.  They understand the language of mouse and icons, they instinctively navigate websites and applications, and most crucially of all, they understand that change is constant and inevitable.

This change in the culture of users over the previous decade is easily overlooked, as we have become accepting of and inured to this rapid change. Equally overlooked is another great change: technology itself. Whilst there has been no fundamental revolution such as the personal computer or the internet, culture changing revolutions of the previous decades, there has nonetheless been a subtler expansions of possibilities enabled by technology. In the previous decade, advances in computing power, mobile device proliferation and internet usage and speeds have massively changed the ways that people interact with technology.  Even those who work in Information Technology often don’t recognise the scale of the change which has happened. As it has happened, people’s  expectations of technology have changed.  Instant access to information and services is the de facto standard, particularly for the generations that form the bulk of trainees.

These changes in technology and its symbiotic relationship with the culture have posed challenges for all organisations. Broadly put, these challenges can be described two ways:

•             External demands – the challenge to meet the service demands of customers outside the organisation

•             Internal demands – the challenge to adapt ways of working and grasp new opportunities

Many, if not most, organisations have had substantial problems embracing these changes. Firstly, because the sheer scale of the change is sometimes hard to grasp. Secondly, because a shortage of financing has restricted investment needed to utilise the new technology. As a result, the tendency has often been to take an “if it’s not broke, don’t fix it” approach.

This approach though misses a fundamental aspect of technologically driven change. No farmer would propose using a horse drawn plough in place of a tractor as both work, so why fix it, because the productivity advantages are obvious. No consumer keeps watching black and white television simply because their set still works. Technology enables change and through the act of enabling it sometimes makes change unavoidable.

The Architectural Approach:  Benefits of seeing the Big Picture

                There is in fact still considerable debate and confusion even within IT what an architectural approach entails. As if to prove that they are equally resistant to change as anyone else, many ‘old school’ IT people view architects as simply senior developers with bad attitudes. Most Enterprise Architects on the other hand would say that their work has only a limited IT component and much of the practice is business facing. It involves looking at the big picture, at the organisation as a set of interconnected people, processes and systems. A and this interconnectedness means that there are no stand-alone solutions. 

Designing for customers not IT

So what does the architectural approach practically involve? An analogy can be drawn with the role of a traditional architect. The customer says ‘Build me a house with 3 bedrooms and a kitchen’.  An architect’s role then is to understand what the customer wants in more detail – how big should the bedrooms be? Who are they intended for? Should they be en suite? Should the kitchen be separate from a dining room or will it also be a dining space? There are many requirements to detail before the architect can agree a design with the customer. The design will then be handed over to the builders and the architect remains engaged to represent the needs of the customer.

                This then is the crux of the architectural approach – to disappear that divide between customer and builder, between ‘the business’ and IT.

Just as a building architect operates within a framework of technical knowledge – the physical properties of different materials, the legal compliance of safety regulations, etc… - so too does the enterprise architect.  Understanding what is technically feasible and explaining the opportunities offered by technology, the architect should empower the customer to be engaged with the process of design and development.

Comparing Old and New Models

When delivering a programme across an enterprise organisation, or a group of organisations, there will be many different parties wanting many different things. Understanding how the requirements of different customers can be met within one overarching architecture is central to the approach, because it is here that the concept of reuse comes into its own.  Different parts of the business will always have different requirements, but because they all fit within the wider set of organisational activities, there is inevitably crossover between requirements for different projects. By breaking the different projects into their constituent parts, architecture creates building blocks. These are reusable components with which to build anew.

This is where the great advantage of the architectural approach over previous methods becomes clear. Traditionally, the IT model was: one solution for one requirement. So the picture evolved something like this:

•             One department has one set of requirements. These are met with a stand-alone solution.

•             A second department has another set of requirements .  Another stand-alone solution is provided.

•             A third department needs data from the first two departments to use for a new set of requirements. Another stand-alone solution is provided and data is extracted from the first two systems manually.

Every time a department came along with a new set of requirements came along, a new system was built, with separate support and separate user groups.  Each time data needed to be moved from one system to the other, or data was needed to be aggregated from two different systems, manual processes and worksheets proliferated.

Every time a change was needed, the suppliers of the different systems were engaged to develop the change, and this became the business model for many software suppliers. They customise each implemented instance of their system in each separate location and tied their customers into on-going development and maintenance contracts, constantly tweaking a multitude of tailored systems. Because of their monopoly and the dependency of their customers, software companies can then charge whatever rates they wish. Day rates of £1500 are not unusual. This highly profitable business model for IT vendors also entails a high Total Cost of Ownership (TCO) for their customers (see below).

Crucially, this approach is also very resource intensive. Operators and IT support need to be separately trained for each individual system, each with its own individual quirks. Manual processes require more people to build and maintain worksheets. And as the cost of upgrading or replacing a business critical system escalates, so the stand-alone solution becomes more outdated and needs more and more effort to maintain.

In contrast, the architectural approach emphasises standardisation and reusability and would look something like this:

•             One department has one set of requirements. The architect looks at how these requirements fit within the overall business. The provided solution is designed with standardised functionality and ready to integrate with other systems.

•             A second department has another set of departments.  The first solution can be extended to meet the new requirements.

•             A third department needs data from the first two departments to use for a new set of requirements. A new set of functionalities  is provided. Data management is put in place to ensure there is a ‘single source of the truth’.

Here, the principles are to extend and reuse where possible.  Meeting requirements is a question of providing a service, and these services can be adapted and changed as new drivers alter the situation. Hence, this is referred to as Service Oriented Architecture (SOA). Data is separated out but is readily exchanged between systems, always ensuring that there is a master data source which can be maintained as the single source of truth.

Changes then are made in one place. Standardisation means that developments are done in ways which are readily understood by developers and business users alike. The Shared Information Services strategy has been to use common technologies, which ensures that development is done with widely available skillsets; contractors can be readily found and internal resources can be trained. And crucially, the dependency on (often small) costly suppliers is removed.

So the architectural approach can demand somewhat more time and effort upfront, but the savings are made by seeing the big picture. Because the technology is standard and the applications all work in the same way, people can use and support the system across different areas. Without the manual effort to exchange data between different systems, the user base is lower.

The upshot is less cost to develop, deliver, maintain and use the systems. A lower Total Cost of Ownership dramatically offsets any initial equivalence in Capital Expenditure.

I don’t normally like to write much here when I’m with a client, as it’s often easy to associate my current thinking with the specifics of a client’s program.  But there’s one commonality that crosses all projects: project managers.

As an architect, you get to work very closely with project managers.  I’ve had the fortune to work with some highly competent ones, and the misfortune to work with some absolutely hopeless examples.  Some have made self-promotion into their true project, while others have neglected themselves while trying desperately to make their project a success.

On one project we even figured out the collective noun for project managers: an infestation.  Because that company’s response to a failing project was to throw more PMs at it; a response akin to trying to salvage a sinking ship by throwing ballast at it.

One situation I’ve noticed working in the public sector recently, is that project managers are given ownership of projects in a way that doesn’t happen the same in the commercial world. The business and the executives, who should be the true owners of a project, appear to delegate to the PM. This has led to situations where I as an architect am reporting into a project manager, even though I’m the one primarily defining the workstreams and the deliverables.  

This sometimes leads to conflict between architects and project managers.  We sometimes treat PMs as glorified secretaries (even in those situations where theoretically they’re my manager!). On the other foot, a common putdown PM use is that architects are only concerned with technology, a piece of political invidiousness which misrepresents my work and prevents the necessary communication with the real business owners.

When you get to work with a PM who knows their job (and isn’t trying to do mine and make me do theirs) then it can be a real pleasure. A simplistic way of looking at it is that I’m good at knowing what needs doing and they’re good at getting things done.  The analogy with my earlier career would be the relationship between a director and a producer: when the relationship’s good, great things can get done.  When it’s bad, you get an Alan Smithee film.

And one last swipe. It’s the director who is the primary creative force and the one whose name we remember, but when the Oscar for Best Film is given out, it’s the producer who steps up to claim it. Bloody typical project manager!

Been a  little quiet on here lately. The current project has been in that stage of delving into business-specifics, which obviously I'm not going to share on here. Now, starting to come up for air again. I did put together these four principles for starting a BI/MI project, which I thought were a quite reasonable set to begin with.

·         Baseline the current reporting set

Creating an initial baseline refers not only to an inventory of data sources, but of an overarching view of the current state and perception of MI and BI. In a legacy environment, much of the process of enrichment which transforms data into information resides within the heads of individuals and the manual processes that are often deeply embedded. This cannot be easily captured in a simple matrix. 

·         Capture current problems

All legacy reporting processes have issues with data integrity, manual steps, workarounds, poor performance, etc… If not addressed, these will be populated through into the new solution. On the other hand, if they are addressed, this issue resolution encourages buy-in of the key user group.

·         Anticipate changes

The introduction of a new MI/BI platform will open the user group up to new possibilities in terms of reporting, which inevitably bring new requirements. The confluence of introducing such a platform in a rapidly changing organisational environment, greatly increases the likelihood of new requirements. These may be of such scope as to entail structural change in the solution. Anticipating these changes in the design stage is up-front work which will pay back manyfold on implementation.

·         Understand duration

Time is the most complex data source in a reporting platform but it is the most often overlooked.  Time plays a role within periodic reporting, within the organisational calendar (which is often distinct from the calendar everyone else uses), in scheduling, alerting, and in the way it impacts when changes in sources or requirements affect the database.

I was very impressed when I first read the Agile Manifesto. Strange to think that was just over a decade ago and already the world and his dog say they use Agile to deliver projects. But do they really?
First a disclaimer. Software delivery methodology is not strictly speaking of high importance to an EA; Agile has specifically emerged from software development. But I've managed development and delivery teams often enough, and as is usually the case, when you can do something you find yourself being asked to do it more often. Especially when the management of development isn't competent, the architect can be a ready-made replacement standing in the wings.

So Agile is primarily by and for coders. The principles describe how to best deliver quality software that actually does what the organisation requires. Simply put: "better ways of developing software". But what I notice more and more are businesses which say they're using agile methodologies and I'll get asked about how I use agile in my work. At best, many of these businesses are simply paying lip service to a trend. Others though are using an inflexible interpretation of methodology - often called scrum, though not necessarily true! - to actually introduce a new level of management overhead. The result is the very opposite of what agile intends: developers are lost in meaningless bureaucracy, the quicksand of more management directives.
I believe the purpose of many of these Agile-In-Name-Only methodologies is to try and achieve some management oversight into what coders are doing with their time. Because coders by nature have very little patience with management interference and rarely see the point of making progress reports to a line manager or PM who barely understands what they're up to anyway. But the daily scrum meeting or the need to produce something visible at the end of a two week sprint is perfect for giving the half-competent manager the illusion of oversight. In practice, the result of these impositions of a structure which is at odds with the Agile principles, is wasted time, disgruntled coders and the prioritisation of methodology over delivery. The end result will naturally be lower quality deliverables.

Coders think that if the manager really wanted to know what progress was happening, they'd know already. And I tend to agree. During the development lifecycle there are countless decisions which need making. Some are relatively minor, some are absolutely critical, and a good decision maker should know which is which. If the coder has no-one to discuss options with and if need be make the call one way or the other, then they'll rightly feel that their work isn't properly valued by the organisation. The development manager should be fully engaged with the coding process, but also with the business,and should be promoting the continual interaction between the two. Or, as one of the Agile Principles succinctly puts it: "Business people and developers must work together daily throughout the project."

The next time I'm asked then how I apply Agile methodology in my work, I'll explain that the structure I apply isn't a mandated methodology or a formalised set of meetings. It has to emerge from the team of people - coders and end users and stakeholders - from their personalities and skillsets and schedules. I'm a big fan of the concept of emergent properties and this applies as well to teams of people as it does to any other system. As another of the Agile principles puts it:

"The best architectures, requirements, and designs emerge from self-organizing teams."

Spot on. And don't even get me started on pigs and chickens..... 

I ran a load of updates to Windows yesterday. Two BSODs later it struggled into life, but now seems to hang every time I hit YouTube in Firefox. (Is this actually not an issue?)
Unfortunately, this takes me back 15 years, to when Windows would be up and down faster than a whore's drawers. At that time, Microsoft had a well-deserved reputation of releasing shoddy software before it was truly ready, just in order to keep ahead of the market. Over the last decade, there's been a big improvement - although many of my mates who migrated to Linux long ago have never looked back. But the main improvements have been in the business software (e.g. SQL Server, SharePoint and BizTalk are all massively improved over what was around 10 years back). I can't help wondering, after that old familiar blue screen, whether there's still not sufficient attention paid to the desktop OS, whether consumers are being taken for granted, or whether there's just something flawed at the very heart of the Windows architecture and its reliance on integration with explorer?

Back from holiday and now it's seriously time to find a new project. Wouldn't it be great to find that smart, innovative project that has proper backing and understanding right up the tree?

What a difference it is packing for a holiday now. 2DVD players, smart phones, iPad, laptop, MP3 players, 3 Nintendo DSi's, 4 cameras, etc... And we're going camping!

I'm thinking a lot lately about content and the way we receive (or deliver) it. I still think the analogy of us being in the equivalent of the silent film era - i.e. that we have a great new technology but it's got along way yet to develop - stands up fairly well. We're not at the stage of making one or two reel shorts anymore, as we were back in the early days (and I was putting near real-time video online back in '97); we're more at that stage of sophisticated art of pantomime that saw some great silent movies like 'The Crowd' or 'Napoleon'.
But there's a couple of parts where the analogy doesn't hold up. In 1920, the coming of sound and colour were widely predicted, but our predictions about new technological innovations have been less, well, predictable. Back in '97 we talked a lot about the convergence of platforms - remember web TV? Well these days it seems to be more a question of divergence - we have desktops and laptops and tablets and e-readers and phones - and not only do different device users have different requirements, but the same customer might want one type of content for one device, but another type for a different device. I really like my Dune Max, but I don't want to Facebook on it, even though I can now. I like reading newspapers on my laptop and graphic novels on my tablet, but sometimes I want to get away from all the screens and enjoy old-fashioned treeware.
So it's going to be a question horses for courses. But there's also another elephant in the room: investment in content, rather than the medium. Sure, converting all those movie palaces to sounds back in 1929 cost a fortune, as it has done getting the cineplexes 3D-ready in 2010. There's little in the way of impressive investment in the production of original digital content though, other than the traditional website or online games. I'm really curious to see when we get the first, original cross-media fictional content - part story, part game, part movie, who knows? - gathering a hundred million customers around the world.
Until then we seem to have skipped way forward in my analogy, and have arrived at reality TV. The medium defines the content and the message in some cases is only 140 characters...