Tuesday, October 30, 2007

Our need for architects ...

I have now returned from Chicago, but before leaving I walked around the city and I was admiring its spectacular architecture. The picture I selected here shows the old Tribune Tower, just across the street from the Wrigley complex. Originally called the “Cathedral of Commerce”, it’s truly one of the best Gothic creations around.

As you now look back up the river from the South side, toward Lake Michigan, you can see a wonderful line-up of buildings, each representing a completely different style. Starting with the over-the-top, flamboyant, wedding-cake layers of the Marina City apartment and office complex that has been featured in many movies, there follows the austere IBM Plaza that, even in the early 1970s, represented a very minimalist style. Next to them we now have the Trump Tower pushing skywards from the riverside – all concrete and glass. Lastly, there is the very ornate Wrigley Building. Once called “the Jewel of the Mile”, it was an American adaptation of the French Renaissance style and from the 1920s onwards it has been a major Chicago landmark.

I have always had an interest in Architecture. Following a year of Engineering at Sydney University I switched to Architecture at the University across town, the University of New South Wales. But as the ‘60’s came to a close I was one of many who moved into the new world of computers. But I never lost my love of architecture.

During the ’70’s I spent a lot of time traveling. First to England, and then later to Canada, where I really gained an appreciation for cold weather, travel quickly filled out any gaps that may have remained from my school days. It was in Edmonton, Alberta that I first learned that -40 F and -40 C were pretty much the same and that once the temperature fell much below this, it didn’t matter what scale you preferred. It was just cold!

But architecture, and the role of architects, is not limited to just the practice of designing buildings. As I picked up this month’s Motor Trend and looked at an Op-Ed piece on Ford, I was surprised to read that the new boss of Ford, very much a car-outsider in Detroit having come from Boeing, planned to reduce the number of Ford architectures by 40 percent to just 10 core platforms. Furthermore, six cylinder architectures would be reduced from eight to two over the next five years.

I’m not sure how the auto engineers would feel about their craft being viewed as a series of architectures! What are they talking about, I can just hear them mumbling? For crying out loud, we design and assemble cars – not churches or libraries!

But this magazine article reminded me of a recent conversation I had with Jim McFadden at the Euro ITUG event the other week. Jim and I worked together a few years back and I always considered Jim a gifted technologist and someone with very strong views on architecture. So, what makes a good software architect? And, how do you find them?

I became a world traveler and took advantage of the opportunity to develop my skills as I worked with many gifted folks. With my early interests in architecture, it became easy for me to gravitate more to the structures of systems and to the properties of their components and to the relationships that exist between them – to paraphrase something I recently read in Wikipedia on the topic of Software architecture (refer http://en.wikipedia.org/wiki/Software_architecture). But perhaps there’s another way and a checklist we could come up with.

As Jim and I continued to talk about this, we settled on a couple of key attributes and have since exchanged a few emails on the topic. From all of this it became pretty clear to us that any architect in a position of product responsibility, should know the business that they are in. They should be able to bridge the gap between the business goals and the various technology approaches we know about today. As Jim later remarked to me “you have to be able to jump to the white board and present with passion, and this means that you have to be fully involved in planning the technology building blocks - if you don't understand it, then you can't effectively present it!”

As with any senior position these days, communications is essential. Whether it’s the ability to just grab a marker and write all over a whiteboard, or document a position to an industry association, there’s no room for poor communication skills.

There are also a couple of other characteristics that are sometimes overlooked these days. Architects need to want to read, and to stay current. They need to be fully engaged with technology and be fully aware of what’s coming down the road. And they need to be smart enough to ask questions – of their vendors, of industry analysts and consultants, as well as of their own corporation.

And then, Jim remarked, “often times businesses put in place a ‘big name’ for marketing reasons, ending up with situations where the senior technologist or architect is a political position instead of a thought leader. The results fairly regularly are ‘technology drift’, with failed projects. But knowing your business is the most important prerequisite of all”.

I pursued this discussion with others in the ITUG community. Tom Steele, who has supported ITUG events on many occasions, and whose opinion always carries weight with me, pointed out that in addition to the items already on my checklist, he believed “a good architect needs to have a ‘network’ of contacts that are more subject-matter experts, as today’s systems are so complex it is hard for a single person to know it all. Being able to bounce ideas off of someone, or to check and see if there is a technology solution not initially thought of, or even to gain insights into possible pitfalls that might be encountered, are just as important”.

Another viewpoint came from Mark Hutchens who founded InSession back in the late ‘80s and with whom I steal an hour or so for coffee whenever I am back in Boulder. For Mark, while the checklist I had been putting together seemed valid, he was also quick to point out however, that “the real skill would seem to be quick on your feet” and added that perhaps this was something that may not appear on a checklist. It was his observation that folks who were quick on their feet exhibited the openness and eagerness to learn that quickly separated them from others. To conclude, Mark summed it up pretty simply as being “quick to learn, open, adaptable, and honest – and you have it”!

Good architects stay very much committed to the application long after it has been deployed. Not only should they set the overall direction, but they need to stay engaged and manage the whole lifecycle. Applications that make it into production can be properly architected but often outlive their economic usefulness. And this is very important aspect of any architects responsibilities.

“The requirements evolve, hardware, operating system etc. changes, and we keep on patching and modifying to give code another lease on life”, noted my colleague at GoldenGate, Sami Akbay. He went on to add “of course, sometimes this happens at the beginning, before the project is delivered; there is scope creep, disassociated requests from different stakeholders delivered after the code is designed etc. But ultimately, we just try too hard to make square pegs fit into round holes”!

I have spent a small part of my career as a member of an architecture team. I have had a deep interest in infrastructure, and the value that comes from implementing sound infrastructure architecture capable of evolving and absorbing the changing needs of business.

There is a lot of bad code out there today that has come from poorly thought-out architecture.
There are many of us that have a real interest in the bits and bytes of our craft. We spend hour’s fine tuning a routine to optimize its memory usage, reduce its I/O overhead, and tinker with it until we can squeeze the last ounce of performance from it. But unfortunately it is sometimes the case that, when these artisans are elevated to positions of architects and technologists, they often want to continue to tinker - unwilling to acknowledge that there are others in the organization that can do as good a job. The desire for control takes over, and projects begin to falter as these architects become unwilling to pursue the ideas of others. There soon is less willingness to take on risk and the organization begins to loose its way.

We have all come across instances of this, and I am pretty sure we all recognize these architects when we come across them. I continue to be asked whether a group needs an architect or whether an organization needs a chief technologist. To succeed, and o develop plans, you absolutely must have one in a position of oversight.

I have spent time as an architect, but my path to that position was lengthy. The years I traveled to different countries, changing disciplines many times – from programmer, to systems analyst, to DBA, to software engineer, to product manager and so on, and the question after question I asked eventually led me to what I do today and to the contributions I know how to make to my organization.

But today, do we teach the practice of software architecture? Are we encouraging our practitioners to consider stepping up to these important roles? Do we earmark the budgets in support of such training or do we favor selected staff with added benefits, like user events, just to retain their services? Outside of regular participation at our platforms user group events, how much training do we provide?

Yet, to develop and nurture good architects, we have to become a lot more proactive in opening up opportunities for them to be better trained. This is beginning to be recognized within the user groups, and the early word back from their boards is that even greater attention will be given to structured education, and most likely, in parallel to the events themselves.

I don’t think we have any other choice if we want to develop architects of the future, but to step in and build educational programs. Very few companies will want to sit around waiting for the next renaissance-man to wonder in, and even fewer of them will want to run the risk of going with someone who prefers to tinker and who takes them into oblivion. But the role they fill, and the directions they establish, are the most important responsibilities in our organization today, for without their insight we will just bounce from one “Gucci idea” to the next.

3 comments:

Greg said...

Richard, It's great to catch up on your blog every now and then. It's kinda like catching up with you without really catching up with you, so to speak.

What's rewarding about the blog is the way you wield out the past showing the relevance for today in your usual quirky ways – and yes you are still the legend. It makes me think that too many folks forget the links and foundations of technology and where the journey has gone by looking only at the fascinations of the moment. I see this often in many forms from talking to mates about what TV to buy down to having the occasional heart to heart with old colleges who struggle with what really is the best technology solution for their businesses – like I can tell them!.

I guess the problem lies in not appreciating the full potential from platforms and systems that you may already have at your finger tips because it’s simply not fully understood or admiring what you mate has without knowing what it really does.

As a former IT Boss (now retired) of the Australian operation of a US corporation, I often wondered whether that problems with many of businesses today (caveat: not all businesses, and how the heck would I know anyway these days) are in part driven by a lack of real understanding of today’s solutions, and whether you think this can ever really be addressed.

I remember the comment being made in an article I was reading on a flight, not so long ago, discussing how one of the most important publications for businesses (in OZ) was the Qantas Inflight Magazine. Their argument being that the captains of business fly often and read the mag and see something that looks good as a “must-have” for the image of their company, such as the latest CRM, SQL platform or whatever! They then latch onto this and drive it into the business, good or bad. Unfortunatley in these cases architecture and design gets lost and replaced by marketability.

Like you I love archtiecture and design, more specifically its mechanics. So, for me technology is great but often driven by idiots. Now does that sound familiar? (Cars you clown).

Cheers

Greg.



Enough of this, baking beckons me again. Hope to catch up with you soon

Jimbo said...

Richard,
This is a great blog today. Especially to me as it is my birthday. I love the processes and the research architecture involves, but most of all it is the discipline and rigor it can bring to an organization that moves me.

David Finnie said...

A very interesting topic, Richard.

As you're probably aware, titles like "Architect" and so on don't mean a whole lot to many Aussies. Certainly that's the case for myself and several of the dudes I work with. At the end of the day, we get the job done, and yes that may involve some requirements analysis, architecture design, code design, coding, testing, performance tuning, tweaking, etc. ! (And of course documentation, but I prefer not to think about that one too much.)

I'm probably out on a limb here (perched precariously all by myself ! :-) ), but several things cross my mind:

- someone has to design the architecture at some stage. Maybe that's an iterative approach, but generally it pays to have at least one person cast an eye on it before too much else happens. So, yeah, we definitely need someone to act as an architect for each project, even if it is not their sole job.

- maybe some people are good at only being architects, but speaking for myself, I have a vital need to continue to do some of the "tweaking" as you put it. My reasons for this are not for lack of trust in the others in my group - the opposite is true - they are a hugely talented bunch. The main reason is to continue to stay in touch with the code. Otherwise, if I'm not occasionally reminded of the trouble I caused by architecting something a particular way, it is hard to learn from my mistakes. i.e. it keeps me humble and aware.

- having people over-see the architecture(s) is almost always a good idea. Some people are not good at that sort of thing, and don't want to be. Fair enough. Some people are very good at it and that's all they want to do. Fair enough again. For myself, I now, and probably always will, want a mixture of architecture and "dirty hands" roles. Some people are good at specific architectures, and some have that ability to design almost anything thrown their way. Companies need to have enough flexibility so that they can cope with all of these possibilities - I'm not sure if many do :-( At the end of the day, though, it is in their best interests.