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

2. 8/10/20042 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…

3. 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

4. 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

5. 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

6. 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

7. 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. 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

9. 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

10. 8/10/200410 Architectural decision factors Ability to Execute Technique Mission Institutional Goals Customer Requirements Standards Practices Products Budget Staff Skills/Expertise Goal Management Governance

11. 8/10/200411 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?

12. 8/10/200412 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

13. 8/10/200413 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

14. 8/10/200414 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

15. 8/10/200415 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

16. 8/10/200416 WAG us Please contact: Michael Gettesgettes@duke.edugettes@duke.edu Scott Fullertonfullerton@doit.wisc.edufullerton@doit.wisc.edu David Wasleydavid.wasley@ucop.edudavid.wasley@ucop.edu Tom Bartontbarton@uchicago.edutbarton@uchicago.edu Michael Gradym-grady@uiuc.edum-grady@uiuc.edu Mark Poeppingpoepping@cmu.edupoepping@cmu.edu

17. 8/10/200417 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.

18. 8/10/200418 “Architecture” www.webster.com 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 www.poepping.org architect one who creatively assembles known components with known behaviors

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

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

21. 8/10/200421 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

22. 8/10/200422 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?”

23. 8/10/200423 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

24. 8/10/200424 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