Planning_and_Impleme.. - didier beck weblog

More documents

Recommendations

Info

Planning and Implementing SOA www.butlergroup.com The move to SOA will take many years for the majority of organisations. It is all very well establishing a roadmap, but a question that is often asked is how long will SOA take to be a normal business/IT paradigm? As with any other forecast of the future, this is a challenging question. Certainly, some large organisations are starting to understand that things are unlikely to stay as they are, and the benefits of service orientation imply that it will be a good model to follow. The four phases that we discussed are likely to take a number of years for any organisation, even the most flexible and agile out there. Some organisations are already starting to work on phase one – educating themselves about SOA; in fact this has already been underway for two or three years now in early adopters. Where SOA is likely to gain limited uptake for a number of years to come is in the mid-market – here, we are still seeing a continual shift away from standalone applications that only cover a small part of the business, enhanced by a ‘sticky tape and string’ collection of applications, spreadsheets, and e-mail, towards more integrated ERP systems. For these organisations to then be told they need to break up these applications into services seems like a backward step. Mid-market companies and other medium-sized organisations (for example, in the Public Sector) are far less likely to be even thinking about what SOA might mean for some time yet – and when they do they will not appreciate being pushed into making decisions by the vendors. Not all organisations will either want or be ready for SOA. Careful strategy can help to future-proof SOA developments. As with any new technology idea, the suspicion is that hype is rather more than the content, and it will soon be replaced by ‘the next big idea’. Butler Group believes that the terminology, SOA, might be superseded, but that the concept of a service-oriented organisation is very much the model of the future. Having said that, there are steps that organisations can take to ensure that any work they do on SOA projects will still be relevant as technologies and business challenges change in the future. Process Discovery and Modelling The way that organisations have evolved has frequently been very hit-and-miss, as management structures grew to cope with the changing business environment. Developing a thorough understanding of what the business processes are within an organisation will be valuable, whatever happens in the future. Adoption of Technical Standards Standards are often seen as an invention by vendors that can lag a number of years behind what the vendors themselves are offering – witness the number of vendors that add ‘extensions’ to standards in order to provide specific capabilities. What is probably as important as understanding the wider technical standards is at least picking what works for the organisation, and promoting the use of those within the organisation. De facto standards can be as relevant in the real world as those that are formally ratified by the various standards bodies, as this indicates widespread adoption. Participation on standards bodies may be a major commitment but will at least provide end-user perspectives directly to the standards process, and should be considered by organisations that can afford such commitment. Maximising the Level of Abstraction Whenever business-relevant information is buried within technology and tools, it becomes harder to change, requiring the relevant skills and knowledge to do so. Wherever possible, this needs to be abstracted to the highest level possible to make it much easier to change, and reduce the skills required to make that change. This approach is highly consistent with SOA. A Solid Architectural Framework There is a myriad of tools and technologies on the market for SOA-enablement, and organisations need to take care to understand the underlying architectures within them to avoid lock-in wherever possible. Creating a solid architectural framework for the organisation, based on its own needs, skills, and future plans, will help to ensure that work done for SOA projects is relevant to these internal requirements. 12 Section 1: SOA Deployment December 2006
www.butlergroup.com Planning and Implementing SOA The Role of Business Rules Business rules is one of those phrases that is reasonably understood, even if not always well-defined. Separating out such business rules from the tangled web of code where they are usually buried, is a valid exercise that will repay efforts whatever architectural style is the current trend. Rules should be visible, manageable, and therefore under the control of business people rather than technologists. Creating Generic Interfaces The major problem with many older technologies is that the interfaces to applications were often hardcoded with those applications, making it necessary to amend significant amounts of code any time a change was needed. Separation of interface from application is already a feature of n-tier architectures that is still valid in a SOA approach, and will still be relevant in the future. Future-proofing SOA can be achieved by continuing to create generic interfaces to older applications. SOA MANAGEMENT AND GOVERNANCE CATALYST Once services start to be deployed, the joint issues of SOA management and governance will demand attention. It is wise to plan for this early on in a SOA project, otherwise there is a risk that SOA will not deliver its expected benefits. SUMMARY Left unmanaged, services can rapidly degenerate into a tangled mess. Run-time management and governance of SOA will converge with traditional systems management. A clear definition of SOA roles and responsibilities supports good governance. Standards for SOA governance are beginning to emerge. ANALYSIS Governance can be regarded as the discipline of managing desired outcomes through structured relationships, policies, and procedures. Good SOA governance should make it easier for organisations to do the ‘right’ things and harder for them to do the wrong ones. Governance can be achieved by creating and then enforcing machine enforceable policies across the service lifecycle, from design time through to run time, and especially when services need to be changed. Left unmanaged, services can rapidly degenerate into a tangled mess. The key difference that Butler Group has identified between successful SOA projects and ones that fail to deliver benefits is in the area of good management and governance. Without a good human management infrastructure, even the best technology solution is likely to allow services created on it to degenerate into a confused set of services that do not get well used. Thomas Erl, in his book “Service-Oriented Architecture: Concepts, Technology, and Design”, lists a number of common pitfalls in adopting SOA: Building SOA in the way that distributed architectures have been built – this can introduce problems such as a proliferation of Remote Procedure Call (RPC)-style service descriptions, the creation of services that cannot then be composed with others, and the creation of non-standardised services. December 2006 Section 1: SOA Deployment 13
Page 1 and 2: Technology Management and Strategy
Page 3 and 4: www.butlergroup.com Planning and Im
Page 11: 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?