Nitin Singhal SOA Tech Sales

Nitin Singhal SOA Tech Sales
SOA and Enterprise Architecture: A Natural Convergence Nitin Singhal SOA Tech Sales Good Afternoon, Ladies & Gentlemen, Today organizations are standardizing across the enterprise and using techniques which allows alignment of business and IT. Enterprise Architecture is one way of linking the overall business strategy to architectural models which capture business intended structures. SOA is an enterprise-scale IT architecture for linking resources on demand. These resources are represented as business-aligned services which can participate and be composed as processes to fulfill business needs. SOA & EA, both require input based on business objectives and produce outcomes that are measured against these objectives. Furthermore, both aim to address issues on the enterprise level (strategy and planning, reference architecture, and so on), and at the same time their governance models are similar.

Agenda Enterprise Architecture … why should we care?
SOA and Enterprise Architecture Best Practices for Enabling SOA at the Enterprise Summary

Enterprise Architecture Bridges the Gap Between Business and IT
Strategy Information Technology Strategy Business Opportunity Business Strategy Technology Availability Enterprise Architecture Business Architecture Processes Information People IT Architecture Applications Information Technology Enterprise wide focus Planning Transition Plan EA Governance There are many depictions of EA and Zachman was really the first. What you see here is a framework developed as part of the IBM Academy of Technology Study on EA that addresses all the concepts. Enterprise Architecture Supports Business and IT Drives Business and IT Strategy Enables Architectural Planning Linking Business and IT Objectives Results in IT Solution Design and Delivery Enabling SOA within the EA mission enhances SOA success Alignment of business and IT Separation of concerns Reusability of applications and information Connectivity Service lifecycle management Governance Infrastructure FEAF — Federal Enterprise Architecture Framework TEAF — Treasury Enterprise Architecture Framework DoDAF — Department of Defense Architecture Framework NASCIO — National Association of State Chief Information Officers Business Operating Environment and IT Infrastructure Project focus Design and Delivery IT Solutions

EA is more than Architecture
EA is more than just architecture, it includes architecture, governance, and a roadmap. Roadmap really defines things we should do, Architecture defines the way things need to be done and Governance ensure, let me see how should I put it, that there is still sanity in what we are trying to do and we are in the right direction.

EA Context Business Environment Business Model Assets Governance
(external influences) Customers, Regulators, Market, ... EA Context influences value Business Model Intent (strategies, drivers, principles, plans), Value (products & services), Capabilities, Business Processes, Information Model, Business Roles & Locations, ... Assets Governance Architecture Management Framework Leadership Sponsorship Ownership Resources Charter Structure Vision Principles Roles & Responsibilities Processes NFRs Roadmaps Metrics … People, Process, Technology Architecture Models Reference Architectures Infrastructure Packages Tools & Processes Services Skills … influences feedback Update Enterprise Architecture Business, Applications, Information, Technical, Governance influences feedback Solution Architectures (many, including SOA) Reuse Solution Architectures (many, including SOA) Particularly note: The whole picture — the overall goal is to ensure that technology improves business effectiveness in fulfilling its intents, responding to external influences, succeeding with its offerings, and adding value to the business. The downward path involves links of the business model, through EA architecture, solution architecture, to result in actual technology that reflects the initial intent. The feedback path involves ongoing iteration in the architectures and possibly the business model (e-business and e-BOD). EA is mainly focussed on Business Model and Enterprise IT Architecture, and Governance — this project focuses on a subset of the Enterprise IT Architecture. Comment on the need for an appropriate strategy for an asset repository — also note that the WP-centric focus facilitates retention and reuse of assets. Also note the significance of Solution Architecture approach — this is how the EA is ultimately implemented. Solution Architectures (many, including SOA) influences feedback Information Applications Infrastructure

SOA means different things to different people
Roles A model of the business and related key performance indicators Business An architectural style which requires a service provider, requestor and a service description. It addresses characteristics such as loose coupling, reuse and simple and composite implementations. Architecture A programming model complete with standards, tools, methods and technologies such as Web services Implementation Slide Objective: “SOA” is a concept that is viewed differently by various people depending on their roles in the organization. The Enterprise Architect, however, must view SOA across all these perspectives and provide the expertise and knowledge that allows these perspectives to bridge cohesively for the good of the business. Details: The most important characteristic of SOA is the flexibility to treat elements of business processes and the underlying IT infrastructure as secure, standardized components (services) that can be reused and combined to address changing business priorities. An Service Oriented Architecture includes all these aspects: An architectural style and a design principle for application development and integration. A way of designing software systems to provide “services” to end-user applications or to other services. A natural evolutionary step to the object-oriented (OO), procedural, and data-centric approaches adopted for solution implementation till now. When creating an SOA system, individual services are typically implemented using one or more of these technologies. The integration of applications and information sources through the exchange of information based on common semantics or a vocabulary used to define the structure of such information exchange. A set of architectural principles and patterns which address characteristics such as modularity, encapsulation, loose coupling, separation of concerns, reuse, composable and single implementation. So when we look at the SOA vision we need to look at 3 aspects: The business view of a service – what is needed to support the business process The Architecture view of a service – how do we define and design these services The implementation view of a service – how do we implement the service through component deployed on the technical infrastructure The most important characteristic of SOA is the flexibility to treat elements of business processes and the underlying IT infrastructure as secure, standardized components (services) that can be reused and combined to address changing business priorities. Services are the building blocks Packaging business functions from new and existing applications in a simple and standardized way creates services that are available for use Services are used to help get the right information to the right people at the right time Services can be reused and combined to deploy composite applications to address new opportunities Increasing use of “Web” services based on open standards complements existing services technology A set of agreements and contracts among service requestors and service providers that specify the quality of service. Operations

SOA Solution Stack SOA is composed of processes, services, and components. At the heart of the SOA is the service model that defines services and components that realize them. This partially layered architecture shows how composite services are aligned with business processes, while enterprise-scale (large-grained) components realize the services. This architecture is supported by several vertical layers, including: An infrastructure layer that's commonly referred to as the Enterprise Service Bus (ESB). A monitoring and management layer to ensure the quality of service and to achieve nonfunctional requirements. A data architecture layer. A governance layer.

Enterprise Architecture: SOA Aspects
Intent: Ensuring SOA links to business value propositions Solution Architecture: Designing SOA Solutions Component Approach: Enabling a building block approach Governance: Processes, roles and responsibilities Planning: Planning/prioritization of SOA programs Development: Building/composing SOA Solutions Operations: Management of SOA-based runtime solutions Deployment: "Publishing" SOA solutions and Change Management Transition: Moving from "As-Is" to the "To-Be" SOA Environment It's obvious that the SOA domains are a subset of the EA domains. For example, SOA is not concerned with the development of business architecture. Instead, it uses the outcome of business processes and other business architecture artifacts, such as Component Business Modeling (CBM), as input to identify business services. In contrast, EA is concerned with the development of business architecture, including business processes and CBM among others. Similarly, from an Application Architecture point of view, SOA is concerned with the modeling and development of services and the components that realize them, while the EA architecture deals not only with SOA-specific artifacts, but with other components, packages, and systems for the whole enterprise.

Components in an Enterprise Architecture

Mapping Solution Approaches to an EA
When analyzing the Technology Architecture, the SOA ESB is just one of many integration mechanisms an EA may need to address. Note also that SOA doesn't address Content Management Architecture, while EA does. Another area of overlap is security and service management. In fact, SOA security is a special case of the total security that EA must specify, and SOA Service Management and Monitoring is a subset of Systems Management that EA must deal with.

SOA-Based Enterprise Technology Framework Application Architecture

Application Architecture – Banking
Integration Layer Management Application Development Channels Layer Electronic Self service Branches Call Center Mobility Partners Protocols Functions Components Availability Presentation Layer Authentication Access Control Content Collaboration Personalization E W ID management Services Layer S e B b Transport S e r Atomic Services Composite Services v c i Change Management s e ( B S P O Directory management Components Layer M A P Routing Business components s b o Quality Management e r Credit Investments Banking Applic. CRM Insurance H T T P Configuration s ( Transformation Data UDDI Repository , ) Architecture Control Loans Treasury Payments Risk and Compliance Credit Cards M Q o u Benefits: Business alignment is maintained by defining a service interface that suits/aligns with the business view and not with existing legacy assets. The Service component maps between the two worlds. Supports implementation substitutability because service component may be replaced without impact on the consumer. Offloads the XML processing burden from systems that are often paid for on a MIPS consumed basis. (assuming the service component runtime is not co-located with the backend system) A service may be implemented using behavior from more than one system, the service component aggregates the behavior to realize the service. Issues: Longer deployment cycle than Direct Access because thought must be given to the definition of the service interface and time must be spent developing the service component. More complex than Direct Access; often involves the use of connector/adapter technology between the service component and the backend systems. J M Common Components S ) Provisioning Portfolio and Process Control , Cash Management J Collecting Asset Mgmt M Transformation Product Accounting HR Auditing Legal S Messaging , H T T P Security Management s ( Information Layer ) u o Analytics Client/Product/Segment Views A a d Orchestration Workflow & E p Client History Client Relationship Client Catalog Product Catalog T a t BI DW Data Marts Information L d o s e r Monitoring

SOA and Enterprise Architecture: Best Practices
Are we still moving in the right direction? Are our target architectures still right? Are we doing these things the way we said we want them done? Determine the Governance Focus Plan Define Enable Measure Define the SOA Governance Model Implement the SOA Governance Model Refine the SOA Governance Model SGMM Enterprise Architecture Models Governance Transition Planning Project Prioritization & Planning These are the things we should do SIMM This is the way things should be architected << Input from Business Analysis >> <<Output to SOA Implementation >> SOMA Projects

Component Analysis The enterprise is mapped out as a set of categorized business components Heat map highlights components for analysis based on criteria such as gaps and efficiency Enables approaches to understanding how the business can be improved Business Administration New Business Development Relationship Management Servicing & Sales Product Fulfillment Financial Control and Accounting Directing Business Planning Sector Planning Account Planning Sales Planning Fulfillment Planning Portfolio Planning Controlling Business Unit Tracking Sector Management Relationship Management Sales Management Fulfillment Monitoring Compliance Product Management Credit Assessment Reconciliation Staff Appraisals FROM: Columns are Business Competencies, defined as large business areas with characteristic skills and capabilities (e.g., product development, supply chain). An Accountability Level characterizes the scope and intent of activity and decision-making at three levels: Directing is about strategy, overall direction and policy. Controlling is about monitoring, managing exceptions and tactical decision making Executing is about doing the work NOTE – Explain this … part of JK Enterprises – discuss the hot areas – how do you do a heat map… Look at PPI notes for more information (on Sales Day) Executing Account Administration Product Directory Credit Administration Sales Product Fulfillment Customer Accounts Product Administration Marketing Campaigns Customer Service Document Management Purchasing General Ledger Collections Branch/Store Operations

Service Integration Maturity Model (SIMM)
Silo Services Composite Virtualized Dynamically Re-Configurable Componentized Integrated Level 1 Level 4 Level 5 Level 6 Level 7 Level 3 Level 2 Applications Methods Organization Infrastructure Information Business Modules Process Integration via Services Dynamic Application Assembly Components Objects Structured Analysis & Design Service Oriented Modeling Business Grammar Component Based Development Object Application Specific Skills Emerging SOA Governance SOA and IT Infrastructure Governance Alignment Governance through Policy IT Governance IT Transformation SOA and IT Governance Alignment Process Integration via Services LOB Platform Specific Project-based SOA Environment Virtual SOA Environment Dynamic Sense & Respond Common Reusable Infrastructure Enterprise Standards Application Specific As a Service Data Services Semantic Data Vocabularies Canonical Models LOB or Enterprise Enterprise Data Dictionary and Repository Isolated Business Line Driven Business offers Services Geographically Independent Service Centers Mix and Match Business and Location Capabilities Componentized Business Process Integration Processes Through Service Composition Monolithic Architecture Emerging SOA Grid Enabled SOA Dynamically Reconfigurable Architecture Component Architecture Layered Architecture Common At IBM, we have been working on a maturity model and process for achieving desirable stages of maturity, a model called the Service Integration Maturity Model (SIMM). The level of de-coupling and amount of flexibility achievable at each stage of maturity are what make up the following seven levels of maturity: Silo (data integration) Integrated (application integration) Componentized (functional integration) Simple services (process integration) Composite services (supply-chain integration) Virtualized services ( virtual infrastructure) Dynamically reconfigurable services (eco-system integration) Each level has a detailed set of characteristics and criteria for assessment, and what follows is a brief description of the highlights of each level: Silo: The organization starts from proprietary and quite ad-hoc integration, rendering the architecture brittle in the face of change. Integrated: The organization moves toward some form of EAI (Enterprise Application Integration), albeit with proprietary connections and integration points. The approaches it uses are tailored to use legacy systems and attempt to dissect and re-factor through data integration. Componentized: At this level, the organization componentizes and modularizes major or critical parts of its application portfolio. It uses legacy transformation and renovation methods to re-factor legacy J2EE or .NET-based systems with clear component boundaries and scope, exposing functionality in a more modular fashion. The integration between components is through their interfaces and the contracts between them. Services: The organization embarks on the early phases of SOA by defining and exposing services for consumption internally or externally for business partners -- not quite on a large scale -- but it acts as a service provider, nonetheless. Composite Services: Now the organization extends its influence into the value chain and into the service eco-system. Services form a contract among suppliers, consumers, and brokers who can build their own eco-system for on-demand interaction. Virtualized Services: The organization now creates a virtualized infrastructure to run applications. It achieves this level after decoupling the application, its servcies, components, and flows. Now the infrastructure is more finely tuned, and the notions of the grid and the grid service render it more agile. It externalizes its monitoring, management, and events (common event infrastructure). Dynamically Reconfigurable Services: The organization now has a dynamically re-configurable software architecture. It can compose services at run-time using externalized policy descriptions, management, and monitoring. . The organization domain looks at the maturity of the enterprise and/or business units in the context of organization structure, processes, mechanisms, learning and knowledge enablement, and governance in support of service orientation. This includes the ability to deliver on changing business requirements.

Service Integration Maturity Model (SIMM)
Silo Services Composite Virtualized Dynamically Re-Configurable Componentized Integrated Isolated Business Line Driven Componentized Business offers Services Business Process Integration Business Service Decomposition Business Process Integration Processes Through Service Composition Geographically Independent Service Centers Mix and Match Business and Location Capabilities Business Application Specific Skills IT Transformation IT Governance Define & Enforce SOA Governance Emerging SOA Governance SOA and IT Governance Alignment SOA and IT Infrastructure Governance Alignment Governance through Policy Organization Structured Analysis & Design Object Oriented Modeling Move to SOA-based Design Methodology Component Based Development Service Oriented Modeling Service Oriented Modeling Service Oriented Modeling Business Grammar Oriented Modeling Methods Modules Objects Components Process Choreography Assembly Services Process Integration via Services Process Integration via Services Dynamic Application Assembly Applications Understand these are initiatives – and each implies several projects The business domain looks primarily at three things: the maturity of the business architecture, the relationship between business and IT and the business value achieved by moving to a service-oriented paradigm. We assess the business architecture and IT support of service orientation with the goal of improved reuse and flexibility, reduced complexity and time-to-market and in both business architecture and IT solutions The method domain looks at the maturity of the enterprise and or business units in their use of specific software (system) development method and process to support the SOA life-cycle and methods. This includes project management and project estimation considerations for the development of services, components and flows for the SOA life-cycle. The application domain looks at the maturity of the application portfolio to leverage service orientation. It focuses on the use of services for sharing and reuse of business functionality across business units and the ability to flexibly interchanging functionality to meet changing business needs. The architecture domain looks at the maturity of various levels of the architecture including, the enterprise and application architecture to support service orientation. The information domain looks at the maturity of the information and data architecture and management to support service orientation. It includes the notions of information as a service and the ability to apply best practices such as MDM and appropriate application of best practices such as Data Cleansing and Migration. The infrastructure domain looks at the maturity of the infrastructure, monitoring and management in areas of service monitoring and management, service security, and service virtualization. Designing the infrastructure to support the non-functional and operational requirements and service-level agreements needed to operate in a specific scope of the service eco-system. Monolithic Architecture Layered Architecture Component Architecture Focus on SOA Foundation Emerging SOA SOA Grid Enabled SOA Dynamically Reconfigurable Architecture Architecture Application Specific LOB or Enterprise Specific Deploy Common Information Services Canonical Models Information As a Service Enterprise Data Dictionary and Repository Virtualized Data Services Semantic Data Vocabularies Information LOB Platform Specific Enterprise Standards Common Reusable Infrastructure SOA Infrastructure Standard Project-based SOA Environment Common SOA Environment Virtual SOA Environment Dynamic Sense & Respond Infrastructure Level 1 Level 4 Level 5 Level 6 Level 7 Level 3 Level 2

Service Oriented Modeling and Architecture (SOMA) Links Business Intent with IT Implementation
<< Input from Business Analysis >> <<Output to SOA Implementation >> SOMA Service Identification Service Specification Service Realization SOMA gets inputs from business analysis activities, and produces outputs necessary for SOA implementation The analysis and modeling performed during SOMA is technology and product agnostic, but establishes a context for making technology and product specific decisions in later phases of the lifecycle IBM Method for developing Service Oriented Architecture based solutions SOMA creates continuity between the business intent and IT implementation by extending business characteristics such as goals and key performance indicators (or KPIs) into the IT analysis and architectural decisions. The outputs of business analysis and modeling efforts such as CBM are leveraged by SOMA to deliver an SOA solution. The analysis and modeling performed during SOMA is technology and product agnostic. Yet, it establishes a context for making technology specific decisions in later phases of the life cycle.

SOA Governance Lifecycle
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 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 Enable the Governance Model Incrementally Deploy governance mechanisms Deploy governance IT infrastructure Educate and deploy on expected behaviors and practices Deploy policies Monitor and Manage the Governance Processes Monitor compliance with policies Monitor compliance with governance arrangements Monitor IT effectiveness metrics

Implementing A Center of Excellence (COE)
Manage the SOA Lifecycle Change management including policies for publishing, using and retiring services Infrastructure to help govern access and monitor service vitality Provide SOA Measuring Best Practices Visibility to usage and project information Business and IT dashboards Provide Skills Transfer & Early Proof of Concepts Identify skills gaps and create development roadmaps Drive use of new technologies and techniques such as BPM Provide Architecture Vitality & Thought Leadership Continuously assess, refine and architecture framework and supporting assets based on internal & external influences Provide Architectural Authority Single point of accountability and communicates SOA best practices, assets, and patterns Center of Excellence A Center of Excellence (CoE) is The focal point and catalyst for the transformation and adoption of SOA A combined logical and physical grouping of resources – human, technical and intellectual – that represent leading edge and differentiated capabilities that are highly valued in the marketplace, A group of individuals recognized for their leading edge, strategically valuable knowledge, and mandated to leverage and/or make that knowledge available throughout the enterprise for SOA innovation. A community of semi-permanent teams of technical specialists, or people trained in a specific SOA skill and technical competencies that are the building blocks of organizational capabilities. A resource pool that can be tapped by the enterprise or line of business as new projects arise which will apply SOA principles. Conduct SOA Architecture Reviews Perform independent design and architecture reviews for key applications and infrastructure Define High Value Business Services Modeling business processes, information services Best practices for identifying and defining shared services Establish Decision Rights Service portfolio planning and organizational design Assets and best practices

Business & IT Lessons Start with the business – don’t lead with IT SOA solutions Difficult to ‘sell’ SOA business value by itself –need to focus on the business value of enterprise-wide reusable services Initially will have higher cost to develop for reusability when compared for a single project’s use SOA is not standalone – ideally be part of a comprehensive Enterprise Architecture SOA Governance required fairly early in the picture SOA acceleration should be a combination of top-down (Business) and bottom-up approach(IT) Don’t forget about enabling the infrastructure for SOA Start with the business – don’t lead with IT SOA solutions Be careful about the hype, SOA is not a silver bullet to solve all business problems Involve business subject matter experts as early as possible in projects, but they were often not available due to the demands of their work Process models of existing or to-be states were not always available Difficult to ‘sell’ SOA business value by itself – also need to focus on the business value of enterprise-wide reusable services Not easy to assign business ownership for enterprise-wide responsibility if a group doesn’t already exist with a mission for enterprise scope Project scope often hampers creating reusability for other projects (mission, schedule, resources funds, longer term support, business requirements) Gain experience first with smaller, non-mission critical services Derive gradual business value through Incremental deployment as opposed to big bang Higher cost to develop for reusability when compared for a single project’s use IT funding patterns can be difficult to change – previous / existing funds management processes can inhibit the growth of SOA (e.g., Silo funding) Cost recovery model to fund services and new requirements can be successful May need to also consider funding service consumers to migrate to the reusable services

Enabling SOA with IBM tools
WebSphere Business Modeler WebSphere Business Monitor WebSphere Business Svcs Fabric WebSphere Process Server DB2 Data Warehouse WebSphere Information Server WebSphere Customer Center Data Power WebSphere Service Registry & Repository WebSphere Transformation Extender WebSphere ESB WebSphere Message Broker Business Services Enterprise Service Bus Interaction Services Process Services Information Services Development Services Partner Services Business App Services Access Services Management Services Infrastructure Services Apps & Info Assets Lotus Collaboration Solutions Lotus Expeditor WebSphere Portal Rational Application Developer WebSphere Integration Developer Rational Software Architect Tivoli Federated Identity Manager Tivoli Access Manager Tivoli Composite Application Monitor Tivoli Identity Manager WebSphere Partner Gateway WebSphere Adapters WebSphere Application Server WebSphere Network Deployment WebSphere Extended Deployment

Summary SOA establishes an enterprise architecture that enables business flexibility and agility SOA is an important foundation of enterprise architecture Companies are using SOA today to drive tangible business value Investments in SOA will continue to drive competitive differentiation. SOA is not one-size fits all Implementation of SOA varies according to the company’s business / IT environment and goals Companies should leverage well defined best practices derived from SOA experiences to make the SOA journey effective Start small, grow fast, and drive successful implementation through effective governance Main Point: SOA changes the game and it is important to recognize that the solutions are built on a foundation – to be successful with Enterprise SOA, companies need to put these capabilities in place to enable the organization.

Remember – SOA Adoption Is A Journey
Main Point: SOA is a journey – go forth and conquer.

Thank you

Business Strategy Drives IT Decisions IT’s Goal is to Flexibly Support Business Requirements
Business Intent Meeting Strategic Goals? Business Strategy & Design Align Strategic KPIs Business Services Business Understanding Business Operations Meeting Business Commitments? Optimize Operation Models Business Performance Management Operation Models Solution Flexibility Solution Composition Response to Business Situations Correct Executable Solution Executable Solution Quality of Service Detecting Business Situations IT Implementation Monitor

Architectural evolution in the enterprise Business flexibility through technical agility
Services based architectures enabled by open standards is the next major computing shift 1980’s to mid 1990’s Mid 1990’s to early 2000’s Pre 1980 Today Future Monolithic Architecture Client-Server Architecture Network Centric Architecture Service- Oriented Architecture / Web Services Dynamically Re-configurable Architecture Mainframe Visual Basic PowerBuilder eBusiness eCommerce Service Oriented Computing Web Services Architecture Open Standards Key Point: SOA is NOT integration …. SOA makes integration solutions “better”

Business Components Defining Key Business Functions
Component Name Account Administration Resources: Account Data, CRM People: Call Center, Customers Technology: CICS Customer Account, SAP SLA/KPIs: Time to Open Account Description Functional aspects of administration including account opening, account management, account closure A business component is “a grouping of the people, technology, & resources delivering specific business value” Components have well-defined interfaces, allowing them to interact smoothly with each other and to be 'snapped' in and out at will, like building blocks” The Interfaces of the Business Components Enable Identification of Candidate Business Services FROM: Decompose an Enterprise into its constituent building blocks (business components) A component is a logical grouping of people, technology, and resources that delivers specific business value, and can operate independently Components allow for understanding interdependencies between parts of the business The output of this process becomes the input for SOA design Account Administration

SOA Security and Management Aspects
Service Registry and Version Management Validate the quality and accuracy of the contents in the service registry. Version management is carried out effectively Define SOA Governance Model Manage Existing Services Governance Ownership and Funding Models Security and Management Reg. New Service Creation SLA Compliance Monitoring Enforce the correct execution metrics for every service invocation Strategic Deployment Options Validate that services are configured to use the infrastructure most effectively Tactical In the “Define SOA Governance Model” initiative, we define the SOA Governance model for JKE, following the SGMM method. We adopt an iterative approach, focusing only on the details of the governance aspects that we address in the respective phase (the “Define SOA Governance Model” bar in the diagram should be composed of several iterations, each one addressing one or more governance aspects; we simplified the diagram showing a single bar that spans the duration of all the different governance initiatives). We use the SOA Governance Implementation Capability Pattern to visualize how both tactical and strategic aspects are addressed -- either in parallel or in different phases -- within our SOA Transformation effort. Security Management Services correctly implement security decisions for authentication, authorization, auditing, transport security, threat protection SGMM - SOA Governance and Management Method SOA Governance Implementation Capability Pattern

Nitin Singhal SOA Tech Sales

Similar presentations

Presentation on theme: "Nitin Singhal SOA Tech Sales"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Nitin Singhal SOA Tech Sales

Similar presentations

Presentation on theme: "Nitin Singhal SOA Tech Sales"— Presentation transcript:

Similar presentations

About project

Feedback