Mistakes and Missteps
Although my experience doesn’t perfectly match “Murphy’s Law,” “anything that can go wrong will go wrong,” mistakes and missteps do happen, it’s true. Perhaps by articulating a few of mine, I can save you from making the same errors?
Not Everyone Should Become an Architect
At one organization that I worked for, as their architecture practice began to mature, management and HR made what I consider to be a fatal mistake. Since architects are generally more senior than engineers (though not always), HR (and Engineering) assumed that the technical growth path was from engineer to architect for everyone. Since in order to be a competent architect its usual for a person to have been an engineer for quite some time, it seemed intuitive that as engineers matured, they would move on to architecture. The new technical growth path at that company, in attempting to account for the emergence of architecture, went from engineer to architect to senior architect to enterprise architect.
But there’s a flaw in that logic: Not every person is comfortable with the kind of horizontal thinking that architecture typically requires. In fact, plenty of people become engineers because they like the linearity that engineering typically applies. I’m not saying that architecture doesn’t require linear thinking. It does! But architecture also requires patterning, relationships between components, lots of abstractions. Plenty of engineers simply aren’t comfortable with the amount of ambiguity that occurs in the practice of systems architecture. For long periods of time, you don’t know the details of many of those little boxes in the diagram. You have to be comfortable with that.
Furthermore, as I stated above, architects tend to be leaders, which means, to be blunt, architects have to work with other people. Other people have to like working with an architect. There are a great deal of “people skills” involved in a typical architecture role. There are plenty of engineers who don’t particularly enjoy working with lots of people and, even more so, with people who disagree with each other and with that engineer. I like to say, “If you don’t like working with people, security architecture is not for you.”
At the organization that I described, as soon as the architecture role was opened up as the single technical growth path, one unit immediately promoted fifty engineers to the architect role. Many of these engineers had been in line for promotion for quite a long time. Once the architect role opened up, it seemed natural to management to move these engineers upwards in the new growth path.
You can perhaps see the problem? A number of those people, although perfectly wonderful engineers, weren’t very good at thinking about complex relationships and flows between systems. And a number of the same set of individuals didn’t like interacting with people all that much. For a few years, it was a mess.
In that situation, there were numerous “architects” who didn’t have the capability, perhaps not the aptitude, for what the architect role requires. And remember, these people were senior to a lot of the engineers with whom they were working. That means that even though architecture decisions might not be the best possible solutions, those working underneath these new architects might have to implement something that was not ideal. Indeed, some of the engineers could see the mistakes being promulgated by the new architects, which led to a loss in confidence in the architecture practice.
This one mistake caused a three-year halt in the development of what eventually was an industry-leading enterprise architecture practice. It took several years to filter out those folks who would never gain the right skills or who didn’t have the temperament, while at the same time having to wait for the development of those who would take the places of the poorly promoted lot.
Since our security architecture program depended upon the capabilities of the enterprise architecture program, our growth and maturity was somewhat stymied for those same three years. Indeed, we had to deal with a good deal of disruption and outright incompetence during that time. It wasn’t fun. Not everyone can be an architect. Not every security person will be successful as a security architect. The lessons from those three years are burned into the way that I select candidates for the architecture role.
-  At the risk of being obvious, it’s important for organizations to provide an engineeringcareer path for those who prefer to remain in a strictly engineering role rather than haltingthe growth of great engineers or forcing them to try and be managers or architects in orderto advance.