Rethinking EA Training
An interesting discussion started on LinkedIn by Nick Malik, a principal architect at InfoSys. The premise was the following:
“I don’t think we do a good job of teaching professionals to become Enterprise Architects. Certification typically focuses on terms and geeky methods when EA’s spend large chunks of time and effort collaborating and convincing and communicating. Basic knowledge of business, logistics, finance, governance and measurement is often spotty. I think it’s time to rethink EA training.”
It's an interesting perspective and his conclusion is something I agree with:
"It's time to rethink EA training"
Most EAs I meet come up through various technical disciplines; wanting more and more authorship and agency in the technical approaches and standards of their industry. Eventually I've found leadership want to consolidate practices and level-set on many levels; and they usually bring TOGAF, SEI, or even IBM eSDM in to do so. My own experience with these are quite good, but when pressed can belie the still evolving profession.
TOGAF is a great basis for EA, steeped in the historical depth of RAND and DODAF; the large scale government project architecture methodology translates quite well to equally slow moving enterprises. Where TOGAF falls down in modern times is keeping pace with concepts such as MVP, AGILE, and the 12 Factor app. Designing micro-services to fail, in concert to produce functional full applications, does not allow for the full TOGAF ADM to even have a chance without wasted effort of churn. Where TOGAF shines however is as a basis for understanding for an EA group and associated architects. Think of it as "Fundamentals and History of Architecture" and you'll get a good grip on the basics and some deep dives into sometimes unfamiliar domains.
SEI, and particularly ATAM, are also steeped in large government projects. A fellow architect peer in a previous role; and an innovation leader, would consistently debate that EA is stuck in 'governance'; and TOGAF and SEI back up this argument. SEI ATAM is meant to deep dive objectively into systems, down to the component level; something important when you aren't quite sure your 3rd party outsourced defense contractor is working diligently enough on your behemoth world 'peace-keeping' destroyers. Where I found SEI ATAM however to differ and offer unique value is their focus on authoring and prioritizing capabilities, of any type; consistently referred to as "ilities" in SEI courses. I personally enjoy this approach as it takes the somewhat 'static' capabilities such as scalability, reliability, etc. and allows the stakeholders to truly author what is most important to their vision.
These are great foundations for any CxO or EA group to level-set expectations and fundamentals. My own experience is TOGAF, SEI ATAM, ITIL, and eSDM; and these provided fresh insights and great refreshers on the fundamentals of Enterprise Architect, each one enjoyable in their own right. But where the classroom ended, I was left to forge my own path.
“I’m going on an adventure!”
Mentorship and experimentation has helped me the most in the past. I've been fortunate enough to have great mentors and I'll name them here; Jeff Cain or Nationwide Insurance, Scott Leigner, Pee T. Lim, and Hoa Ton That of Travelers to name a few.
Jeff taught me as an EA at Nationwide to challenge anything subjective, and he steamed ahead as probably the most visionary and impactful IT leaders in that enterprise. He was also a very organized and pragmatic person, and his results would speak for themselves. Everything had a logical reason, and if it didn't stand up to scrutiny or fill the need, it was scrapped and we moved on, MVP EA?
Scott Leigner was a manager of mine at Travelers, and on large assessments would challenge the methodology as well as the results. In addition Scott was deft at navigating the politics and players of a large organization. Jeff and Scott had many similarities, but the most defining was assessing the method prior to the project. Analyzing the path before we took it.
Pee T. Lim and his compatriot in innovation Hoa Ton That at Travelers taught me to question the entire viability of EA; both evangelic's of MVP and innovative approaches; their goal was to develop faster with minimum risk, a daunting challenge in a 100 year old insurance enterprise. But their work speak for themselves: great strides in IT culture change in a behemoth of a company, fighting disruption on it's own turf.
The most important part of these mentors however, and I've spoke to this before in previous posts, is that they were also all very congenial and nice people; not attacking the status quo like a pitbull but working in harmony with it.
“If you can dodge a wrench, you can dodge a ball!”
And lastly, experience and experimentation, have pushed my knowledge in EA further. I love Data Visualization and the teachings of folks like Ed Tufte and McCandless. Often EA work is tasked delivering a consultation to a decision maker or a larger audience, forays into DV and infographics have helped me up the ante in how my artifacts are displayed with a hope to captivate more people into the vision I am proposing.
What these experiments unveiled to me was a lack of innovative EA tools, many EA's have to work with a plethora of modeling programs. Most commonly Vision, PowerPoint, or Excel; with some EA groups focusing on Rational or Archimate to at least provide a centralized repository. This in my opinion is a symptom of EA lacking training, as most technical professions rely on training to a tool for recognition of knowledge.
In the end I agree with Nick; there needs to be a shift in education and training for EA. If I were to approach a modern EA curriculum in modern times, I'd approach it as follows:
Fundamentals and Foundations: TOGAF, SEI ATAM
Methodologies: AGILE and MVP
Trends: Microservice Architectures, Cloud Scaling, AI, and Continuous Deployments
Influencing: Data Visualizations, Presenting, and Business Etiquette
Innovation: Fluid changes in topics, creativity focus, and a search for better tools.
Is this all for naught?
In conclusion, I have a theory: Injecting EA into micro-service AGILE could lead to an almost automated architecture repository; coupled with machine learning confidence architecture pattern matching, this could possibly lead to a dying profession with EA's relegated to operators. Will micro-services become bloated in the process, maybe. I have no doubt the "communication and convincing" aspects of EA will remain, leaders will still want their advisers, there isn't enough time in a business day to play EA and CxO. An underlying assumption for A.I believers is that the only jobs that will remain our future will probably be 'creative' roles, however, still leaves a place for architecture practitioners. Perhaps a shift to better tools and the creative aspects of EA will lead to a better place.