Planning_and_Impleme.. - didier beck weblog

More documents

Recommendations

Info

Planning and Implementing SOA www.butlergroup.com Governance can be split into design-time governance and run-time. Design-time governance covers service assets within a registry and/or repository. Such assets can include the service description (WSDL), documentation, schemas, namespaces, taxonomies, Business Process Execution Language (BPEL), and so on. One of the key aspects of designtime governance is the need to control what is developed, which should always be driven by the business need. One of the key aspects of design-time governance is the need to control what is developed, which should always be driven by the business need. One organisation found that when it identified a particular business-relevant service, and then investigated what existed that could be mapped to that service, it found that there were already some 20-odd versions of that service in existence – requiring significant re-design to consolidate. However, good governance must not stand in the way of innovation; it should seek to de-risk it. This will be one of the greatest challenges to the IT function – how to manage SOA carefully without restricting the organisation. Run-time management and governance will converge with traditional systems management. Standard IT systems management usually covers applications that operate on one platform, although of course there are already technologies that enable common management across several platforms. However, as an organisation starts to deploy SOA-based applications, management of an operational SOA will require additional thought and preparation. The major challenge for management of SOA is that the services may not all be within the same domain. Service management consoles are used to monitor and manage performance issues within an organisation’s infrastructure, but when a service could be running externally to the organisation, it is necessary to then establish performance metrics about that service in a standards-based manner. Run-time governance usually concerns the messages flowing across the message transport system, and usually relates to SOA policy and security management. However, run-time governance can also control elements such as routing and transformation – capabilities that can be performed by an ESB but could also be carried out by policy management. Run-time governance usually concerns the messages flowing across the message transport system, and usually relates to SOA policy and security management. The run-time management aspects cover logging (auditing), performance management, monitoring, and alerts. Such run-time management may be particularly relevant if a service fails to run as expected, allowing a request to be routed to a back-up or alternative service that is available, but which may have a different cost. An example of this might be a credit-check service. Usually the organisation might use a low-cost service, but if this is not available for some reason then it may be appropriate to access a more expensive alternative, or it may be preferable to wait until the cheaper one is available. Policies may need to be accessed here to help make the decision. Routing of messages may be used to perform load-balancing functionality in order to improve performance. For example, if some services had a very high service level defined, then it may be necessary for the SOA management infrastructure to hold back services with a lower Service Level Agreement (SLA) to enable critical services to be performed first in order to meet the required SLA, and also to send alerts if the critical SLA is breached. Many organisations will require the ability to define quality of service requirements for individual services, creating a graded service structure. SOA governance tools usually include the ability to define and maintain policies for service management. Some products on the market allow different qualities of service to be made available; for example, IONA’s Artix Enterprise Service Bus can be extended to provide quality of service capability, but is also available without this if service level monitoring is not required. One issue that is particularly likely to arise where a service is used by many third parties is the potential for it to become over-used, and here the SOA management offering will need to have the ability to ‘throttle’ services to restrict them in order to prevent it impacting others adversely. 16 Section 1: SOA Deployment December 2006
www.butlergroup.com Planning and Implementing SOA Management of SOA will need a console-style capability that crosses all the platforms that the services are operating on. Managing external services has to be included in this, and this is where standards for management will become necessary. We foresee that run-time service management and monitoring will become part of the whole IT Service Management area, but one that must be directly related to the business. Accountability within SOA must be driven by the presence of a sound audit trail indicating all interactions with a service. Service management tools need to be able to produce metrics which can then be analysed to provide feedback into the service lifecycle. This area is still in the early stages of development, but to enable a fully mature, service-oriented enterprise, the feedback loop provided by such analysis will illustrate where services can be improved and optimised. A clear definition of SOA roles and responsibilities supports good governance. Various roles will be needed within a successful SOA project. The governing body has already been discussed, but at a more detailed level, there will be a range of different roles that may be necessary, such as system administrator, operations, security officer, and business analyst. At a recent Webinar organised by the EbizQ Web site, participants were asked what formal governance roles were in use within their organisations. The results indicate that, whilst a number of organisations have not yet defined formal roles, many see that this is an increasingly important point. Role Percentage of respondents (multiple responses allowed) None 39.94% SOA Governance Officer 17.89% IT Governance Officer 31.31% Compliance Risk Officer 24.92% Security Policy Expert 40.58% Figure 8.3.1: SOA Governance Roles (Source: EbizQ) Security is currently seen as the most important formal role, with almost a third having an IT Governance Officer as well. The same survey then asked who was responsible for defining governance policies, with more conventional job titles as the selected options. Role Percentage of respondents (multiple responses allowed) Other 13.42% Policy Experts 52.08% Architects 63.90% Developers 14.38% Figure 8.3.2: Who Defines Governance Policies (Source: EbizQ) The role of the architect is clearly seen as an important one, with the majority of respondents seeing architects as having a significant role in the establishment of governance policies, with policy experts coming a significant second. December 2006 Section 1: SOA Deployment 17
Page 1 and 2: Technology Management and Strategy
Page 3 and 4: www.butlergroup.com Planning and Im
Page 15: www.butlergroup.com Planning and Im
Page 31 and 32: www.butlergroup.com Technology Mana

Planning_and_Impleme.. - didier beck weblog

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?