IT Architecture in the Blogosphere

Say what you will about Google and its adsense, it does throw up more than the average number of ‘interesting’ links at the top of Google Mail. I stumbled across a link that looked incredibly interesting, but as a means to prevent me from being sued for libel I will refrain from publishing it. My recent post on Redefining IT Architecture shows that I am completely unsure whether I do any real architecture work- most of my work is in the design world- but from time to time I do define the rules that a solution (and very occasionally an enterprise) uses to implement a system so I think that I can call myself an architect.

But after an hour of so of clicking and following links in the IT Architect blogosphere I am confused, depressed and not a little angry at the content that supposed architects are publishing. Now I admit that most of my professional life has been in the data sphere, but I also spend a significant amount of time in the ‘business’ world- talking about governance, processes and skills and resources. In my entire experience I have never had cause to wonder about the details of language used to implement a system, the development methodology or any other deep technical issue.

Now this may simply be a case of the same word being used in multiple situations- after all, we as the IT profession stole the word from the construction industry, so we can’t really complain- but surely there is a difference in the technical skills, the soft skills and the background and experience between someone attempting to define how an multi billion dollar company sets up its governance structure for Information Management and someone implementing an (admittedly possibly large scale) application using the latest technology.

And furthermore (yes I am fully in rant mode now) I also recognise that there are significant skills required to build these systems, but according to the scale of systems complexity (I’ll insert the link to that later) an organisation is one of the most complex systems it is possible to consider; far, far more complex than any engineering design, simply because it has to deal with that most unpredictable of things- a human being. So, is the work that a technical architect does less valuable than an enterprise architect? No, because like all good constructions you need the foundations to be sound, but honestly, none of the major challenges that I face  are in the traditional technical domains (application, data or infrastructure). Far, far more complex to understand is the activity associated with working out what users really want, how we ensure that they use the systems that we build for them correctly and getting buy-in and belief from non-IT people who just see us getting in the way.

As the MD of one of my former employers would frequently say: “Guys, this is not a technical problem”. Unfortunately for that company the tech heads ruled and it finished up going bust (after, I hasten to add, I had got the heck out of Dodge as I could see the writing on the wall). OK, IT Architecture is not going to go bust, but we risk losing a lot of credibility by solving the wrong problem.

And now I need to shut up before I offend more people than normal.

Redefining IT Architecture

Every now and then someone comes along who has such a compelling message and a such a fantastic delivery of that message that the very fabric of your intellectual foundations get shaken. Jan Hoogervorst is just such a person.

Until now I looked upon IT Architecture as a largely diagram based activity- trying to stay away from the As-Is and focus on the To-Be- but fundamentally it drew pictures and was descriptive. Oh, how naive I was: In an hour long presentation Dr. Ir J. A. P. Hoogervorst turned my world on its head.

According to the presentation, and both its content and style of presentation lead me to believe that this view is entirely correct, Architecture provides normative guidance for design. That expression needs explaining: Architecture is the prescriptive process the defines (not describes) the rules by which changes may be made to an existing design to create a new design. Practically speaking then, Architecture is a consistent and coherent set of principles and standards that prescribe how a system is to be designed.

The consequence of taking this approach is the realisation that Architecture and Design (at least in the IT world) are fundamentally different concepts, and that most of the time, the activities that Solution Architects do are actually design. This is not a problem (in fact, a lot of the ‘fun’ part of my job is the design part, the architecture part makes your head hurt) as long as the managers, leaders and other stakeholders recognise what it is you do. And there are actually some good reasons for having one person act as Architect and Designer: the relationship between Architecture and the Design created using it is naturally very close. And as most organisations do not have well defined Enterprise or Solution Architectures, the poor chap (or lass) doing the work is probably going to be switching hats between Architect and Designer many times a day.

As the maturity of Architecture increases, the distinction between the Design and the Architecture will become clearer. But by then there will be a new IT paradigm and we will all be some other sort of engineers.