TOGAF 9 Soa Governance Ver1 0


Published on


No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

TOGAF 9 Soa Governance Ver1 0

  1. 1. Summarised - 2010
  2. 2.  Ser vice Oriented Architecture (SOA) as an architectural style  Factors relating to the adoption and deployment of SOA within the enterprise  Correspondences between SOA and TOGAF terminology  The definition and structure of service contracts
  3. 3.  New stress points are created around understanding the relationships between technology portfolio and service portfolio  New stress points are created around SLA definition, governance, and impact management  New stress points are created around tracing business to IT  New stress points are created around communication, alignment, and semantics  New stress points are created around platform and interoperability  New stress points are created around performance visibility and optimization
  4. 4. Defines Structured traceable representations of business and technology shows how ser vices should be links SOA designed and stakeholders how platforms together must interoperate provides consistent Defines principles, Enterprise abstractions of high-level constraints, strategies and frameworks, project Architecture patterns, and standards deliverables shows which services should be built and provides a link how they from business should be re- to IT used links many different perspectives to a single business problem providing a consistent model
  5. 5.  Function: A function is a thing that a business does. Ser vices support functions, are functions, and have functions, but functions are not necessarily services. Ser vices have more specific constraints than functions.  Business Service: A business service is a thing that a business does that has a defined, measured interface and has contracts with consumers of the service. A business service is supported by combinations of people, process, and technology.  Information System Service: An information system service is a thing that a business does that has a defined, measured interface and has contracts with consumers of the ser vice. Information system services are directly supported by applications and have associations to SOA ser vice interfaces.  Application Component: An application component is a configured and deployed system, or independently governed piece of a configured and deployed system. Application components provide information system services. Application components can be physical applications and also logical applications that group together applications of a similar type.  Technology Component: A technology component is a piece of software or hardware that can be purchased from an internal or external supplier. Technology components are configured, combined, built on, and deployed in order to produce application components.
  6. 6. TOGAF Phase SOA Concept Benefits to a SOA Initiative Preliminary The TOGAF framework provides a meta model Using TOGAF will provide a direct linkage and process that is capable of incorporating both between business-led and developer-led business-led and developer-led SOA concepts in communities, initiatives and benefits within a holistic framework an organization Architecture Vision The TOGAF ADM includes specific steps to TOGAF Business Capability Assessments address SOA concerns, including: provide an opportunity to look at the • Consideration of business capability — which business services that exist or are desired capabilities are most valuable, volatile, and and how these business services can be differentiating for the business? realized. •Consideration of technology capability — how The TOGAF Technology Capability technically mature is the organization and how Assessment provides an opportunity to mature does it desire to be? look at technology risk and maturity, •Consideration of IT governance impacts — what The TOGAF IT governance assessment impacts is the Architecture Vision going to have provides an opportunity to identify SOA on current IT governance models? related governance impacts. Business Architecture The Business Architecture phase elaborates the Business services are explicitly identified capabilities of the business and defines explicit and tied to ownership, usage, and business portfolios of business services, accompanied value, forming the detail of a business led by ser vice contracts that formalize ser vice SOA strategy in a way that can be linked consumption into a developer led world. Information Systems The Information Systems Architectures phase Information system services are explicitly Architectures shows how the identified business services identified and tied to business service, data map to applications and data encapsulation, and applications, elaborating a high-level framework for developer-led SOA implementation.
  7. 7. TOGAF Phase SOA Concept Benefits to a SOA Initiative Technology Architecture The Technology Architecture phase shows how SOA technology architectures are application capabilities identified in the developed with traceable reference to: Information Systems Architecture are mapped •Business ownership and value onto SOA platforms and off-the-shelf SOA •A defined organizational position on services, providing a blue print for baseline and target technology maturity implementation •Service contracts that identify service consumers, SLAs, and non-functional requirements for services •Landscape visibility of how technologies will support deliver y of applications and information system services •Consideration of the IT governance model, requirements, and issues Opportunities & Solutions The TOGAF ADM allows for identification of Development of a multi-disciplinary Migration Planning improvement opportunities and then selection, Architecture Roadmap allows SOA prioritization, and sequencing of those capability to be incrementally developed, opportunities according to architectural analysis including proof-of-concept, pilot, and and stakeholder need. mainstream SOA enabling. Implementation Governance TOGAF provides specific processes for design TOGAF identifies the need for design governance during the implementation of an governance, which can include SOA design architecture. governance. This approach provides a framework in which to apply an organization’s standards, guidelines, and specifications to implementation projects. Architecture Change TOGAF allows for implementation issues and Lessons learned from proof-of concept Management external factors to be incorporated into the and pilot activities can be leveraged and architecture, allowing the overall approach to be used to shape the strategy from a bottom- refined. up perspective.
  8. 8. Service Qualities and TOGAF Service Purpose of a Governance Service Considerations Contract
  9. 9. Governance Operational Contract Contract between two business entities which which specifies the actual communication specifies what interaction is needed, inputs, protocols and message formats outputs, SLAs, OLAs, and KPIs The service contract specifies the quality and integrity of the interaction between services. This specification allows the development of service- level objectives (irrespective of whether they are formalized into an SLA). Ser vice contracts for m an important insight to developing the critical operational path, and they set the quality and security benchmarks for Application and Technology Architecture components.
  10. 10. Attribute Type Attribute Description General Reference A unique identifier within the architecture information for cross-reference, clarity, and differentiation from other similar artifacts. General Name A suitable, preferably unique, short form name for the artifact General Description Name of the service. Should indicate in general terms what it does, but not be the only definition. A narrative of what the artifact is, what it does, and its relevance to the architecture. General Source The source of the artifact, which may be a person or a document, along with a date to support traceability of the architecture General Owner The owner of the artifact is the name (person or group) who validated the details of this artifact; the person/team in charge of the service. General Type The type of the service to help distinguish it in the layer in which it resides; e.g., data, process, functionality, presentation, functional. General Version The version of the service contract. Business RACI Responsible: The role is the person/team responsible for the deliverables of this contract/ser vice. Accountable: Ultimate decision-maker in terms of this contract/ser vice. Consulted: Who must be consulted before action is taken on this contract/ser vice. This is two-way communication. These people have an impact on the decision and/or the execution of that decision. Informed: Who must be informed that a decision or action is being taken. This is a one-way communication. These people are impacted by the decision or execution of that decision, but have no control over the action. Business Ser vice name ‘‘caller’’ Name of the consuming service. Business Functional Requirements The functionality in specific bulleted items of what exactly this service accomplishes. The language should be such that it allows test cases to prove the functionality is accomplished Business Importance to the What happens if the service is unavailable process
  11. 11. Attribute Type Attribute Description Business Contract control How the contract will be monitored and controlled. requirements Business Result control How the results of the service will be monitored and controlled requirements Business Quality of service Deter mines the allowable failure rate Business Ser vice Level Deter mines the amount of latency the service is allowed to have to perform its Agreement actions. Non-Functional Throughput Volume of transactions estimated; e.g., 100,000 Requirements Non-Functional Throughput period The period in which those transactions are expected, e.g., 100,000 per day Requirements Non-Functional Growth The growth rate of transactions over time (estimated based on service take-up and Requirements business growth); e.g., 10,000. Non-Functional Growth period The period in which the growth is estimated to occur ; e.g., 10,000 per year Requirements Non-Functional Ser vice times The available hours/days the service is needed; for example, 9 to 5 Monday to Requirements Friday (excluding Bank Holidays). Non-Functional Peak profile short term The profile of the short-term level of peak transactions; for example, 50% increase Requirements between hours of 10 to 12 am. Non-Functional Peak profile long term The profile of the long-term level of peak transactions; for example, 50% increase Requirements at month end. Non-Functional Security requirements Who can execute this service in terms of roles or Requirements individual partners, etc. and which invocation mechanism they can invoke Non-Functional Response requirements The level and type of response required Requirements
  12. 12. Attribute Type Attribute Description Technical Invocation The invocation means of the service. This includes the URL, interface, etc. There may be multiple invocation paths for the same service. There may be the same functionality for an internal and an external client, each with a different invocation means and interface. For example, Sales App, events triggers, receipt of a written request for m. The service end point address to which the invocation is directed should be included. Technical Invocation preconditions Any pre-conditions that must be met by the consumer (authentication, additional input, etc.). Technical Business objects Business objects transferred by the service Technical Behaviour characteristics The criteria and conditions for successful interaction and any dependencies (on other ser vice interactions, etc.). This should include any child services that will be invoked/spawned by this service (in addition to dependencies on other services).
  13. 13.  TOGAF Version 9, The Open Group Architecture Framework (TOGAF), 2009
  14. 14. If you have one last breath use it to say...