Planning_and_Impleme.. - didier beck weblog

More documents

Recommendations

Info

Planning and Implementing SOA www.butlergroup.com At SOA maturity, the organisation will start to be able to dynamically optimise processes based on the visibility of data. By the SOA transformation phase, a deeper understanding of data requirements will become apparent. Business Activity Monitoring (BAM) should be starting to be used in this phase so that the organisation can see, on an up-to-date basis, where there may be performance issues. At SOA maturity, the organisation will start to be able to dynamically optimise processes based on the visibility of data. New data sources and types may need to be introduced, but the architecture will have been defined to enable swift incorporation of new data services that can then be used in conjunction with existing ones. Control and Governance At the investigation phase, most organisations will want to pay scant attention to control and governance issues, but although a heavy handed approach is likely to be unnecessary, a degree of governance will be required early on. The right organisational structure to mandate and govern the development of services will need to be worked out, including establishing ownership of services. Without good governance, there is a risk that services will be created to satisfy whims that are not genuine business needs. By the development and deployment phase, organisational structures including roles and responsibilities must become more clearly defined. Understanding what is expected of the various parts of the organisation – and this is not only the IT function – will be important to ensure adequate control is there. Policies should start to become visible by this stage, Change management, which will already have started to become an issue, needs to be resolved during the SOA transformation stage. Whilst in an ideal world services should be carefully defined up-front to avoid change, in the real world change may be needed, and will need to be managed and governed. Tools to assist will have developed in maturity by this time (there are already many available today). Once an organisation moves into the SOA maturity phase, the concept of dynamic governance will start to become real. For this to happen, it must be possible to examine what messages are being routed through the organisation, measure response times, and take corrective action dynamically if there are any issues. Infrastructure During the investigation and discovery phase, organisations will need to look at their infrastructure and modernise it to put certain basic elements in place. It may be possible to reuse an existing messaging infrastructure, and layering Enterprise Service Bus (ESB) technology on top is likely to be a route that many organisations will already be investigating. An area to watch here is the growth of the open source Infrastructure requirements will evolve during the move to SOA, and by the SOA transformation phase, it will be necessary to develop a comprehensive service management infrastructure... Change management, which will already have started to become an issue, needs to be resolved during the SOA transformation stage. technology stack, which may provide a useful way of testing out options with lower investment. In the development and deployment phase, organisations should start to use the idea of a services registry and/or repository. This will help with some of the governance issues, as well as ensuring that all participants understand what services are already available. Here it will also be valuable to develop an understanding of the business rules that are already present, but that are embedded deep in multiple business systems. These must be separated from those core systems to enable business users to make modifications to them easily. Infrastructure requirements will evolve during the move to SOA, and by the SOA transformation phase, it will be necessary to develop a comprehensive service management infrastructure that overlaps with, and reflects the business services that are in use. By this phase, SOA infrastructure tools must be merging with the other IT service management tools and techniques that are in place today; for example, there is likely to be significant overlap between a Configuration Management DataBase (CMDB) and service registries that should be resolved during this phase. 10 Section 1: SOA Deployment December 2006
www.butlergroup.com Planning and Implementing SOA By the SOA maturity phase, the real dynamism that SOA can offer should start to become feasible, with an autonomic service infrastructure allowing services to be identified and accessed on-the-fly. Forecasting how infrastructure is likely to change so far into the future is like gazing into a crystal ball, but a policy-based solution is likely to support this model the best. Development Methods One of the key needs of the investigation and discovery phase will be to acquire service-oriented expertise. This may be easier said than done, since it requires a move from functionality and application-oriented thought and design processes to a service-oriented one. It will also be vital to have a broad understanding of current systems and technologies; it is unlikely to be wise to buy external SOA skills at the expense of upgrading internal skillsets. This change of emphasis will need a significant human change management effort. During the development and deployment phase, we would expect organisations to be moving on from pilot projects towards a reasonable degree of service development and reuse; this is where it will be apparent that the different domains are inter-related, since without the other horizontal areas keeping up, it would be all too easy to develop runaway services that do not suit business needs. Essentially, a service serves; the questions to be resolved at this phase are how, where, why, when, to whom, and if it is needed at all? Although a few composite applications exist today (for example SAP, together with some of its partners, have created what they refer to as X-APPS, which link together several services both from within SAP’s application and external to it), Butler Group does not see a significant move to this paradigm until organisations are ready to move to the SOA transformation phase. Here, it is anticipated that composite application development will become much more commonplace, and large, single-purpose applications will gradually reduce. In the SOA maturity phase we will start to see rapid application assembly, where composite applications are the norm – in fact they are created and then overtaken by new ones from the underlying services which become available. This will need service creation to be fully understood throughout the organisation. The IT function will need to support the composition paradigm fully, with graphical composition tools in the hands of business-facing experts. SOA may not be the appropriate architectural model for all systems. Whilst SOA holds the promise of flexibility, agility, and potential for future cost savings, it may not be the most appropriate architectural model for all systems. Where complex transactions are involved that need tightly coupled links between the various phases of the transactions, a SOA is unlikely to be a suitable model, particularly if very high volumes of transactions are involved with high performance requirements. Stateful, long-running, orchestrated business conversations are not well-suited to a SOA approach, as the management of such complexity is beyond SOA, certainly at the moment. Where an application is very self-contained and structured, and components have been designed to be tightly coupled, there is little advantage in breaking it down into services that are insulated from each other. Additionally, where an organisation has recently implemented a new enterprise application, such as an ERP system, which is in widespread use throughout the organisation and is starting to meet its transactional and informational needs, there is little relevance in even considering SOA. However, the vendors of most of the major enterprise applications are certainly paying serious attention to SOA – they are facing many of the problems, such as rigid processes, that SOA can address. It is therefore likely that future versions of such applications will be service-enabled, and permit choice in how the individual services are assembled in the future. Where only one or two applications are in use in a homogeneous IT environment, and they are not likely to change, imposing a SOA would add unnecessary overhead at this stage. Organisations may want to start investigating SOA within the next year or two, to establish if it is likely to have any benefits for them – and even so, there may be no apparent need to change for the foreseeable future. In cases such as this, service orientation might be an appropriate model for new functionality, particularly when external partners and collaborations may be relevant. The book ‘Mashup Corporations’ has some examples illustrating this usage of SOA for new projects. December 2006 Section 1: SOA Deployment 11
Page 1 and 2: Technology Management and Strategy
Page 3 and 4: www.butlergroup.com Planning and Im
Page 9: 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?