The Role of the Architect. The Role of the Architect

Transcription

1 The Role of the Architect Jason Bloomberg Senior Analyst ZapThink, LLC Take Credit Code: ROLEARCH Copyright 2006, ZapThink, LLC 1 The Role of the Architect Design Governance Project Management Organizational Issues Copyright 2006, ZapThink, LLC 2 1

2 Challenge: SOA is Architecture Copyright 2006, ZapThink, LLC 3 What is Architecture? The fundamental organization of a system embodied by its components, their relationships to each other and to the environment and the principles guiding its design and evolution. (IEEE P1471/D5.3) Copyright 2006, ZapThink, LLC 4 2

3 The SOA Metamodel Business Model Service Model Service Metadata Implementation Models SOA Metamodel is a model of models: Business Model, Service Model, & Implementation Models Service model is abstract representation of Requirements for Services Services in production Model actualized in Service contracts and other Service metadata Copyright 2006, ZapThink, LLC 5 Service Model Drives Contract-First Development Service contracts specify required functionality to IT and provided functionality to the business Service model represents the clearinghouse for information about IT environment Contracts go beyond WSDL: Usage policies Security policies Consumer delivery contracts Service-level agreements, etc. Copyright 2006, ZapThink, LLC 6 3

4 SOA Foundation: The 4+1 View Model Logical View Functional requirements Implementation View Components Information View Use Case View SOAs Data View Process View Processes Deployment View Platforms Copyright 2006, ZapThink, LLC 7 SOA Foundation: The Zachman Framework Copyright 2006, ZapThink, LLC 8 4

5 The Zachman Framework (cont.) Copyright 2006, ZapThink, LLC 9 SOA & Zachman DATA FUNCTION NETWORK SOA Copyright 2006, ZapThink, LLC 10 5

6 SOA & Zachman (cont.) Business Entities SOBAs The Internet The Organization Business Change Business Strategy Semantic Model Process Model Service Network Users Service Lifecycle Governance Framework Logical Data Model Service Model Service Infrastructure Service Consumers Events Policies Physical Data Model Component Architecture System Architecture UI Services Messages Rules Schemas Components Network Nodes Identities Elements Assertions Copyright 2006, ZapThink, LLC 11 The Service Model: Processes Source: IBM Copyright 2006, ZapThink, LLC 12 6

7 The Service Model: Building Business Services Source: IBM Copyright 2006, ZapThink, LLC 13 Organizational Issues Copyright 2006, ZapThink, LLC 14 7

8 Building the right SOA team Shared Services cross organizational boundaries Siloed IT management styles are becoming obsolete The new role for enterprise architects Copyright 2006, ZapThink, LLC 15 Where Do You Find Enterprise Architects? Enterprise Architects (EAs) must have the big picture of the relationship between business & technology Some are more technical, some are more business-oriented, many organizations put both types together on a team Typically rise through ranks internally, because of need for intimate knowledge of business Supplement EA team with consultants, but don t let consultants drive EA Copyright 2006, ZapThink, LLC 16 8

9 Building Support for SOA Find your champion May be LOB manager, CIO, managementlevel architect, or other architect Build the business case Solve business problems while transitioning to new architecture Tackle project iteratively within context of overall plan Copyright 2006, ZapThink, LLC 17 Change Management Issues Organizational change more challenging than technological change Keep business focused on TCO Focus on human aspects of change management (education, etc.) Copyright 2006, ZapThink, LLC 18 9

10 The Ivory Tower Problem Architects create design and other artifacts, but don t have the authority or mandate to require their use Development team considers them optional Business likes idea of architecture in principle, but short-term needs trump best practices When architects are external consultants, the not invented here syndrome makes the Ivory Tower worse Copyright 2006, ZapThink, LLC 19 The Power of the SOA Center of Excellence SOA experts who maintain a knowledge base of best practices General and company-specific Design time and runtime Drives SOA policy (either explicitly or implicitly) Can unify approaches across a large organization Copyright 2006, ZapThink, LLC 20 10

11 Enabling Service Domains A Service Domain is a logical grouping of shared Services with a common business context Examples: customer-facing Services, purchasing-related Services Manage Services by managing the Domains Move away from traditional IT silos for the purposes of managing Services, but retain technical teams as needed Copyright 2006, ZapThink, LLC 21 The Roles of SOA Business Stakeholders Logical View Functional requirements Component Architects Developers Implementation View Components Information Specialists Information View Enterprise Use Case Architects View Use Case SOAsView SOAs Data Experts Data View Business Analysts LOB Experts Process View Processes Systems Experts Deployment View Platforms Copyright (C) 2004, ZapThink, LLC Copyright 2006, ZapThink, LLC 22 11

12 The Role of the Architect: Governance Copyright 2006, ZapThink, LLC 23 SOA Governance in the Narrow Governance of SOA initiative Design time governance Are developers and other personnel following the policies that apply to Services? Runtime governance Are running Services and SOBAs conforming to runtime policies? Copyright 2006, ZapThink, LLC 24 12

13 SOA Governance in the Broad Policy management SOA configured & controlled via metadata, including policy Visibility Services abstract heterogeneous data sources, providing necessary business intelligence Flexibility Ability to build Services that address compliance issues and adjust them as regulations or business needs change Not just governance of SOA governance in the context of SOA Copyright 2006, ZapThink, LLC 25 Project Management Copyright 2006, ZapThink, LLC 26 13

14 IT Governance Feedback Loop > Delivery of architectural guidelines and supporting materials > Governance over project-specific selection of architectural materials > Traceability of architectural materials used within a project > Feedback on effectiveness of architectural materials Source: LogicLibrary Copyright 2006, ZapThink, LLC 27 Project Management for an SOA Project Pilot project much like a standard IT project, because business Services not yet in place. As your SOA matures, you must shift to a more agile, model-driven approach that requires more flexible project management. Basics of project management won t change (resource management, client management, schedule/dependency management). Project managers will have to deal with larger, more diverse teams. Maintaining agility requires the project manager to change the project plans over time more frequently. Key to keeping SOA projects on track: measurement of key indicators Quality indicators Governance indicators Other indicators Copyright 2006, ZapThink, LLC 28 14

15 The Relationship with Portfolio Management SOA rollout projects vs. ongoing Service lifecycle projects Break up SOA rollout into individual projects, based on iterative approach showing business value at each step Plan for ongoing change New Services New versions of Services Ongoing reconfiguration of SOBAs, policies, etc. Copyright 2006, ZapThink, LLC 29 Architectural Visioning Session Attendees: architecture team, business analysts responsible for business processes Provide the SOA perspective Processes drive the Services, Services drive the technology Split into two initiatives: process definition followed by Service definition Balance big picture with realistic pilot starting point Copyright 2006, ZapThink, LLC 30 15

16 Key Elements of Successful SOA Projects Building the right SOA team A diverse group that bring different perspectives and wide-ranging support to the implementation Handling organizational/people issues Human resistance to change more challenging than the technical issues Tackling the project iteratively Won t have full spec as you get started Managing the Service lifecycle Very different from the traditional software development lifecycle (SDLC) Copyright 2006, ZapThink, LLC 31 ZapThink is an advisory, analysis, & influence firm focused exclusively on Service- Oriented Architecture, Web Services, & XML. Thank You! Read our new book, Service Orient or Be Doomed! How Service Orientation Will Change Your Business. Jason Bloomberg jbloomberg@zapthink.com Copyright 2006, ZapThink, LLC 32 16