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.