Sunday, January 15, 2006
Defining the role of Chief Security Architect
I previously blogged on my notion of becoming chief security architect awhile back and felt that I needed to expand it to include recent thinking but first wanted to explore the notion of any form of Chief Architect before doing so...
Unlike typical architects, a chief architect has different duties. Most business folk don't really have a clue about the thing they want to be developed should look like. Like blind men, they can't quite understand the elephant. This causes politics and other confusions. Someone needs to formulate and communicate a vision of the goal that the others within the enterprise can buy into and work towards. Some folks may call this type of work "strategy" while others may call it turd propagation, but it still wants doing.
A chief architect should define the "paradigm" for which can be iterated and refined by others. In my own usage of the word Chief in my own title, I have to sometimes check myself to make sure that while it conveys being a subject matter expert in a particular domain, it can and should never become a means to communicate hierarchy. What you call people and processes within the enterprise does matter.
Typical architects are starting to become technical managers whereby they provide guidance to craftspeople (aka developers). This practice can either be vary invigorating or cancerous depending upon whom happens to be in the role. Chief arcitects on the other hand should provide guidance and become the check and balance to what other forms of architects are pontificating. Many enterprises in their savage adoption of best practices and collaboration and forgot about the notion of healthy tension and the chief architect should bring this on.
Prior to working in corporate America, I worked for several Internet startups. At this time, I used to ignore the business conditions when doing technical work. I still believe, that the business should not interfere with the architecture of a system but well. But a good architecture or design costs money. Not because it is necessarily more complicated to develop, but because management needs the allow for more slack, so that a meaningful, fruitful dialog amongst all participants is allowed to emerge.
Likewise, another practice that occurs but should be savagely avoided is during the annual review cycle, chief architects pretty much have to justify their existence by stealing the credit of others. To a certain degree, I have been guilty of this practice not only in a work context but in the books I have written.
As the lead author of multiple bestselling books, I had the responsibility of ensuring conceptual integrity in their creation. Yet, many folks only see my name on the cover and either forget about and/or ignore the fact that a book is never "written" by any single individual. The team includes developmental editors, copyeditors and other roles not usually mentioned. The author gets all the glory, conveys inspiration to the readers of their tome but the real work has occured by others.
I wonder if the bloggers who read my blogs who also happen to be book authors could consider not only acknowledging friends and family in their upcoming books, would also make it equally important to list every single reviewer whom provided feedback. I wonder if we could get industry analysts to do the same?
Anyway, the role of chief architect and that of industry analyst are actually synergistic in many regards. The chief architect has to be a pretty good business analyst, because the primary overriding objective is effective support of some business process...
| | View blog reactionsUnlike typical architects, a chief architect has different duties. Most business folk don't really have a clue about the thing they want to be developed should look like. Like blind men, they can't quite understand the elephant. This causes politics and other confusions. Someone needs to formulate and communicate a vision of the goal that the others within the enterprise can buy into and work towards. Some folks may call this type of work "strategy" while others may call it turd propagation, but it still wants doing.
A chief architect should define the "paradigm" for which can be iterated and refined by others. In my own usage of the word Chief in my own title, I have to sometimes check myself to make sure that while it conveys being a subject matter expert in a particular domain, it can and should never become a means to communicate hierarchy. What you call people and processes within the enterprise does matter.
Typical architects are starting to become technical managers whereby they provide guidance to craftspeople (aka developers). This practice can either be vary invigorating or cancerous depending upon whom happens to be in the role. Chief arcitects on the other hand should provide guidance and become the check and balance to what other forms of architects are pontificating. Many enterprises in their savage adoption of best practices and collaboration and forgot about the notion of healthy tension and the chief architect should bring this on.
Prior to working in corporate America, I worked for several Internet startups. At this time, I used to ignore the business conditions when doing technical work. I still believe, that the business should not interfere with the architecture of a system but well. But a good architecture or design costs money. Not because it is necessarily more complicated to develop, but because management needs the allow for more slack, so that a meaningful, fruitful dialog amongst all participants is allowed to emerge.
Likewise, another practice that occurs but should be savagely avoided is during the annual review cycle, chief architects pretty much have to justify their existence by stealing the credit of others. To a certain degree, I have been guilty of this practice not only in a work context but in the books I have written.
As the lead author of multiple bestselling books, I had the responsibility of ensuring conceptual integrity in their creation. Yet, many folks only see my name on the cover and either forget about and/or ignore the fact that a book is never "written" by any single individual. The team includes developmental editors, copyeditors and other roles not usually mentioned. The author gets all the glory, conveys inspiration to the readers of their tome but the real work has occured by others.
I wonder if the bloggers who read my blogs who also happen to be book authors could consider not only acknowledging friends and family in their upcoming books, would also make it equally important to list every single reviewer whom provided feedback. I wonder if we could get industry analysts to do the same?
Anyway, the role of chief architect and that of industry analyst are actually synergistic in many regards. The chief architect has to be a pretty good business analyst, because the primary overriding objective is effective support of some business process...
