Planning_and_Impleme.. - didier beck weblog

More documents

Recommendations

Info

Planning and Implementing SOA www.butlergroup.com Not standardising SOA – this is especially relevant for larger organisations, where a number of different projects running in parallel could result in very differently designed services that cannot then be integrated or composed in the future. A way to overcome this would be to have a single proof-of-concept project to establish good practices that can then be spread throughout the organisation on future projects. Similar services may be developed in different regions of the organisation because information is not being shared. This will occur for organisational and political reasons but should be minimised by good governance. Not understanding SOA performance requirements – SOA is likely to introduce multi-layered processing, and certainly when Web services are used, there is a deep dependence on XML data representation. This can cause performance issues unless hardware is scaled appropriately and performance is considered at design time. One of the first essentials will be to set up the organisational structures in people terms to ensure good management and governance. Some of these issues can be overcome by good design, but a sound management and governance capability should be planned in from an early stage to avoid these issues. One of the first essentials will be to set up the organisational structures in people terms to ensure good management and governance. Who (as in ‘what department’, as well as ‘what role’) should be responsible for monitoring, defining, and authorising changes to existing services that will exist within an organisation? Some kind of internal governing body should be set up to take on this responsibility. However, there are alternative models – central and distributed. With central governance, the body should have representation from each of the areas that are affected by services (both technical and business, including subject matter experts), and it will be wise to have an independent arbitration function as well to help resolve issues. This governing body will then review proposed new services, approve the removal of unused services, and where appropriate, changes to existing services. A distributed governance approach would involve each business unit having its own body to monitor services that are relevant to that business unit. A distributed governance approach would involve each business unit having its own body to monitor services that are relevant to that business unit. This is likely to be more appropriate for a highly distributed organisation that already has autonomous management. Whichever model is suitable (and a mixed model may be appropriate), the role of the governing body is to define good practices and standards for services, including the architectural and procedural guidelines for their use, and to oversee their deployment. Some of the key questions that arise around SOA management and governance include: Who has access to services? Who is allowed to create them? How do you write new versions of that same service? What happens when they are updated? What are the rules and polices around upgrades? Good metadata management is also a key part of successful SOA. Defining the standards to be used, for example for different data elements (such as in identifying a customer, which may have a customer ID for internal use to uniquely identify a customer, and a customer login ID which is used by the customer to access a service) is important. The data dictionary concept beloved by mainframe systems is actually a highly beneficial model – providing clear and accessible information about what data is, and how it should be used within the organisation. Where services cross organisational boundaries, it will be necessary to then use agreed standards (such as Electronic Data Interchange (EDI) standards, Interactive Financial Exchange (IFX) standards, and so on). 14 Section 1: SOA Deployment December 2006
www.butlergroup.com Planning and Implementing SOA The Role of the Registry One of the problems that arose with early Web services was around service identification, with frequent stories of services being ‘discovered’ through discussions around the coffee machine or in passing in the corridor. Services could rapidly become far more popular than anticipated and performance may become an issue. Equally, services could have been created that served no business need, and were therefore not used. It is vital to define a common central store for information about services – often called a registry. A registry can be used for much more than simply keeping basic information about services – it can be used both at design time and run-time so that policy-based information can be dynamically accessed at run-time for detailed control. The service registry can support sophisticated dependency and impact analysis. The service registry can support sophisticated dependency and impact analysis. Even though a service should be self-contained, it may still impact another when used in a composite application. In addition, it will be valuable to identify which services interact with one another when the need to modify a service arises – if too many services might depend on it, this could be an occasion when it is appropriate to create a new service that has some similar functionality, rather than create a new version. An area that will be interesting to watch over the coming months will be what happens in the area of CMDBs. Today, these are used in the IT service management arena to maintain and manage information about various IT-related assets – and services can equally be regarded as assets, just as applications and systems are at the moment. The Service Contract When two parties agree to do business with one another, it is very wise to set up a contractual agreement that covers what the provider will deliver, and what the consumer expects. The same applies within a SOA; it is sound practice to define the contract and obligations between consumers and providers, and these will be interdependent. Often the service definition (as given in the Web Services Definition Language (WSDL) for a Web service) is regarded as sufficient, but in practice rather more will be necessary. There are a number of other things that need to be documented about a service’s agreement with its consumers, such as run-time performance expectations, who to call if the service breaks, charging models (if any), etc. SOA Lifecycle Management Within the applications area, we are seeing the emergence of the concept of Application Lifecycle Management (ALM), which covers the lifecycle of applications from origination through to deployment and on to retirement. Services will need a similar degree of control throughout their lifecycle; something will trigger the creation of a service, and eventually it may need to be removed from service as it is no longer needed. Within ALM, change management is a particularly complex area. In SOA, version control is a highly contentious issue. Delegates at a recent Butler Group Masterclass on SOA had some robust discussions on whether a service should be able to have multiple versions or not. The conclusion of the debate was not unequivocal – most services are likely to change over time, and the change should be reflected by the creation of a new version. However, a service that could be used in a very longrunning business process might need to be kept stable. The important thing is that the service interface should not change unless the version changes – minor details of how the service operates could, in theory, be accommodated without a version change. Lifecycle management issues cover service development, testing, staging, and production. Moving from one phase to another can be a complicated challenge, and the move for mainstream application management vendors to acquire the more specialist SOA management vendors is likely to prove beneficial here. Design-time Management and Governance A building relies on having good foundations – no matter how good a quality the bricks, doors, windows, and the construction itself, if the foundation is not sound then there is a risk that the building will collapse if the strain becomes too great (for example, if there is an earth tremor). The same metaphor can be applied to services – if a really ‘cool’ service is developed and proves highly popular, overuse of that service could cause the whole infrastructure to grind to a halt. Some of this will be down to the platform but the majority comes down to good governance and management. December 2006 Section 1: SOA Deployment 15
Page 1 and 2: Technology Management and Strategy
Page 3 and 4: www.butlergroup.com Planning and Im
Page 13: www.butlergroup.com Planning and Im
Page 31 and 32: www.butlergroup.com Technology Mana

Planning_and_Impleme.. - didier beck weblog

Create successful ePaper yourself

Delete template?

Save as template?