We don't hire Architects
Quinton Wall's Blog |
May 21, 2007 11:11 AM
|
Comments (1)
We dont hire architects. Like a bell tolling that phrase has stuck in my head for the past few weeks now. They are only 4 words but together they have such a powerful impact I have not been able to shake them ever since a friend, a VP in a start-up here in Palo Alto mentioned them to me.
I have to admit that for some time now I have become increasingly jaded on the use of the word architect and what did that actually mean. Being in the IT industry for some time now I prided myself with being called an architect. In fact that was why I got into the business in the first place; I wanted to build, to create and to design but as time went by the purpose of architecture and those that proclaimed such a title on their resume became increasing hazy. Yes I can architect a system, anyone can do that and yes some can do it better than others but what happens if someone else, or a collective of others creates, maintains and supports an architecture for you? How does that change your perception of need?
This was exactly the conversation my friend and I were debating. Both of us strong fans of open-source and reducing complexity in solutions we continue to explore the ever evolving world of solution frameworks that permeate the technology ecosystem. One such framework I have been looking at recently is Ruby On Rails or RoR as it is known. Admittedly, a newbie when it comes to RoR I am amazed at this immensely powerful framework for building web applications. Having been a fan of Expresso many years ago as a full featured framework which I could use with teams quickly and easily I was thrilled to see RoR embrace dynamic languages whilst adding some depth to the substance, crushing other frameworks in its path. Again, the bell tolled We dont hire architects.
I thought about this some more and fragments of our conversation swirled back into my memory. We dont hire architects, Everything just works, Engineers love it, it stops all the architecture discussions. The thoughts keep flooding back. Imagine going to an art studio and everyone agreeing that strange scribble of paint hanging on the wall that my 4 year old could do was art. I can count on one hand the times where I have been in a room with a collection of architects (are they called a collection, or flock or heard? who knows...I digress) where everyone agrees that a certain design is the best way to go. It happens very rarely IMHO. Even though design patterns, hotly debated these days as a solution looking for a problem, certainly have benefits of learning from the past and others experience but is it really relevant on every project and worse still do they limit us to thinking in a similar way as we did in the past (I still havent seen peer 2 peer design patterns...does that mean P2P is not good?) I am not bashing design patterns by any stretch as I remember not too long ago when Struts burst on to the scene. No longer was their any debate over whether MVC was the right approach. The pattern worked and people didnt argue; the just got things done! Shortly after the same issue of object relational mapping and the bloatware of EJBs was thrown against the rocks and splintered into a thousand different pieces when Hibernate sailed by showing up the clear waters that was possible when simplicity and productivity was the goal. The purpose of the pattern was to simplify design by hiding complexity not demanding allegiance to a single way of thinking.
So where does this leave a product company like BEA with revenue earnings falling short of target and much of the direction focused on SOA (which some consider over engineering to start with). Yes I am an employee of BEA and proud to be, but I am also an observationalist. Looking at the services revenue (a combination of support, education and consulting) I cant help to think that at times it points to an a possible over complexity of solutions and products. Yes, BEA's sweet spot is the hard problems of the enterprise which we do very well but we need to very careful not to turn everything into an art show in the middle of Soho where debate of design gets in the way of delivering real business value to the companies we engage in. Embracing frameworks like Spring (and hopefully more dynamic languages if I had my choice!) is critical but so is knowing where to use what technology. Some consider Java the Cobol of our generation and to tell you the truth I think that is a pretty accurate statement. Java is great for legacy integration with the suite of JCA compliant adaptors that abound but again why cant integration be more dyanmic and leverage frameworks like RoR. BEA is positioned very well to capitalize on the changing environment and are doing so with Web2.0 offerings like Portal, ALUI etc. Dont get me wrong, the suite of BEA products available are the best in the business (otherwise I would not work here) and will continue to be as long as we continue the trend of dynamic change deeper into the product offerings especially in areas such as Integration where the focus must be to continue to simplify the problem through products; naturally the architecture of such solutions will follow the lead and force simplicity as its core principle. The result being better products, better solutions and more business problems solved!
Ok I think I have trailed on for long enough but in order to change our way of thinking we need to throw away old paradigms and embrace new knowledge and ways of thinking. Its not about being right or wrong its about learning more and reacting to that new knowledge. One story that comes to mind when I think of this change that I heard many years ago which sums up my thoughts goes like this:
There was once a reporter who spent many years following Gandhi around India as he spoke to the masses. After a year or so the man became increasingly frustrated with Gandhi's speeches as they often seemed to contradict an earlier one.
Finally, the reporter managed to get an interview with Gandhi where he asked the question why his message kept changing and often contradicted previous messages.
Gandhi looked at the reporter and smiled saying 'That is because I know more now than I did yesterday'.
Who would have thought I would end up quoting Gandhi in a technical blog. I will be first to promote strong architects but will also be the first to recognize the origin of the word which means "Great Builder" Not all projects require great builders but they should look to leverage such wisdom through products they buy or frameworks they download. Projects should not have have to re-invent the wheel every time they unwrap the box or leverage a new framework.
No assembly required I say!
Comments
Comments are listed in date ascending order (oldest first) | Post Comment
-
Hello Quinton,
I'm a first time reader of your blog. Certainly like your writing style.
Guess what, I call myself an architect. I second that it has unfortunately become important to define that, and my definition would be along your lines.
As to the we don't hire architects, that probably means the company doesn't use the word for what is essentially the same thing: an engineer who takes the lead in large scale design, possesses the knowledge and skill to either do it herself or help others to do it, and can explain and weigh the qualities to be designed objectively. Objectivity, i.e. designing for (perhaps difficult to reconcile) requirements, effectively stops the discussion.
To me, objectivity means it's not a matter of being a fan of anything, but to try out a lot of things to be able to come up with relevant facts and figures, then decide and stick to the choices suited to the situation. This usually is a balance of short term project specific requirements and long term organization level requirements. It relates to the identity of the company itself. (and I don't mean the logo & letterhead stuff). Gandhi has a lot more to say about that. Here's one more example on making architectural choices: A policy is a temporary creed liable to be changed, but while it holds good it has got to be pursued with apostolic zeal.
Posted by: erwin_glassee on June 19, 2007 at 4:40 AM
|
