Architecting IT: The Role of Catalyzing Increased Coherence Across Systems and Services Tom Barton, University of Chicago Michael Gettes, Duke University

8/10/ 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/20043 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/20044 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/20045 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/20046 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/20047 … 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/20048 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/20049 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/ Architectural decision factors Ability to Execute Technique Mission Institutional Goals Customer Requirements Standards Practices Products Budget Staff Skills/Expertise Goal Management Governance

8/10/ 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/ 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/ 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/ 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/ 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/ WAG us Please contact: Michael Scott David Tom Michael Mark

8/10/ Architecture 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 ) 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/ “Architecture” ar·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·tect Etymology: from Greek architektOn master builder mas·ter an original from which copies can be made architect one who creatively assembles known components with known behaviors

8/10/ IT Architecture Not-exactly-known Components Uncertain Behaviors, Complex Interactions Not New but Not Commonly Understood

8/10/ Thesis Domain-specific Architectures become their own stovepipe Focus on Institution IT Architecture

8/10/ 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/ 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/ 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/ 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