I chose, largely, to follow the lifecycle track – and, a note to Microsoft, seven concurrent tracks is too many. Almost by definition architects have broad interests and I imagine most attendees found several sessions interesting in any particular slot.
Microsoft's Lifecycle centres on its VSTS (Visual Studio Team System) tools, of course, although "software factories" also feature – see later. VSTS seems to be built around a genuine rethinking of the development process in order to deliver more transparancy (through "friction-free metrics" - the tools deliver metrics without getting in the way of the developers), team collaboration, and better QA.
There was also mention of "blind spot metrics" to highlight overlooked issues (such as a module with impressive test results and coverage metrics, perhaps; but which also suffers from massive code churn – possibly you're just measuring the implications of a skimpy and inadequate test pack).
VSTS is certainly a radical upgrade for the Microsoft development tooolset, although I'm not sure that it could entice me away from other, more established, vendors (such as Telelogic or Borland), if I already had an effectively automated lifecycle development process. In fact, perhaps there are serious migration issues for anybody not already developing on the Microsoft platform as, although VSTS emphasises its extensibility and customisability, it is firmly based in Microsoft technology – Team Foundation Server – for its version and configuration management.
I'm possibly being a tad unfair here, but buying configuration management from the firm that sold VSS (Visual Source Safe [that link isn't necessarily Reg-endorsed, BTW – Ed]) as an SCM solution rather worries me.
His enthusiasm for the product was palpable but he also discussed the dangers of customising a powerful tool without due process and maturity (it's not the tool's fault, but you could make it as over-precriptive and restricting as some early CASE tools, if you wanted to). Phillips also gave an endorsement to Borland's CaliberRM, which intregrates with VSTS to add Requirements Management (an essential part of the lifecycle, in my opinion, that VSTS doesn't really deal with out of the box).
Oh, and the complexity of VSTS licencing still seems to be a real issue (see Tim Anderson's comments here. Attendees didn't seem impressed by the book which is supposed to explain it all. Some of them also seemed to be getting conflicting information from their Microsoft contacts on exactly what they could do with their reports from VSTS without buying extra licences, which isn't a good sign.
Ivar Jacobson was brought along to add independent gravitas to Microsoft's lifecycle approach with the Essential Unified Process (Ess UP). I must say I was a little disappointed by this. Yes, the Unified Process has sort-of been hijacked by IBM (although, to my mind, the Eclipse EPF process framework project mitigates this issue) and is a bit daunting; but the idea of a "unified" process behind development generally is probably unavoidably hard when you get down to the practical nitty gritty.
Ess UP's big idea of customising process to particular developments is good (but it has been tried before – see Trireme's Catalysis for example – and only a few of the more mature developers can be bothered). But, Jacobson's approach, of putting its components on glossy cards with explanatory documentation and playing them on a board in a development "game", seems more cosmetic than useful, to me.
Yes, it is based on previous approaches that have worked (see Scott Ambler here and it makes process more accessible; but people who need it this accessible probably won't cope with it anyway. But perhaps I'm being unfair again. According to Jacobson: "The card metaphor makes the process itself lightweight, agile and easy to use." You can check this out for yourselves here.
The presentations on Software Factories by Jack Greenfield and others were interesting, but some of the admitted limitations of their current implementation are rather serious:
- Customisation isn't easy.
- There's no logical overview of the application being developed.
- It's hard to tell what to do and when to do it.
- There are too many wizards.
- It's hard to revisit past decisions.
- It isn't optimised for team development.
I'm also a little worried that the Software Factory approach will, in practice, encourage developers to produce code faster without examining the abstractions behind the system they're automating – from my misspent youth in structured design, business users don't always fully understand their own business process and trying to "automate the current physical" is fraught with danger.
Nevertheless, Software Factories seem to be a significantly innovative approach to development and their next iteration (which I can't talk about just now, because all attendees were put under NDA) may well address many of the issues. And, of course, access to Microsoft future thinking, even under NDA, must be a plus for conference attendees.
The final focus group revisited the question of what an IT "architect" actually is. The consensus seemed to be that there were different kinds of IT architect but that they were generally experienced technologists with an understanding of the business – and the title was often more a matter of recognition of someone in the IT group already doing the job rather than the result of any specific training.
That's a bit worrying to me, as I suspect that an experienced business person would find it easier to pick up the principles of IT than vice versa and they might have a broader view of architecture, going rather beyond the limits of today's automated systems.
As I said in my last postcard, I tend to see an IT architect, in practice, as just a specially well paid (and experienced) systems analyst (thinking of "systems" in the "Systems Theory" sense, perhaps).
Certainly, ego seems to be a qualification – I'm sure some of the attendees saw their architect title as a reward for being Truly Wonderful. And, there was an interesting comment dropped by Martin Fowler at the QCon conference this week: "We sometimes have trouble with the term architect at Thoughtworks, mainly because of some of the people we meet calling themselves architects."
But I'm beginning to think that there really is a special architect role, requiring skills beyond those of a top analyst with both technical and business experience. For a start, an architect should be responsible for the practical success of the business deployment – one architect told me that he wrote and signed contracts (analysts generally don't do that).
And, secondly, architects are (or soon will be, the way regulations are moving) accountable for the architectural quality of their projects. If the new widget system gets as far as going live and proves "unfit for purpose" perhaps it's the architect's fault (just as it might be if a new school didn't have a toilet block) and the architect responsible may get "disbarred" - or sued.
That last one didn't seem to go down well with some people in the focus group – I was reminded of a seminar for aspiring non-exec directors at the IoD when the assembled non-execs were told that they might be personally (financially) responsible for bad governance in the firms they were directors of - and might actually have to earn their fees. However, there is liability insurance – get it now while you can still afford it <grin>.
Overall, then, an interesting conference and a lot to take in. Software factories, in particular, might be a real breakthrough – although the current Microsoft implementation isn't there yet and I can't talk about its next iteration because of that NDA. Just as well really, as vapourware is always impressively free of interesting issues to talk about – I've commissioned Tim Anderson (also attending this conference) to look into what is actually available in this area.
However, I was left with the impression that Microsoft is growing up – and finding the harsh realities of enterprise computing a little daunting. Its old approach, that everything difficult can be made simple by merely adding a Wizard (or two, or a dozen) may be running out of steam. Or, at least, becoming "wizard-heavy".
Microsoft certainly has the brains, talent and enthusiasm for the job, but enterprise scale delivery of automated systems that align well with changing business requirements and can be deployed globally for large communities might just be a very hard problem. It may not be possible to make it as easy as building a little utility in VB and Microsoft may have to come to terms with that. ®