The Ivory Tower Enterprise and Software Architect
Lately I have been hearing a lot about the differences between an Enterprise Architect and a Software Architect. Grady Booch just did a great Podcast called Enterprise Architecture and Technical Architecture, Arnon just did a great blog titled Software Architecture – 5 years later, and Bredemeyer separates their site based on the differences. I agree with them all, the roles are different and I am not questioning their points of view. I am just pointing them out because they are what sparked my thoughts for this post.
I tend to see all the roles in the software field a little differently. I see three classes of individuals at different levels of their career path. One I call the Ivory Tower type of person. The second is an In the Valley type of person. The third is the person in the wrong career path. I won't discuss the last type of person more than to say that there just are some people who are not trainable, and they are usually in the wrong career path.
The Ivory Tower type of person usually believes their intelligence is sufficient enough to carry them in their current role. They will blindly follow the advice in a random article, web cast, or vendor demo. They see proof of concepts as a waste of time.
The In the Valley type of person understands nothing is invented, it is only discovered. They accept that odds are someone else has already discovered what they are looking for and gone through the pain of vetting it, but they will trust nothing until they have seen it work in the environment in which it is going to be integrated. Demos, articles, and web casts are not enough to persuade them a product is ready for adoption in their environment.
Government is the perfect place for the Ivory Tower worker. Government is in the spending business. Spend your budget, or lose your budget is the driving force behind most government projects. The Ivory Tower worker is great at spending money.
In my book if you are an Enterprise Architect, you better know how to do Software Architecture. If you claim to know how to do Software Architecture, you better be a darn good developer. I do not believe in the hands off approach and I do not believe the Software Architect and Enterprise Architect should fall into completely different categories. To me an Enterprise Architect relationship to Software Architect is similar to the System Architect and the Software Architect. In my book if you claim to be an Enterprise Architect or System Architect, you better be able to fill the role of Software Architect.
If all you do all day is analyze business processes, you are a business analyst. If you translated the business processes to a software architecture, then you are a Software Architect. If you translate the business process into a software architecture that takes into consideration the enterprise it must live in and integrate with, you are an Enterprise Architect.
Enterprise Architecture and System Architecture simply include a broader range of soft skills and knowledge to do there jobs. I believe the same is true of the relationship between the Software Architecture role and the Development role, but if you aren't a great developer in the language you are architecting your solution for, you have no business architecting in that language/technology.
The same holds true for COTS products. You should know how to use the product inside out before you include it in your solution.
I know you can't know everything. That is what proof of concepts are for. Proof of concept the heck out of a solution you don't understand. Heavily documenting your findings for a diverse audience forces you to think about it in different views and helps to flush the gotchas.
I also understand that there are a lot of soft skills needed to be a Software Architect versus being a developer, and being an Enterprise Architect versus a Software Architect require even more. But gaining those skills does not mean you can compromise your technical skills.
Below are some of the characteristics I witness in the different types of people.
The entire point of this blog is to provide some insight into the reasons for some of the mangled up messes we see out there in our industry. Being a consultant I see a lot of them. A lot of times I am coming in after an Ivory Tower crew has wreaked havoc on an environment.
As with agile, I do not believe a process, or a role defined in a process, creates excellence. The characteristics the individual brings to the role will determine the level of excellence they achieve. A key characteristic is the ability to remain teachable. Lose that and your on the way to your own Ivory Tower.
I tend to see all the roles in the software field a little differently. I see three classes of individuals at different levels of their career path. One I call the Ivory Tower type of person. The second is an In the Valley type of person. The third is the person in the wrong career path. I won't discuss the last type of person more than to say that there just are some people who are not trainable, and they are usually in the wrong career path.
The Ivory Tower type of person usually believes their intelligence is sufficient enough to carry them in their current role. They will blindly follow the advice in a random article, web cast, or vendor demo. They see proof of concepts as a waste of time.
The In the Valley type of person understands nothing is invented, it is only discovered. They accept that odds are someone else has already discovered what they are looking for and gone through the pain of vetting it, but they will trust nothing until they have seen it work in the environment in which it is going to be integrated. Demos, articles, and web casts are not enough to persuade them a product is ready for adoption in their environment.
Java != .NETSo what's the point? The point is that I do not believe in the Ivory Tower side of career path. I have seen a lot of motion generated by these people, but the efforts usually end with nothing accomplished, or a train wreck for someone else to clean up. I am not saying they are lazy. I have watched them work their butts off.
My first week on a particular project I was asked to be the advising architect on a Java project. I said no. The manager believed anyone with architecture in their title could architect on any project and that technology should not impact the role. I explained I was a .NET Architect and that it was not my belief, or experience, that technology did not matter. I soon found out why he believed what he believed.
That organization had an army of Ivory Tower Enterprise Architects that blindly made decisions behind closed doors about what was best for the enterprise without ever understanding the enterprise. They would buy huge applications and force them down the throats of the employees in the enterprise. The answer as to why something was needed on a project was "because we bought it, and now you have to use it".
I soon learned why the EA division was made up of Ivory Tower Enterprise Architects. It was because the CIO was an Ivory Tower CIO. With regards to technology, if an organization is made up of managers that are completely confused, it can usually be traced back to their own IT organization.
What happen to the Java project? 80 million dollars down the drain. Would have been better spent on a spare tire for the Mars Land Rover.
Government is the perfect place for the Ivory Tower worker. Government is in the spending business. Spend your budget, or lose your budget is the driving force behind most government projects. The Ivory Tower worker is great at spending money.
In my book if you are an Enterprise Architect, you better know how to do Software Architecture. If you claim to know how to do Software Architecture, you better be a darn good developer. I do not believe in the hands off approach and I do not believe the Software Architect and Enterprise Architect should fall into completely different categories. To me an Enterprise Architect relationship to Software Architect is similar to the System Architect and the Software Architect. In my book if you claim to be an Enterprise Architect or System Architect, you better be able to fill the role of Software Architect.
If all you do all day is analyze business processes, you are a business analyst. If you translated the business processes to a software architecture, then you are a Software Architect. If you translate the business process into a software architecture that takes into consideration the enterprise it must live in and integrate with, you are an Enterprise Architect.
Enterprise Architecture and System Architecture simply include a broader range of soft skills and knowledge to do there jobs. I believe the same is true of the relationship between the Software Architecture role and the Development role, but if you aren't a great developer in the language you are architecting your solution for, you have no business architecting in that language/technology.
The same holds true for COTS products. You should know how to use the product inside out before you include it in your solution.
I know you can't know everything. That is what proof of concepts are for. Proof of concept the heck out of a solution you don't understand. Heavily documenting your findings for a diverse audience forces you to think about it in different views and helps to flush the gotchas.
I also understand that there are a lot of soft skills needed to be a Software Architect versus being a developer, and being an Enterprise Architect versus a Software Architect require even more. But gaining those skills does not mean you can compromise your technical skills.
Below are some of the characteristics I witness in the different types of people.
| Roles | Ivory Tower | In the Valley |
| In all the roles | Considers themselves artists. Likes to invent Creates new things that need to be fitted into the context in which they they are working | Considers themselves engineers. Seeks out industry standards Creates new things that are of value to the context in which they are creating and therefore fit naturally into that context |
| Developer | Use Agile to mean "we do not document" | Use Agile to mean "take full advantage of the team's collective experience" |
| Lead Developer | Acts more like a project manager | Is building the first of every type of module, and guides the team from that baseline. |
| Software Architect | Believes they can leave behind their development skills Does not believe software architecture is dependent on their knowledge of technology | Understands that keeping up with their development skills is a must. Understands software architecture requires complete understanding of the technology they are using |
| Enterprise Architect | Believes they can leave behind their development skills and architectural skills Is not involved with application level details | Understands that keeping up with their development and architectural skills are a must. Understands the details of their enterprise's applications |
The entire point of this blog is to provide some insight into the reasons for some of the mangled up messes we see out there in our industry. Being a consultant I see a lot of them. A lot of times I am coming in after an Ivory Tower crew has wreaked havoc on an environment.
As with agile, I do not believe a process, or a role defined in a process, creates excellence. The characteristics the individual brings to the role will determine the level of excellence they achieve. A key characteristic is the ability to remain teachable. Lose that and your on the way to your own Ivory Tower.
posted by tadanderson at 6:48 AM
3 Comments:
I pretty much agree with the whole content of the post.
About the Agile process I would say that most of the startup companies have adopted this term as a way to hide the adhoc process they usually follow. In fact this is not even a process.
At the architecture level the ivory towers usually happen to be at TOP positions in companies and this is when things get really tough for the Architects as their suggestions go down the drain as they don't fit their models. For instance at one time my suggestions were rejected based on the reason that I was suggesting to use a third party cache and the person in charge wanted to reinvent the wheel just to have more control over the cache.
Excellent article and provides accurate view of what an Architect should look like and do.
Excellent article that correctly puts things relevant to an architect and what he/she must look like and do.
Post a Comment
<< Home