Thursday, February 3, 2011

Great piece by Anton Aylward on IT Architecture

It is on Anton's blog as a October 2010 post, but for some reason I just got it now on Google Reader. As I'm currently in an Architecture role, it is an interesting reading, I couldn't agree more with him, specially after going through TOGAF training:

A friend ang colleague who is also a security guru and much better qualified than me and who admits that he is not a huge fan of enterprise architecture frameworks doesn’t think that “enterprise
architecture” is on a completely solid footing; he points out that it’s a major business for Gartner, following their takeover of Meta Group.

He asks “Anton, you’re a systems engineer and hence familiar with large-scale modelling and design: what’s your take on the widespread use of ‘architecture’? Is it over-egging the pudding?”

Its certainly is a heavily abused term. One that has been hijacked by marketing and owes more to articles in glossy magazines than engineering substance.

One thing we are all aware of is that IT as a whole is subject to CHANGE. In fact Change Management is a very necessary skill in all aspects of the profession even if the practitioners do not admit to it.

Disciplines like ITIL bring change management to the forefront, and even in InfoSec we are well aware that unauthorized or unmanaged change can be precipitous.

The point here is that most of what engineers get taught about architecture is. on the one hand, about change in that they are building something new, but they don’t seem to be be taught to
“build-for-change”, that is changes to come. In fact it seems bl00dy difficult to get engineers to build for maintenance and repair. Its taken heavy financial incentive to get engineers to design for easy of assembly on some - not all - production lines. And that may conflict with ease of maintenance!

Sidebar: All those Salvation Army Special PCs I’ve worked on, for
myself and as a social contribution, machines I’ve worked on for
clients, have stuck me as things that skin my knuckles when I try to
change hard drives, fuses or twist ribbon cables into a 21st century
artists rendering of a Gordian knot. Ease of maintenance they are not.

I can understand how civil engineers or shipbuilders fail to consider ‘ease of change’; the effort to reposition a highway or a city because of a change in the requirement is high. However Jane Jacobs showed that city planners also don’t seem very inclined to learn form past mistakes and work to political rather than social agendas.

The Irony is that software and much of IT is in such heavy flux and so much of it is as amenable to change as silly-putty. Yet designers still have a mindset that is rooted in a more physical and more fixed world. Change, to many “software architects” means changing your button-bar or
your colour scheme. Big deal.

Well OK, many are tied in by vendor ideas: can you change your mail user agent and still access your mail repository? Notionally I can because I keep all my mail on an IMAP server, but in reality the vendor-specific configuration means that if I changed between Thunderbird, KMail, Gmail,
Outlook, Pegasus, Elm, Balsa, Eudora or Evolution then I would have the better part of a day wasted in setting up all my accounts and the rebuilding of the local indexes. Not quite “vendor lock-in” but a high enough threshold to make change a chore.

Now lets take a look at something else.

The Open Group Architecture Framework (TOGAF) is a framework - a detailed method and a set of supporting tools - for developing an enterprise architecture.

There’s a lot of material at
That TOC has a nice diagram showing “change management” last of all and not discussing it, and not addressing “designing for change”.

But to address the question my colleague raised I focused on this:

“IT Architecture” and “IT Architect” are widely used but poorly defined
terms in the IT industry today. They are used to denote a variety of
practices and skills applied in a wide variety of IT domains. There is a
need for better classification to enable more implicit understanding of
what type of architect/architecture is being described.

This lack of uniformity leads to difficulties for organizations seeking
to recruit or assign/promote staff to fill positions in the architecture
field. Because of the different usages of terms, there is often
misunderstanding and miscommunication between those seeking to recruit
for, and those seeking to fill, the various roles of the architect.

I can’t agree more!

In fact this is an excellent page. But as I said to begin with, the conceptual model omits the fundamental assumption that is implicit in IT, that of change.

And Information Security is even more so!

No comments:

Post a Comment