Facets that describe Enterprise Architecture at a given institution:

 This is a start on a model for describing how Enterprise Architecture / I.T. Architecture is structured and engages with the enterprise.

Organizational Models of Enterprise Architecture

  • Informal/ Ad hoc architecture - no formal architecture group.  Individuals acting as ad hoc architects in their areas
  • Isolated Architecture - a "more formal" architecture group but that group is buried in one department
  • Federated Architecture - Architecture deputies around campus working together to form a "enterprise architecture"
  • Head Architect with Domain Architects - like federated but with a central lead architect orchestrating the federation
  • Central Architecture - a core group of architects that review all projects in the enterprise

Other aspects that might affect positioning and organization models

  • Do you build or buy software - as a general rule is your institutions preference to build or buy
  • Do you outsource activities
  • Are you active in lots of open source projects
  • Do you have a Project Management Office
  • Do you have Portfolio Management Process

Facets that describe how you engage  (see Mark Poepping's Arch to Action document)

  • Where do you report:
    • Manager




  • Where is your range of effect:  Projects in
    • A group


      Multiple Deptartments

      Across Campus

      All Projects on campus

  • When do you engage with projects (based loosely on Enterprise Unified Process terminology)
    • At inception

      During Elaboration

      During Construction

      During Roll-out

      After Launch

  • Method of engagement
    • Pleading



      Project Review

      Project Gate

Organization's Operating Model

Which model most closely matches your organizations operating model (take fromEnterprise Architecture as Strategy by Ross, Weill and Robertson)

  • Distributed (few common business processes and little data integration)
  • Replicated (common business processes with little data integration)
  • Coordinated (few common business processes with high data integration)
  • Unified (common business process with high data integration)

Organizational Maturity Model

At which point in the maturity model would you say your organization is mostly at (also from EA as S)

  • Business Silos
  • Standardized Technology
  • Optimized Core
  • Business Modularity


  1. Organizational Models: don't fit Chicago's style of architecture.

    Control Points, Influence Points and Interaction Points 

    Portfolio Management Process:  is actually two things.  Service Portfolio Management and Active Project Portfolio Management.  Some frameworks include both.  But they are distinct in some shops.

    Which of us are actually doing true Enterprise Architecture rather than actually technology architecture as applied to the enterprise?  UW-Madison: we split our activities into two bins:  Technology and Policy/Process.  Vision, Governance, Staffing Skills - do we see that as part of our actions?  We are in at the requirements and capabilities needs.  We fade out at the build and roll-out point in time. 

  2. Paul Hill:  If your developer managers are rewarding "on-time and under-budget" rather than well Architected, then it is difficult to engage them.  Need to have rewards for engaging the architects early and well-designed applications.

    Tom Barton:  There is an economy here that we need to work within.  An architecture provides services that a project can take advantage of that reduces the net cost of the project.  Identity Management services are external so the developers don't need to build them each time.  Also need to keep the whole life-cycle of the project in view when making decisions.

    Activity Based budget models - it can look like it is cheaper to build your own IdM system rather than add the overhead of the central IdM system.

    Do best practices dictate that certain objects should not be charge-back based?  Sure but... 

  3. Discussion about Enterprise Architecture and Strategy - Jim's philosophy on the book.  Discussion about Instruction as a highly Diversified operational model.  Sakai as a framework that might support the highly diversified environment.   Pushes more towards a set of unified standards that allow for integration of multiple.