Archive for February 2008
Yesterday, I heard someone use nimble as a synonym for agile. So I wondered what would have happened if the thing we know know as Agile had been called Nimble. Would it have made any practical difference? I find it hard to think that there could be conferences about Nimble and a body of Nimble literature, but maybe some people think that about Agile. Maybe there is already a Nimble movement who contemptuously refer to the Agile movement as splitters. Or maybe Nimble is a new trend about to start. Possibly to be followed by Spry.
Reading The Long Tail on the tube today, I got an insight into data classification. One of the aspects of information systems I struggle to understand is the exclusive use of hierarchical classification structures. In these structures, a particular thing can only be of one given type. Sometimes this may well be appropriate, but more often than not it isn’t.
Let’s take the example of film genres. A film, for instance, may be a comedy and a drama. In hierarchical structures, this film ends up being in a made up genre in which comedy drama is a child of comedy (and there is likely to be a genre of drama comedy as a child of drama.) Now, I can understand that you might want to classify your film in order to report against it – maybe all comedy is a specific department with costs and revenue. Fair enough. But why would you assume your users, especially those outside your organisation, would be happy or able to use your classification system – if you want to find something, it’d be more effective to classify this film as both comedy and drama. That’s trying to use the same data for two different ends, right?
Well, this is where the insight bit helped me. The physical world has some constraints that are not evident in computer systems – for instance, shelf space is limited. This means that in your local DVD rental store, that film is likely to be with the comedies or the dramas. They can’t reconfigure the shelving depending on how you’d like to search through their DVDs. So putting this together, I wonder if the reason that some people are wedded to their hierarchical structures is because these structures haven’t been a problem. Until now. There is some evidence in The Long Tail that without effective searching and filtering, we are intimidated by choice, whereas if the searching and filtering is effective we respond well to more choice and may even increase our spending. Now is the time, if you haven’t already done it, to think about how your users will navigate to the product they want. Because if you get that wrong, they’ll walk away.
I’ve always been impressed by the fact that you can leverage your .NET development skills to develop for Windows Mobile devices. I’ve tried out a few trivial examples, but this is an area I’d like to explore in more depth. So, I had to check out the the Windows Mobile Developer Center, which has been refreshed and renewed. Take a look. Isn’t the 4th box intriguing?
We’re all aware of mashups. Wikipedia defines a mashup as:
"a web application that combines data from more than one source into a single integrated tool"
For what it’s worth, I don’t agree that it has to be a web application – any kind of application will do; indeed some mashups that may be possible with client side application frameworks are going to be difficult if not impossible to achieve in a web application. If you want to get an idea of the range of mashups out there, look here.
Recently, I heard someone say that the measure of how poorly an IT department is aligned with the enterprise is to count the number of spreadsheets and user-maintained databases that are used to run the business. This statement rang true, and the rise of mashups is only going to increase the disparity between what is required and what IT delivers. Unless something changes. One possible change that has generated substantial thought and buzz is the rise of the enterprise mash up: the rapid, cost-effective delivery of applications that do exactly what a user or group of users needs. This delivery may even mean enabling the user to create their own applications. What is needed is a suite of services – which provide the data and associated logic along with all the *-ilities (*-ilities being my shorthand for scalability, reliability, etc.) required – and some tooling.
Personally, I’m not sure there is any difference between the idea of a composite application and a mashup – only that in my experience, composite applications have seemed to refer to apps inside an enterprise whereas mashups live on the Web. And when thinking about the services that are available, don’t restrict yourself to those offered by your enterprise. Have a look at this example of mashing up mapping data with Outlook.
In my post yesterday about Agile Architecture, I emphasised the role of standards. While I think that standards are crucial, I don’t believe that every system, service and application should necessarily implement the standard format for data representation – provided that whatever they do use can be translated to the standard. It may sound like more effort to have everything implement translators that translate from an internal representation to the standard format – aka the Canonical Data Model. However, taking this approach leads to greater agility since each individual system, application or service can evolve independently – any changes are local and contained unless they genuinely have a wider scope. If they do have a wider scope and the standard format needs revising, it is possible (and desirable) that translators will shield other systems from potential impact (do give some thought to versioning before you find yourself needing to revise your enterprise data format – I’d suggest you consider building in support for side by side versioning from day one and have a policy in place for deprecating old versions with adequate notice provided to affected parties.) What this all means is that you only have to change what needs to change. Which means that you can respond more quickly and effectively to change.
I’ve read my fair share of Agile literature and listened to the likes of Kent Beck and Mary Poppendieck. And like many others I’ve been impressed at a project level. At an architectural level, I’ve always had this nagging doubt that an agile process may not lead to an agile architecture. For the purposes of this post, an agile architecture is one that accommodates change easily. Before I go any further, let me say that the result of many years of non-agile processes has left many organisations with architectures that are anything but agile.
What has created the current architectures that aren’t agile? There’s a couple of possibilities. The first is a resistance to change. A waterfall process can lead to a false sense of stability and a rigid focus. In this environment, in which the customer is punished for changing their mind, the architect may be encouraged to focus on the project and resist change – just like the process resists change. The second is a lack of a joined up approach. If every project is delivered individually without overall coordination, chaos ensues. Systems will take different views of data, they may use different terminology and they may be built with divergent technology. In this unplanned world with no standards, architecture is accidental and agility is an unlikely happenstance.
The temptation, of course, is to overplan and overthink. We can identify the errors of the past as not having considered the whole and, thus, overcompensate by trying to accommodate every eventuality. But this way leads to inertia and madness. As Yogi Berra (might have) said, "It’s hard to make predictions, especially about the future." George Orwell wrote: "People can only foresee the future when it conincides with their wishes, and the most grossly obvious facts can be ignored when they are unwelcome." And in this thought we can see the error of those who think that the best way to predict the future is to invent it. For an architect, this aphorism is tempting but inverts responsibilities since it leads to the architect imposing future requirements upon the stakeholders.
So what’s the solution? Well, first off having a clearly communicated vision for the application, enterprise and, subsequently, architecture is a pretty good start. Secondly, knowing that change is inevitable means that the architect will realise that what is certain today may be questioned tomorrow and overturned the day after. Thirdly, you need standards and coordination across projects (my favourite metaphor for this is town planning – the town planners don’t know what the future holds but if they’re worth their salt they’ll plan in such a way as to accommodate change as best they can.) Of course, these standards themselves will need to change. This coordination of projects and standards implies a healthy governance process (think planning permission.) Finally, there needs to be a clear and concise statement of the principles underlying the architecture.
Here’s what some other people think about agile architecture:
What do you think?
April 28th and 29th will see this year’s Architect Insight Conference roll into town – the town in question being Windsor on this occasion.
To whet your appetite, take a look at the agenda here. It’s divided up into four themes this year: Enterprise Architecture, Infrastructure Architecture, Solution Architecture and Software plus Services. And in the Software + Services track, I’ll be speaking with Marc Holmes about the upcoming Oslo set of technologies. Hope to see you there.