Architecting IT: The Role of Catalyzing Increased Coherence

Across Systems and Services

Tom Barton, University of Chicago

Michael Gettes, Duke University

8/10/2004 2

30 second sales pitch• We all have primary IT areas that tend to be organized to

address the needs of their respective constituencies. We now require technical and policy alignment within and among these areas in order to better leverage infrastructure and application capability to the benefit of all IT areas and the institutional mission.

• The set of services that we are asked to provide require a level of complexity tending to exceed what our organizations have been trained to do.

• We need architectures and architects to help address these complex business, policy and technology problems spanning all IT disciplines.

• So, if you believe this pitch…

8/10/2004 3

Working Architects Group

• WAG(v1): initial design: Jan 2004– Poepping (CMU), Barton (Chicago), Fullerton (Wisconsin-

Madison), Gettes (Duke), Grady (UIUC), Wasley (UCOP)

• What brought us together– Similar roles, ambiguities, uncertainties, Scotch– Group therapy

• Our goal – better understanding of our discipline– Architecture issues and requirements– Institution architect applicability– Common issues, range of motion– Role/approach/skills/value

8/10/2004 4

What do you need?

• Services Meeting Institutional Mission– it’s not about the technology

• Technology: to effectively deliver services• Flexibility: to adapt to changing landscape• Scalability: to the institution and beyond• Reliability: it should all just work• Vendor Independence: not being cornered• Organization: people to deliver the above

8/10/2004 5

What do you want?

• Architectures describing how things should work together.

• Evolve the organization to respond to architectures and integrate services

• Our world is complex and we want to offer it more simply to our communities

• Be successful applying IT without making it about IT

8/10/2004 6

Common issues. “More of …”• More automation, more applications, more data

– More services:config mgmt, courseware, collaboration tools, repository, portal, integrated data, …

– More service providers: central IT, distributed IT, peer institutions, vendors, partners

– More constituencies: traditional and “loosely affiliated”– More security: combat viruses, spam, & identity theft– More granular access: roles, authorization– More locations: off site, partner, our peers, mobility– More coordination: information sources, service

providers– More privacy: identity vs. anonymity– More availability: performance, diagnostics

8/10/2004 7

… and “Less of …”

• For users– Less hassle: fewer credentials, easier access to tools

& information– Less interruption: “just works” 7x24

• For providers– Fewer moving parts: common infrastructure, fewer

systems, interfaces, & transformations– Less duplication of activities: organize around

common infrastructure– Less risk: ability to achieve security and service

objectives across services and providers

8/10/2004 8

Some components• Institutional Data

– ERP + SIS, but also clubs, projects, parking...– Other “data-of-interest”

• Network Connectivity, Registered Devices, Performance

• Middleware– Services

• SSO, Identity/Attribute Management, Authorization, Service Location…

– Methods• Web Services, Standards, Environments• Structured Design – leverage building blocks

• Diagnostics– Management Console – Network plus Services

8/10/2004 9

Institution Architecture & Architect

• Institution Architecture Should– Rationalize Strategies, Focus/Balance Priorities– Inform, Influence Decisions– Improve Predictability

• Institution Architect– Role

• Leverage Skills in Your Organization• Complement Management Team• Manage Influence

– Capabilities - “Broad Depth”• Technical – Network, Security, Middleware, Systems, Application• Customer – Requirements Elicitation, Service Definition• Social – Organizational, Inter-personal, Writing, Presentation• Management – Planning, Tracking, Financing, Negotiation

8/10/2004 10

Architectural decision factors

Ability to Execute

Technique

Mission

Institutional Goals Customer

Requirements

Standards

Practices

Products

Budget

Staff Skills/Expertise

Goal

Management

Governance

8/10/2004 11

Discussion

• Do you also see a need for a new type of IT discipline to help us meet new service requirements?

• What are some of its common themes and variations? How do you handle it? – Responsibilities– Approach to Integration– Style/Skills of the Architect– Organizational Placement– Measurement of Value

• Should an effort continue to define this discipline? Now/later? Participation? Venue?

8/10/2004 12

Sample Responsibilities

• Create and Maintain an Architecture– Artifacts/Processes/Templates– Standards/Roadmap/Vision– Team-based Creation (no vacuum)– JIT aspects – respond to Emerging Issues

• Technology/Product Development• Opportunities – Edict or 900lb Gorilla

8/10/2004 13

More Responsibilities

• Communicate and Interpret the Architecture– Evangelize and/or Intervene– Translate, Transform, Project– Consult on Project Definition (discovery)– Consult on Implementation (delivery)

• Integrate the Architecture– Across Drivers; Between Domains; Over Time– Help to set Priorities for Operational Agenda

8/10/2004 14

Style/Skills

• Broad Expertise, Pattern-Matcher• Write, Speak, LISTEN• Walk a Fine Line

– Proclaim/Consult– Expert/Strategist– Gadfly/Catalyst– Leader/Facilitator

• Other…– Tom’s Fomenter, Scott’s Omnigraffle Jockey– Michael’s Panache– A descent spellor

8/10/2004 15

Organizational Placement

• Relationship to Management Structure

• Relationship to Strategic Implementation

• Reach: IT-local or Institution-wide

• We are:– An Individual Reporting to CIO– A Small Group Reporting Below the CIO

8/10/2004 16

WAG us

• Please contact:

Michael Gettes gettes@duke.edu

Scott Fullerton fullerton@doit.wisc.edu

David Wasley david.wasley@ucop.edu

Tom Barton tbarton@uchicago.edu

Michael Grady m-grady@uiuc.edu

Mark Poepping poepping@cmu.edu

8/10/2004 17

Architecture

• http://www.whitehouse.gov/omb/memoranda/m97-16.html

This memorandum transmits guidance to Federal agencies on the development and implementation of Information Technology Architectures. The Information Technology Architecture (ITA) describes the relationships among the work the agency does, the information the agency uses, and the information technology that the agency needs. It includes standards that guide the design of new systems. An ITA makes it easier to share information internally (e.g., agency-wide e-mail) and to reduce the number of information systems that perform similar functions. The ITA provides the technology vision to guide resource decisions that reduce costs and improve mission performance.

8/10/2004 18

“Architecture”

• www.webster.comar·chi·tec·ture

1 : the art or science of building; specifically : the art or practice of designing and building structures …2 a : formation or construction as or as if as the result of conscious act b : a unifying or coherent form or structure

ar·chi·tectEtymology: from Greek architektOn master builder

mas·teran original from which copies can be made

• www.poepping.orgarchitect

one who creatively assembles known components with known behaviors

8/10/2004 19

IT Architecture

• Not-exactly-known Components

• Uncertain Behaviors, Complex Interactions

• Not New but Not Commonly Understood

8/10/2004 20

Thesis

• Domain-specific Architectures become their own stovepipe

• Focus on Institution IT Architecture

8/10/2004 21

Introducing the WAG

• What brought us together– Similar Roles– Similar Ambiguities– Similar Uncertainties– Similar Scotch

• Our Goal – Better Understanding– Architecture Issues and Requirements– Institutional Architect Applicability– Common Issues, Range of Motion– Role/Approach/Skills/Value

• Lots of Interest– Hard Problems, Expensive People

8/10/2004 22

What’s in it for You…

• Our and other CIO’s– Address Expanding Complexity (Velocity)– Increasingly Interdependent Domains– Gap in today’s approach

• Other Architects– Does this help you? Can you help?

• Our Peers are our Institution– “what’s that guy do anyhow?”

8/10/2004 23

The Gap:

• Interdependence and complexity• Convergence across disciplines• Complex New Interdependencies• Conflict in Domain-Specific Design

Patterns• New Trade-offs Across Disciplines• Language Barriers between Disciplines• New Security/Privacy Exposures

8/10/2004 24

What’s in it for Us

• Leverage in Collaboration– Strategy, Models, Method, Artifact– Technical Breadth

• Help in understanding all this stuf

• Benchmarking– Measurement, Improvement– Technologies

• Group Therapy