I went to a
CIPS (Canadian Information Processing Society) lunch on Tuesday and the topic of discussion was 'The State of Enterprise Architecture'. The talk was given by Martin Mysyk, the curator of
www.enterprisearchitecture.ca. Actually, it was more of a discussion lead by Martin. This was appreciated as there were many practicing architects in the room and it was good to hear the variety of perspectives, challenges, and concerns that these fellows face.
Martin began by posing the question '
What do Enterprise Architects Do?' Someone responded from the back of the room, 'We slow projects down!' Everyone laughed and then we got more serious. Other answers were offered: 'we provide strategic vision, influence, and guidance to the enterprise', someone read a Wikipedia definition for EA's. In the end, Martin compared EA's with municipal planners. I thought this was interesting and decided to google it, and I found this page:
Enterprise Architecture Analogies Some interesting food for thought.
A slide was displayed about
EA As a Career and a short discussion ensued on how does one get their foot in the door (certification, promotion from BA role, promotion from SA role, etc). EA's require a delicate balance of technical and business expertise, combined with superb soft skills like communication and effective discussion leadership. Martin recommended a book called the
Zoom Factor by Sharon Evans. I might have to pick this one up as it looks like it might be interesting.
Warming to his subject, Martin moved into
the EA Practice. He reviewed several different flavours of EA methodologies out there today, commenting that TOGAF seemed to be the current favourite. A slide was displayed with EA Practice at the top, followed by four boxes (focuses of EA?): Business, Data, Applications, and Technology. I was surprised that Security didn't count among them, and it didn't seem to arise in the discussion as much as I thought it would. If TOGAF suggests that a Business architecture is important, doesn't a Security architecture merit some consideration? Perhaps I missed it in the diagram...
Some important considerations for EA's that came up in the discussion:
- We need to consider growth versus optimization in Calgary right now (considering the price of oil)
- Who in the organization should benefit from EA? Is I.T. really the right place for every organization's EA practice? Some companies have their EA practice reporting to the Legal dept. others report to Operations, or even the CEO.
- Perhaps the question is 'Where can the EA practice provide the most value in organization?' Answers to these questions will be different for each situation. Depending on the answers, one may have to reconsider who the EA practice reports to...
And finally our discussion wrapped up with the challenges that EA's face:
- We need to prove our value with a small budget. How do we do that?
- How do we influence the decision makers without seeming heavy handed?
- How do we provide guidance and structure to development and growth without seeming heavy handed?
I'd love to have some comments!
The Phoenix Project by Gene Kim, Kevin Behr, and George Spafford. The team leads at my current contract recommended I read this book. It's marketed as 'A novel about IT, DevOps, and helping your business win.' I enjoyed this book (and probably most people do) because it was easy to associate characters in the book with real people I've worked with. On top of that, the problems the characters confront in their business are taken from 'last month' in many IT shops around the world. Readers can relate to this book. In some ways, I could say I've lived this book about 8 years ago, and I'm trying to help implement those solutions again where ever I end up working.
