Itana Un-Conference 2021-04-02

Attendees:

Dana Miller (Miami University)

Mojgan Amini (UCSD)

Ashish Pandit (UCSD)

Amy J Fouts (Northern Arizona Univeristy)

Brian DeMeulle (UCSD)

Henry (NYU)

Monique Mavour (Florida International Univeristy)

Jim Phelps (U Washington)

The group voted on a topic to discuss.  The selected topic was Architectural Leadership.  Below are the notes from the discussion.

Other topics that were suggested were:

• Considerations in selecting the "right" EA tool when spreadsheets and Powerpoint are not enough
• Why does the role Enterprise Architect become a disputed topic at times? While we know that we are always doing architecture whether we are aware of it or not, we get caught up in terms. Perhaps an alternative to Enterprise Architect could be Technology Business Partner?
• (Selected Topic) Architectural Leadership
• Body of Knowledge in Business Architecture - What is Next? Body of Knowledge is just the beginning - you need a recipe!
• Facilitation Facilitate meetings, brain storming sessions etc
• What reports do you use to manage your application portfolio? Would be interesting to see the views that resonate most with the stakeholders, and what attributes you need to have to generate them
• Measuring and enhancing the maturity and value of your EA team   Ideas on how to measure value, and contribution that matters most to stakeholders

Architectural Leadership -  Generate ideas, sell the ideas, inspire actions, influence, Build relationships etc

Leadership of the EA Team and how you manage up to the CIO etc.

• UCSD - EA leadership reports directly to the VP-IT, CIO.  The CIO is very technical and interested.  The CIO talks with the EAs regularly and checks in with them.
• UW - We use a matrix with our EA Board (CIO  (Jim will share with the group).  We also use our Quarterly Planning Spreadsheet.

Leadership down and out to organization at large (given that the EA team is small).

• UW - Communities of Practices - Solution and Business
• UW - Community built artifacts - Guardrails
• NYU - Functional people own different applications, different schools have their own IT leadership - how do you balance the influence and decision making and agility and local decision making
• UCSD - for project management they require an EA to be named when the project is getting started.  This helps with a gate.  Every project has a solution architect.  That helps with projects.
• UCSD - Architecture Review Committee (Governance Body) that was launched.  It has distributed IT leadership from campus.
• UCSD - Brian has a lot of relationships with campus partners - connection and influence.  

With the limited number of EAs, how do you prioritize which projects they engage in?

• UCSD - the project team will do the heavy lifting.  It needs to have an EA but they may just be informed - they don’t need to deeply engage unless it is high impact.

What if there isn’t a defined EA team but people are doing EA work in a distributed way?

• MU - have a review board (Value Engineering) that looks at projects but it is way after the fact to have any impact on the project.  
• UW-Madison - built out a set of “deputy architects” people who were trusted to do good architectural thinking and to notify me when they needed help or input.
• NYU - sponsored TOGAF training and invited people from the schools into the group to increase the common knowledge and language.  Mostly IT but some IT savvy business people who came in too.
• UCSD - LEAN Bench - building a foundation of practice and mindset of process improvements.  Did a big effort to roll out training (4500 trained in LEAN 6Sigma).  Because of that, when they did ERP projects , they built a bench of LEAN experts for facilitation and process reviews.  
• MU - vigorous LEAN training program but no unifying project.  There is a capacity but no direction to unify it around a given effort.

EA is a different kind of management track but you are leading via influence. 

• Try and be viewed as a helper rather than a hinderer
• Find ways to demonstrate value:  make things simpler for them (we can connect them to existing resources), keep them from running into problems, point out things that they didn’t consider that will become problems later.
• Storytelling and good metaphors are really important - take the language out of the technical complex and into the clear understandable.
• Making simple and clear graphics.
• Making multiple forms of arguments from emotion - making meaning for different audiences.

EA governance:

• NYU - have put in place a hard stop when you are asking for data.  This is a chance to do a check on projects and procurements.