This is apparently a discussion that comes up on a repeated basis on LinkedIn, and was asked again recently. Fortunately, Jeffrey Smith (Chief Architect, Lockheed Martin) was kind enough to post a summary of the last time this discussion came up, and I’d like to share his words with you. Excellent insight from the EA community on “the value of experience” in Enterprise Architecture.
“While it is hard to determine when a consensus is reached on a forum like this, we did come to some general agreement. I will try and summarize what came out of that discussion as best I can from memory.
- We all agreed that it is experience, not age that is the determining factor. With that in mind, however, there is going to be a minimum age in order to gain the experience. Most agreed that someone under 30 marketing themselves as an EA either did not understand what EA entailed, or was being unrealistic. To be effective as an EA, the person must have a combination of business and technical experience that would be virtually impossible to attain at a younger age.
- We discussed the types and levels of experience that were required. Obviously an effective EA needs to have both technical and business experience to be effective. The amount in each category will vary depending on the person and the industry they are working in. Someone that wants to be an EA in an industry that relies heavily on technology would need more experience in the technology area than someone looking to work as an EA in a less technology intensive industry.
It was also discussed that the both the technology and business experience ideally should be from working at a number of different companies. This was viewed as important to provide a more well rounded view than what would be seen in working for a single or very small number of companies. Every company has it’s own approaches to both business and technology and understanding the different approaches allows an EA to better work in whatever culture they find themselves in.
Experience in only on business approach or technology approach is just a limiting as having experience in only one technology area. The experience also needs to include working at management levels in order to get the big picture understanding needed.
- There was a discussion about various certifications and there value in determining the competence of an EA. While certifications can provide a good foundation for someone going into the field, certifications are no substitute for experience. By the same token, someone with 25+ years experience should not be viewed as unqualified simply because they do not have a piece of paper. For someone with 25+ years in architecture, going to get certifications is not likely to add much in terms of their skill as an EA.
There has been a lot of debate about what makes a good EA, and I think this debate will continue for some time to come. The main part of the debate seems to revolve around whether it is better for EAs to come from a technology background or a business background. There are plusses and minuses to each. One thing that is needed in the EA field is the establishment of mentorship programs to help train the next generation of EAs. Successfully establishing industry recognized mentorship programs would go a long way towards advancing EA as a profession.”
Some very nice points in here, thank you. We with the grey hair definitely think you have to have some to be an EA!
But all kidding aside, I think we have to come down firmly on the side that experience counts. But experience of what? That gets to the fundamental question of what we do. I see EAs (at least by title) who are alll about the operational stability. I see others (by title) who are all about the applications portfolio. I see some others who are all about the "business" – whatever that means.
For me the EA is in the business – that doesn’t mean the EA reports to someone in "the business’, it means that the EA must have the business chops to be allowed a seat at the enterprise table.
EAs must be about dealing with unanticipated change. Sounds like a contradiction in terms, because by definition the actual changes will inevitable be unanticipated. Hower the kinds of change, rate of change and shearing forces can give architects insight into the kinds of flexibility/tradeoffs required.
Simple rules like "things that are likely to change rapidly and often shouldn’t be embedded in things that change infrequently and slowly". It’s kind of obvious, but actually requires considerable insight.
Other rules like, "you need to minimize side effects of one ‘system’ from another". The best example here comes to me from restaurants and sewage systems. Where I live, sinks in restaurant kitchens are not allowed to be connected directly to the sewage system. There is an air gap. So if the sewage system backs up the efluent doesn’t get into the sink where food/dishes are. Not a pretty image, but a really good point. In the event of a major storm – when the sewage system is overloaded there is safety. Note that system has nothing to do with technology – it is really an illustration of a core architectural pattern
As a final note, I am not sure that it is mentorship exactly that we need for the future architects. Apprenticeship, perhaps. But mentoring is somehow different.
Well, interesting reading for me as in my very freshly 29th year of age I am actually in official EA role for five years already:) (And not solution type EA, not technical architect like EA, let alone infrastructure architect EA)
So where did I get the experience to actually become (as I believe) a good one? Of course on the job, in previous consulting,at university (PhD). But I do strongly believe, that it is much more about attitude, focus, interest and the right level of interest (and talent, perhaps?).I have developed in the past years as well, from certainly more techie guy (when it was just enough to have smart ideas how to make a piece of software live longer, be cheaper, more modular…) to be much more interested in how to actually make those ideas happen in a complex environment, when does it make sense to do it and if the company is actually interested in it. I became much more interested in the nature of the company, in its operating model, in people, culture (pretty important), social background, varying interests of stakeholders and how to cope with those… and – well – understand politics as well, of course. On the business side, even if I basically stick only to banking (and previously to Telco), it is not that much difficult to actually see how the business works elsewhere and how the EA function works elsewhere, where its positioned and who are the actuall "customers" (I have also quite a good understanding of different modes of operation and business in number of diversly big CEE banks).
And I do dislike to be actually judget by my age (especially when the first piece of software which I sold was when I was 14 – and no, it wasn’t HTML web page:)
P.S. Certification does not make much difference. I do have a COBIT foundation certificate and I do not find myself to be a pro because of that. I do not have any certificate on any EA framework, but I do believe that despite that I could be pretty helpful lad to help a company with that.
@Ondrej
Valuable input. Thanks for sharing.
EA experience is not a question of age, but a question of whether one actually has had insight into all disciplines of EA
You have to understand technology
You have to understand the concept of business and enterprise management
You have to understand information architecture
You have to understand application architecture
and many more
Can you have all of this when you are 22?
Probably not
Can you have missed some of those when you are 45?
Absolutely!
Being an Enterprise Architect is all about technology, not business. Chris Bird says it’s all about business, but it’s clearly not. It’s about knowing on a higher level how to design and maintain your enterprises’s IT architecture: What systems to implement, how to implement them and much more. Without solid programming experience, you really know next to nothing about IT. And, also it’s about communicating this technical information to the executives and management in the company, as well as communicating the business objectives to the development team, and implementing them correctly. And, it’s also about taking responsibility for what you have done in a big way. The only person who can do this is a person who has started at the bottom in IT (which is obviously programming), and only then can he move up to possibly development manager, and then software architect and then enterprise architect if there is this path in the company. Also, I don’t understand how in North America where the language is english, that there is so many immigrants who can’t write or speak english properly (illustrated clearly by Ondrej Galik’s poor essay.). How can he be an Enterprise Architect? This leads me to another very serious problem in IT. There’s clearly a problem because of the sheer volume of H1B Visas being granted to overseas workers without a proper foundation in our language and culture. It is lowering our salaries and giving the IT industry a bad name.
Hi John,
There are a number of threads on LinkedIn where someone would post a message that begins like your response here, only to have five or six published authors or accomplished EA leaders literally leap on them, arguing that EA is about Business, not Technology.
I’m a little less of a fanatic on the point, but I do swing to the "business" side. An architect who plays the role that you describe is an important person… but the more correct term is probably Enterprise Information Technology Architect. I would be concerned with your confusion between these roles, as an Enterprise Architect does not need to work their way up through IT to be effective.
Also, before you jump on Ondrej’s grammar, please be aware that responses to my blog come from all over the world. In many cases, the respondant is speaking English on my blog, but in their native land, where they serve as an EA, they speak a different language. I welcome the input of anyone who would like to share with me, and I doubly welcome the input of someone who lives in another country, yet is willing to communicate with me in a language that they do not use on a daily basis, in order to share experiences that cross languages and borders.
Welcome to the discussion. I’m glad you shared your insight and opinion and I hope you read further about the field of Enterprise Architecture.
Yikes! Minimum age for an EA? I bet you like to poke sticks into hornet nests.
Next I bet you will ask if an architect needs to code?
Just kidding. Thanks for furthering the discussion on this topic.
Hi Nick,
I watched the discussion you’ve summarized on the LinkedIn group. I have several thoughts on the matter based on my years of experience.
I do believe there could be a rare EA just under the age of thirty. This is based on opportunity, mentoring and education. My next comment may not be welcome.
I would be very hesitant to hire an under 30 EA unless I knew he’d been mentored by someone who had at least 15 years of experience in various roles and at various employers. The dotcom boom flooded IT with people who just know how to make something work. Those who stuck around after the dotcom bust are teaching the ‘just make it work’ mentality to the latest crop or IT people. What happened to wrapping analytics around solution provisioning?
A sure indicator of ‘just make it work’ mentality can be observed through solution sprawl. Solution sprawl is where someone figures out how to make something work then they apply the same solution repeatedly without considering supportability or scale. Or a solution is applied just because a technology has the functionality without any regard to supportability.
What is EA? That question continues as a debate. It is whatever the business determines. For some it may have a more technical slant for others it is a blend of business w/technology as the solution. For EA to succeed, a decent blend of innovative leadership is required (e.g. that means less linear thinkers at leadership layers).
Thanks Nick for backing me up:)
To John: Please excuse my English or stop reading at this point. You were right, my native tongue is not English and I do not work in English speaking country, let alone US (yet the allmighty internet allowed me to reply to this post). So do not worry, there is no such a silly US company that would employ a poor lad like myself for a position which I do not fit for while taking other pure US cititzens their jobs:) Fortunately for me, you can find such a silly company in Europe, which with 50.000+ employees is still willing to employ and pay very nice money to somebody like me doing enterprise architecture.
Now, back to the topic of EA from the trip to nationalism (and just a liiiitle bit of irony;).
I do understand your perspective. I also believe that it is one of the currently more prevalent opinions. Nevertheless, since I’ve seen some EA practices already, I must admit that I also do believe that excelent EAs can recruit from business side as well, or from excelent managers/project managers. Because the role name does not really matter that much as the past experience and huge pack of soft skills.
RHWhite made a valid remark about mentors as well. In my case my last two bosses (Chief architect/CIO) were 50+ with excellent track record. Such people can help, educate, guide and motivates very much.
Cheers
O.