The Ivory Penthouses of Architecture
Jim’s asked when architects moved out of development. After all a master builder is still a builder, right?
An even more interesting question is “why” architects moved away from software and into Ivory Penthouses?
[With a touch of my renowned sarcasm, sometime ago I brought the ivory tower / 30,000 feet view analogy into the modern era and refer instead to ivory penthouse and 30th-story.]
There’s lots of answers. I’ll pick two that have to do with the problem space and the solution space.
The Problem Space - It’s big and it wants to change ever-more rapidly.
This is the “why we are here” of the IT industry - “The Business”. IT(&C) is a business imperative now and has been for a while. There is no option. It is no longer a question of whether you leverage IT, but rather how quickly.
The market demands it bigger/smaller/better/cheaper/quicker/whiter. A competitor makes a killer move. A major part of the supply chain just went broke.
All of these things require universal changes within the organisation and often in conjunction with partners. IT is often seen as the slowest to change, which is ironic given that the primary enabler (software) does not exist in a tangible reality.
Agile software development obviously deals with this in a paticular and successful way.
Applying agile values and techniques to superintending design concerns is what Rebecca’s article is about (and as Jim expresses, something that is astonishing in its rarity).
Why would architects decide to take the elevator up to the ivory penthouse? Because the 30th-storey view is a lot nicer. It seems easier to see commonality, diversity and boundaries. I say “seems” because these elements have different characteristics at the macro level to when they’re seen in detail. Personally, I find it invaluable to use the details to form or validate the world-view picture as the fractal nature problem solving becomes fuzzier and more distorted the higher you get until two problems that may look alike from on high can be very different, and applying the same solutions to both is typically not aiming for success.
It’s certainly easier to spot more distant changes and general shifts in a particular direction. This is where the enterprise architect adds real value to the business proposition, but only if the assumptions on which technical decisions are made are valid.
The Solution Space - It’s big and it’s growing ever-more rapidly.
This is the “what we use” of the IT industry. Our tools and techniques.
In the 15 years of my career the amount of “stuff” you need to keep across has increased at an almost ludicrous rate. It’s mostly not “good stuff” either, but you do have to research and deal with it no matter what its quality or applicability (is there a Moore’s Law for software dross?).
As Hani will atest from the bottom of his liver, this is phenomenon is particular prevelant in the Java world, however those that have dealt with ActiveX components, Perl modules, Linux packages, and Photoshop plugins also have felt the bewilderment of garbage gluttony.
Apart from just the software, there’s the architectural models, patterns, methodologies, and (for those of us who remember that the “U” in “UML” doesn’t standard for “Universal”) metaphors and languages.
Why would architects decide to stay up on the balcony sipping Vodka Redbulls and eating canapes rather than be with the developers guzzling Coke and eating pizza? It’s a helluva lot easier and more tranquil, that’s why.
It’s difficult to flit from one standards specification to another, to work with the builders to see how vision is transformed into reality, and to do the winnowing and chaffing needed to pick the best solutions for the problems at hand. There’s no substitute for practical experience but with the amount of effort required to have detailed experience along with broad comprehension, many just opt for staying in the conceptual layers and never see their vision through to the end, including getting their hands dirty to help build it.
Will they heed the advice and follow the lead of those who know a better way? Sadly, I think not in the main.
Architects are often ridiculed for just drawing pretty pictures. One so-called EA took it to another level recently and told me in response to discussions about researching the codebase to assist developers in moving to a new architecture said that he’s not a worker, he just tells people what to change in their diagrams. ‘Nuff said.
