Jim Phelps from Wisconsin is kicking off the workshop by talking about the ITANA group, which had its first f2f meeting yesterday. Over 20 people attended that meeting, where many people said that there was a lot of discussion about what IT architecture actually is and who is an architect (Jim characterized the discussion as “navel gazing”).
Now we’ve got a panel representing different practices in IT architecture and governance at different institutions. Bruce Vincent from Stanford notes that we have quite a range of practices reflecting the structures and cultures of different institutions. The panel includes Tom Barton from U Chicago and our very own RL Bob Morgan in addition to Bruce and Jim.
Bruce says IT architects are working as influence peddlers – that’s in a discussion of governance. Most at ITANA agreed that influence is more practical than formal governance. Influencing architecture early is critical – bringing it in late (like an architecture review board) dooms it to failure.
Tom notes that Chicago is not big on process, and they’re not sure what architectural process is. But it should result in simpler more sustainable services, and a more common infrastructure. To do that some of the challenges are that people aren’t connected enough to be aware of or comfortable with leveraging other people’s work. At Chicago they’ve done several things to try to move this. One is that they’ve started having meetings of the chief technical people in each of the directorates. It’s been good contact, but hasn’t resulted in tangible outcomes. The enterprise architect has been involved with purchasing of new software for the institution, to do some vetting of security and integration in new packages – result is they’re not shooting themselves in the foot quite as much. They recently formed an architecture group, which includes senior decision makers and senior tech people – 12-14 people. Aim to get buy-in and resource commitment. The idea is to make “more harmonious” decisions – e.g. what kinds of operating systems can be run in the data center. Engaging in a virtualization strategy using that group.
How services get advertised and shared is a problem. The “IT Ecosystem” is a web database that is designed to help people know who to talk to and characterize the mess.
RL Bob starts off by saying that he’s here to represent the incoherent view, which both he and his institution are well suited for. One of the roles of the architect is to get everyone else to think like an architect, to think about the long-term, sustainability, etc. We don’t have a single person respsonsable for architecture or an architecture office. Bob describes the attempt at UW to have an Architecture group, which tried to list architectural principles, which ended up not being entirely successful. Much architecture ends up working as advice and engagement in specific projects, which might imply roving bands of architects engaging in lots of projects. But not all projects take advantage of seeking out architectural advising (nor would that scale too far). The development of the product and service lifecycle has been more successful, and while it’s not specifically about architecture, it at least has touch points where architecture can be considered.
Bruce talks about Portfolio Management – architects are asked to give an idea of relevant amount of investment and how long it will last – there’s relatively little in the way of formal structure for this. At Stanford they have a body called the Systems Governance Group, which controls project money in large. Annually large projects have to come and “defend their right to exist”. There’s also a faculty subcommittee on computing that they’ve used successfully to gauge faculty support for efforts. Stanford has a Technology Architecture and Strategy Council, which has practitioners who are the lead technologists in various areas and have to “put up or shut up” on strategic direction and think about how their areas integrate and overlap with each other.
It strikes me that this conversation really represents a classic industrial style of “architecture” as a controlling system that can prescriptively decide what’s correct at an institutional level. I tend to think of a post-modern concept of architect as a bricoleur (see quote below), working in more of an ad-hoc manner to build structures that use the materials at hand to respond to ever-changing needs.
In response to a question I asked about whether any of these architecture review boards include people from outside the central IT groups, Paul Hill noted that MIT’s architecture review board has included people from across the institution that have reviewed projects on a regular basis, but that recently the non-central-IT folks requested that the central organization do the detailed reviews and report back to the whole group instead of having everyone involved.
The ‘bricoleur’ is adept at performing a large number of diverse tasks; but, unlike the engineer, he does not subordinate each of them to the availability of raw materials and tools conceived and procured for the purpose of the project. His universe of instruments is closed and the rules of his game are always to make do with ‘whatever is at hand’, that is to say with a set of tools and materials which is always finite and is also heterogeneous because what it contains bears no relation to the current project, or indeed to any particular project, but is the contingent result of all the occasions there have been to renew or enrich the stock or to maintain it with the remains of previous constructions or destructions. The set of the ‘bricoleur’s’ means cannot therefore be defined in terms of a project (which would presuppose besides, that, as in the case of the engineer, there were, at least in theory, as many sets of tools and materials or ‘instrumental sets’, as there are different kinds of projects). It is to be defined only by its potential use or, putting this another way and in the language of the ‘bricoleur’ himself, because the elements are collected or retained on the principle that ‘they may always come in handy’. Such elements are specialized up to a point, sufficiently for the ‘bricoleur’ not to need the equipment and knowledge of all trades and professions, but not enough for each of them to have only one definite and determinate use. They each represent a set of actual and possible relations; they are ‘operators’ but they can be used for any operations of the same type.
Technorati Tags: architecture, IT-architecture, CSG, CSG-Spring-2007
Oren Sreebny 