architecting it: the role of catalyzing increased coherence across systems and services tom barton,...
Post on 21-Dec-2015
216 Views
Preview:
TRANSCRIPT
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
top related