Posted by Mike Rollings
Last week I attended the first meeting of Penn State's IST EA Advisory Group. This group is helping Penn State define undergraduate education, graduate education, and professional development education and research related to enterprise architecture. The four different teams really took off over the course of the 1.5 days we were together. Many good ideas came out of the kickoff and I look forward to helping these ideas move forward as part of the professional development team and the group.
However, even among those at this event (around 70 people) who have been around EA for a long time, the question still remains -- What is EA? Thankfully the leader of the session did not go down this rathole. Instead we focused on what needs to be done to develop enterprise architecture professionals.
Who is an EA professional? The point of view I shared with the professional development team was that I did not think that our focus should be just for those that identify with EA. If you have to decipher the term EA before you can get value from the courses then I believe we miss a great opportunity to introduce useful methods and disciplines to many business and technology professionals.
For those of you who have followed my writing in Burton Group research and also this blog, my position should not be surprising. For instance, since we launched our enterprise architecture coverage 18 months ago I have been calling for a focus on business outcomes, influencing decisions across business and IT, and a move away from the notion of an ‘EA devotee society’. This is just a part of the brokenness of EA. I would much rather discuss how to correct EA-related fractures in organizations and describe competencies or practices (e.g. business optimization techniques, dependency analysis) that heal the patient, rather than first convincing someone that they need EA.
I think that the competencies that make up EA should be offered to a broader audience of professionals. For instance, the business strategist who is looking for a way to broaden their ability to examine implications of a strategy to include a technology impact assessment. I don't want to put a barrier between them and the method by first having them get the term EA.
I believe that the broadest benefit comes to those who focus on the competencies and not the EA term. The reason we care at all about the analysis techniques etc. in the EA bucket is because we want to improve business outcomes – not because we care what you call the bucket! When you focus solely on the bucket it leads to ivory towers, ineffective processes, a lack of participation, and low stakeholder commitment. I would rather focus on the value to the business.
Comments