A taxonomy of pain-points for implementing and engaging in enterprise / I.T. architecture at institutions.

Budget Processes that focus on localized cost not overall cost. (Activity Based Costing as an example)

Developer Incentives that reward low-cost/on-time rather than engaging architecture and expanding the core architecture of the enterprise

Project Management Mindset that is tied to a broken budget model

Unanswered questions on the role of architecture in governance

Lack of carrots to offer to those who are good architectural citizens

Incorporating architecture into the SDLC or PDLC (project development lifecycle) so that it gets as much focus as other development activities such as development, test, release, etc.

Carrots  

This is the place to talk about the carrots we offer to those who are good architectural citizens.

Carrots at all the various levels: 

Having existing core-infrastructure that they can leverage is a good carrot.

Carrots for Developers (from Hebért Diaz-Flores' email)

  1. Promotional opportunities (I did end up advancing some of the staff)
  2. Idea that you could make yourself more "marketable" by using enterprise standards
  3. Training (everybody received training in the enterprise technologies)
  4. Reduction of work related to maintaining local hardware and software (this ended up to be quite a significant carrot)
  5. Opportunity to do something new (most people don't want to be "stuck" doing the same thing forever)
  6. Removing headaches about information security
  7. Opportunity to work collaboratively with staff outside of the department (some people liked this, others not as much)

Carrots for Project Leaders / Managers

  1. Volunteer / Offer to do some of the work
  2. Offer it for free
  3. Performance Reviews that include evaluating "Enterprise / Architectural Performance"  more of a "how did you do it".   Something like Stanford's performance review process and Bredemeyer's Architectural Competences.  Titles that include Architect would be created in various groups with the expectation that they would think / act architecturally.

Carrots for Department Heads / Executives

  1. Cost savings across projects
  2.  

Anti-Carrots

  1. Charge-back for doing the work the right way
  2. Money already spent on a non-enterprise solution
  3. Attempting to build out the core infrastructure on a project-by-project basis which adds costs and complexity to every project

Other Issues: 

How do Engagement Style and the Carrots affect each other?  e.g. If you have money to help out a project (off-set costs), does it change your engagement style?  If you have no carrots, are you stuck in the pleading mode of engagement?

If you are going to ask people to fit into an enterprise infrastructure, you need to have an infrastructure to fit into.  Chicken-and-Egg problem.  Trying to build out the core infrastructure via projects is difficult.  

When you have a project-based cost account it is difficult to fund the building of general use infrastructure.  NYU - not just money but staff resources that limit the growth of the infrastructure.  Building the skill set is also difficult - need to back-fill with contractor support.

Michigan State - huge project that they used to fund an Identity Management infrastructure projects - (modernization of their HR and Accounting system).

Chicago - Project Management Office sees the value of common solution that crosses many projects.   They agreed to the benefit of the common solution across the many projects and agreed to fund the work as part of one of the projects.

Brendan and USC - focus the work around the directory steering committee.  Governance body made up of a number of leaders from around the university.  If someone brings forward and activity, others are found that many others are doing the same thing.  This can lead to a recognition that this is a central IT service.

Maximum transparency within and across the institution can bring these core items to the surface 

Central IT and the Architects need a foundation of trust and transparency.  

Hebért - how do you reach the middle managers outside of committee work?  Keith - really leverage the working groups you are on.  Jim - I spend time at the Registrar's Office and I walk around and talk with those mid-level managers.

Places to Catch Enterprise Core Activities

Project Management Office that has a vision across  many projects can see that they are funding the same activity across many projects

Governance bodies that see similar requests from several groups 

1 Comment

  1. Question:  You have published standards and architectures.  A CxO type picks a vendor that doesn't fit.  How do you deal with that.
    • SLU : ARB review - document it the fact: who made the decision, that it is outside the standard
    • UW-M : Gentle conversation of the fact that it doesn't fit.  Mention that they are not aligned and try to get on their roadmap to get them aligned with the standard.