Governance, Policies / Principles Specific Topic: ESB versus Broker

Transcription

1 Dr. Hans-Peter Hoidn Distinguished IT Architect (Open Group certified) Enterprise IT Architectures Governance, Policies / Principles Specific Topic: ESB versus Broker

2 Agenda of Governance (50 Minutes) Governance SOA Governance Policies / Principles Followed by Specific Topic : ESB versus Broker 2

3 Governance 3

4 Claim Data Business TRB User Project Architect or DA Arch Review Board IT Steering Committee Business Requirement Identified Architecture Initiative Yes Design Conforms to Architecture? No Yes Arch Conforming Alternative available? No Vitality Process Enterprise IT Architectures Governance One of the 3 aspects of Enterprise Architecture Implementing the EA Architecture Transition Governance Business Architecture Channels Interface s Security s Applications Common Application s Common System s Network s Platform s System Management s System & Infrastructure Development Information architecture Component architecture ARB Data architecture IT architecture TRB Models Principles Enterprise Tech Framework Transition Plan Management Action Plan Organisation Processes Evaluation & Selection DA 4

5 Governance Keeps Enterprise Architecture alive Strategy Business Opportunity Business Strategy Information Technology Strategy Technology Availability Enterprise wide focus Planning Enterprise Architecture Business Architecture Processes Information People Locations IT Architecture Applications Data Technology Ensures Vitality Transition Plan Project focus Design and Delivery Business Operating Environment and IT Infrastructure IT Solutions 5

6 Governance: Introduction Comment Governance is Roles and responsibilities, Processes Governance matters Realizing business benefits, Business process flexibility Improving time to market Mitigating business risk Improving team effectiveness by measuring the right things and communicating clearly between business and IT Hint: Align Governance to C -management procedures Act as Enabler not Inhibitor 6

7 What is Governance? Establishing chains of responsibility, authority and communication to empower people (decision rights) Establishing measurement, policy and control mechanisms to enable people to carry out their roles and responsibilities Corporate Governance IT Governance EA Governance SOA Governance 7

8 Governance involves balancing the key aspects of relationships and processes on a foundation of communication THE WILL THE WAY Ø Trust Ø Charter Ø Alignment Ø Organization Ø Responsibilities Ø Principles Ø Communication Ø Processes Ø Behavior Ø Roles & Respon. Ø Culture Relationships Processes Ø Ø Metrics Tools Communication 8

9 Enterprise IT Architectures The Governance and Roadmap areas are nested in IT and Enterprise level work 9 Enterprise Governance Enterprise Plan / Roadmap IT Governance IT Roadmap Architecture Governance Architecture Roadmap

10 Governance A balanced approach Optimal Target based on Requirements Unstructured Free-for-all Unrepeatable process No metrics No documentation Relies on heroes Governance Balanced Repeatable process Measurable Documented and used Continuously improved Too Structured No room for creativity Bureaucratic and slow Too many metrics Policy & procedure excess Often ignored / undermined 10

11 Governance affects many decision-makers Business Units Executive Committees Technology Briefings Operations Business Direction and Opportunities Approvals & Resources IT Direction and Opportunities Architecture Blueprint Architectural Vision, Transition & Vitality Guidance, Standards & Direction Architects Architecture Leadership Sponsored issues and opportunities Architecture Implementation Projects/Solutions Life Cycle Levels, Issues & Escalations Special Task Forces Technology Scans, Assessments, Labs, Metrics, Issues, on demand Architect Design Develop Test Implement 11

12 Governance Organizational Context Business Strategy IT Strategy Enterprise wide focus Enterprise Transition Plan ARB Architecture Review Board Gap Analysis Business Model Governance Architectures ITA Arch. Principles Architecture EAF Solutions focus ACRT Architecture Compliance Review Team Business & Technical Solutions (Projects) "Solution Life Cycle" Deployable Unit 12

13 SOA Governance 13

14 Governance! Importance by Illustrating Control Sales Accounting department Legal x x App. 1 x App. 2 x Order fulfillment x Currency conversion service x Purchasing 1. Provide a currency service that fills a specific line of business (LOB) 2. Other LOBs start using the service 3. LOBs increase use of services / quality suffers 4. is fixed at provider s expense 5. Fix works temporarily but problem reappears 6. Maintenance costs soar / provider ends service * Scenario from Introduction to SOA Governance, Bobby Woolf. 14

15 Governance within the SOA Lifecycle Discover Construct & Test Compose Integrate people Integrate processes Manage and integrate information Gather requirements Model & Simulate Design Financial transparency Business/IT alignment Process control Manage applications & services Manage identity & compliance Monitor business metrics 15

16 SOA Governance Life Cycle Addresses Key Questions How do we govern and manage the Life Cycle of services? What standards do we need to establish and when? What processes do we need to identify, develop, deploy and manage services? How do we govern and manage our SOA Identification, development and deployment approach? What can I reuse from my existing IT Governance Model? What metrics and key performance indicators will we use? What is our SOA Vision and Strategy? How does the registry and repository get used? What controls are necessary? How do we measure our model and the effectiveness of services? Who manages the s Repository? Who uses it? 16

17 SOA Governance Lifecycle How to establish? Plan the Governance Need Document and validate business strategy for SOA and IT Assess current IT and SOA capabilities Define/Refine SOA vision and strategy Review current Governance capabilities and arrangements Layout governance plan Define the Governance Approach Define/modify governance processes Design policies and enforcement mechanisms Identify success factors, metrics Identify owners and funding model Charter/refine SOA Center of Excellence Design governance IT infrastructure Monitor and Manage the Governance Processes Monitor compliance with policies Monitor compliance with governance arrangements Monitor IT effectiveness metrics Enable the Governance Model Incrementally Deploy governance mechanisms Deploy governance IT infrastructure Educate and deploy on expected behaviors and practices Deploy policies 17

18 Governs the Consumers as well as the Provider Provider Consumer Eligibility Account Creation Eligibility V2.1 Account Creation V1.0 Level Definition Level Agreement Level Definition Endpoint Endpoint 18

19 Example: Defining the Governance Solution Tailor Methodology Execute the JKE SOA Governance Project Identify SOA Business and IT Principles Determine Existing Governance Structure Define CoE Structure Create Project Proposal Create the SOA Governance Framework Implement Tools and Infrastructure WebSphere Lotus Rational Tivoli Roles Processes Policies 33% 10% Metrics Quality Gates Refine Operational Environment 19

20 Interaction Between the Lifecycles Lifecycle Policies quality gates controls metrics standards are defined in the Governance lifecycle (for different aspects of Governance) and they are enforced in the service lifecycle Governance Lifecycle metrics are captured to improve governance process 20

21 The Governance Framework (Extensions to Development Processes) All the elements that we need to add to make a process well-governed Policies Roles 33% 10% Metrics Processes Quality Gates non-governed process well-governed process 21

22 Example Enforcement at Development Time exception procedure Implement that failed Litmus test human decision policy s should be reused instead of created whenever possible registry lookup quality gate new roles new activities s must be compliant with the existing reference architecture review 22

23 Example Enforcing Reuse Policy During the Identify s activities, the SOA Architect implements the Reuse policy searching for existing services Planning Define Focus Identify Owners Modeling Identify s Specify s 1 Implementation Design s Assemble s 3 4 Management Manage Quality of Manage Levels 11 At the Validate Design quality gate the policy is enforced Define Funding Realize s 2 Test s Deploy s Manage Change Manage Security Policy 1 Quality Gate 4 s should be reused instead of created whenever possible Validate Design, semi-automatic enforcement during development 23

24 Example Enforcing Architecture Compliance Policy The SOA Architect implements the Compliance with the Reference Architecture policy during all the activities in the Modeling phase Planning Define Focus Identify Owners Modeling Identify s Specify s 1 Implementation Design s Assemble s 3 4 Management Manage Quality of Manage Levels 11 At the Validate Design quality gate the policy is enforced with a manual review of the service model Define Funding Realize s 2 Test s Deploy s Manage Change Manage Security Policy 2 Quality Gate 4 s must be compliant with the existing reference architecture Validate Design, manual enforcement during development 24

25 Governance at Development Time Enforcing Policies of s Life Cycle Ensure Compliance and Define Policies 1 state transitions are defined based on governance solution 2 Validate Ownership 3 5 Registry Lookup to enforce reuse of existing services Publish to repository after Litmus test is successful WebSphere Registry and Repository 6 Add a Policy for Dynamic Binding Publish Find Enrich Manage Govern Analysis and Design 4 Validate Design for Standards Compliance 25

26 Policies / Principles 26

27 Terms (again) Definitions (Wikipedia, Oxford Dictionary) Policy: A policy is a principle to guide decisions and achieve rational outcomes. A policy is a statement of intent, and is implemented as a procedure or protocol. Presidential executive orders, corporate privacy policies, and parliamentary rules of order are all examples of policy. Policy differs from rules or law. Principle Defines the underlying general rules which an organization will use to make decisions about the selection, utilization and deployment of all business and IT resources and assets, across the enterprise. A fundamental truth or proposition that serves as the foundation for a system of belief or behavior or for a chain of reasoning. 27

28 Policies / Principles: Introduction Comment Policies / Principles The terms not used consistently, Policies often legally binding, Principles internally. Both defining underlying general rules which an enterprise will use to make decisions They should be well expressed (Name, Description, Motivation, Implication) Hierarchy: Guiding Ps down to Detailed, Company down to Coding Ps. Hint: let C -management express Guiding Principles / Policies and explain how well they are handled (see Example) 28

29 Example Guiding Principles / Policies Early Iteration Guiding Principle Investigate TCO, ROI, and Risks Description One of the element of risk management is that small suppliers should provide access to the code. Reuse standard before buy standard before reuse non-standard solution before build internal solution Simplify the portfolio of applications and reduce the complexity of the environment Standard is very important, reuse is the second choice but reuse of non-standard could be very costly and risky. Market applications (packet solutions) as seen as standards. This also applies to processes etc. Complexity of environment includes challenging the business requirements in order not to implement unnecessary functions. Do not reinvent the wheel use assets Manage Information/Data as a corporate wide asset 29

30 Policies / Principles must be at a consistent level, provide guidance and not dictate how things should be Defining Principles - Rules, Guidelines A good principle: States a fundamental belief of the enterprise in one or two clearly written sentences. Recommends an action against which some arguments could be made. Has relevance to a technical architecture. Is worded directly and simply in terms understandable by both business and IT managers. Has business wide applicability. Is durable; will not be outdated quickly by advancing technology. Has objective reasons for advancing it instead of the alternatives which were considered. Has impacts which need to be documented. Represents change A poor principle: Makes a statement which no one would dispute. Is a general business or financial statement. Has little or no general applicability. It may actually select a standard or a technology. Is stated at too low a level of detail and may not endure. May be included "because I say so". 30

31 Special Topic: ESB versus Broker 31

32 ESB versus (Message) Broker Enterprise IT Architectures Both 32 Intermediary, Transformation of Data Often both are introduced as concepts For both (named) products are availabl ESB (Enterprise Bus) Transfer of Protocols, Routing (Message) Broker Managing of Queues, Emphasis on lows Closer view: ESB intermediary for messages this is a higher abstraction than a broker concept of queuing ESB may include a Broker, a Broker can be used as ESB Broker needs on both sides the same installed software (aka EAI Enterprise Application Integration)

33 Illustration of (Message) Broker Information Flow Queue Queue Queue Queue Queue 33

34 Recap: ESB (Enterprise Bus) Virtualization ESB acts as an intermediary (proxy) between requestor and provider ESB provides service virtualization of Location and identity Interaction protocol Interface Interactions are decoupled, supporting separation of concerns 34

35 ESB Multi-protocol Exchange Intermediary decoupling heterogeneous consumers and suppliers Tooling Domain of interest - Intranet Exchange WebSphere (WAS/ Portal) SOAP/JMS SOAP/JMS WebSphere provider.net Client SOAP/HTTP SOAP/HTTP.NET provider Some Client XML/HTTP ESB XML/HTTP Some provider XML/MQ COBOL Copybook/MQ XML/MQ Client CICS Text/MQ Text/MQ Client 35

36 Example of ESB use: Multiple Channel Access to Backend Integration Developer Review Export and Import Review Export and Import Build mediation flows Build mediation flows Deploy Module Deploy Module ESB Account System Java Client Appl High Value Accounts J2EE Appl SOAP/ HTTP XML/ JMS Export (ACT) Export (HVA) Component Eligibility Mediation Transform Request/Response Business Transform Objects Log Message Infos Request/Response Determine Eligibility Module Import HQ Eligibility SOAP/ HTTP Applicant Eligibility J2EE Appl 36

37 ESB is today s technology Enterprise IT Architectures EAI Queues Lines of maintainable code Direct Connectivity ( middleware (No Connectivity, mediation & custom adaptation logic Application Message Queuing / CORBA Connectivity logic Mediation & custom adaptation logic Application Enterprise Application Integration Connectivity and mediation logic Custom adaptation logic Application Enterprise Bus Connectivity, mediation & custom adaptation logic Application as a service All connectivity, mediation and custom logic buried within the application. Removes the connectivity logic from the application Removes the connectivity + mediation logic from the application Reduces application to its core business functions ( service (i.e. a Reduced development and maintenance; increased flexibility and reuse 37

38 38