[B][URL=http://www.oreillynet.com/xml/blog/2006/08/soa_readiness_checklist_ten_cr.html]SOA Readiness Checklist: Ten Critical Factors for Achieving SOA Success[/URL][/B]
Thursday August 17, 2006 2:03PM
by [URL=http://www.oreillynet.com/pub/au/207]David A. Chappell[/URL] in [URL=http://www.oreillynet.com/xml/blog/articles/]Articles[/URL]
One of the best parts of my job is I get to travel a great deal to meet with a countless number of people to discuss their technology initiatives. Over the past couple of years in particular, I have traveled around the world several times and met with a cumulative of thousands of people consisting of architects, project leaders, Architecture VP’s, CTOs, and CIOs, all of which have been at varying stages of adopting SOA. This has usually been through a series of public SOA forums and through private meetings with individual companies. Sometimes it is with customers, and sometimes with users of other SOA infrastructure products. Sometimes it is with those who are not using any SOA infrastructure whatsoever and are still trying to figure out how to best embark on their SOA initiatives. In the SOA forums I often get a chance to engage in and facilitate a conversation with a room of people that consists of those who have successfully completed SOA projects who are explaining their success factors to those who are still trying to figure that out. I have noted a consistent set of themes which I have rolled up into what I will call the “SOA Readiness Checklist: Ten Critical Success Factors for Achieving SOA Success”
1. Have a vision. Through building a SOA that is best fit for your business, you are putting an architecture in place that will be pervasive across your enterprise and is going to prevail for decades to come. Create a vision and be well prepared to articulate it regularly and consistently. This may seem like a “duh”, but this is what helps you to build the longer term plan, and to gain support from other teams, from other departments, and from your upper management. I hear regularly from Senior level architects that they spend the majority of their time evangelizing and reinforcing their vision to their own people at all levels about what they are trying to accomplish. This is an ongoing process that continues even after the SOA projects are under way.
2. Identify reasonably scoped, attainable projects. Nothing speaks louder than a successful project that you can point at that didn’t run over time or budget or suck all available resources in the process. Choose something that has immediate value that you feel you can accomplish within a few months. This of course must be accompanied with the longer term vision. You gotta think big! But don’t try to “boil the ocean” on your first project.
3. Build Repeatable success patterns. As you accomplish your reasonably scoped projects, you should be learning as you go. Having a successful project or two gives you tremendous insight into what works well, and what things you could improve upon the next time around. One thing that I hear consistently across all those who have successfully built a SOA is that nobody gets it right the first time. There are always things that can be improved upon. The successful aspects of the initial project can be recognized, captured, and carried from one project to the next. These successful aspects may be software based, or may be organizationally based.
4. Align the software projects with the business problems that need to be solved. One thing I have learned from working with CIOs is that there are always plenty of primary business imperatives that top of mind for the CEO. These business imperatives usually have to do with improving operational efficiency, or increasing top-line revenue by attracting and retaining customers. Attracting customers may mean creating new products and services, and new marketing programs to reach them. Retaining customers may mean having the ability to quickly react to products, services, and programs being constantly introduced by your competitors. It may also mean improving customer service. These are all things that will require software systems to help implement and automate. Go and find those initiatives and you will ensure that your SOA projects get the attention they deserve.
5. Build Flexible business processes that meet the constantly changing needs of the business. This is another one that might seem like a “duh”, but it should be stated that the broader goal of the SOA project should be to create flexibility through loosely coupled services that can be put together to form composite applications that automate particular business functions. This is where the real benefit of SOA can be realized. As business requirements change, and functionality needs to get introduced, the business processes which are based on SOA must be capable of adapting to change more readily than those that are written as stovepipe applications, or those that were hard-wired together through coding web services directly.
6. Find a champion within the business. Another thing I have learned from working with CIOs and project leaders who have succeeded at their SOA initiatives is that nobody gets funding from the CFO and CEO anymore simply by going to them and saying that they have a new architecture that’s really cool and is going to solve all your problems. They heard that before with EAI. Besides, very few CFOs or CEOs give a damn about SOA, architectures, ESB’s, or any of that. They are results oriented and don’t usually care how you as an IT department go about doing it. And they will remind you that you can’t seem to keep up with the change requests as it is. Find someone on the business side of the house who is responsible for one of the top business imperatives, convince them that your SOA project can help them, and let them be your champion for getting your SOA project funded.
7. Establish corporate-wide support at all levels. Adopting a SOA is going to require support at every level of the organization. Development teams who have been traditionally solely responsible for siloed applications will now have to open up their kimonos and start communicating with other teams about creating and using shared services across applications. CIO’s and owners of individual datacenters, who have been traditionally incented to hold their cards close and keep their corporate data locked down, will now have to start working with other datacenters, departments, or business units about opening up and sharing data and business logic across business processes that may span those boundaries. This is not a natural act, and in some cases will require forced introductions and will need to be prodded along by senior management.
8. Establish a SOA “Center of Excellence”. The SOA “Center of Excellence” or “Competency Center” is a cross functional team that consists of architects, project managers, and business analysts. This team typically also has a champion within the senior executive team to ensure the priorities of the team are driven forward. This team is responsible for addressing the new organizational issues surrounding the adoption of SOA. New organizational structures will have to be put in place, new areas of ownership established, and SOA related governance models will need to be established.
In an [URL=http://mediaproducts.gartner.com/gc/webletter/progress_sonic121606/issue2/gartner1.html]insightful article[/URL] (openly viewable at no cost), Gartner’s Darryl Plummer asks, and answers these questions and more - “Who owns what? Who owns the data, services, and processes, and how does one bill back for those processes? Who is responsible for the system that those processes run on? In terms of distributed transactions, an enterprise has processes that span organizations, business applications, computing systems, and even companies. And you have to understand when you are doing this transaction across a lot of different boundaries, how are you going to handle that?”
9. Establish new Governance models . With stringent government regulations such as Sarbanes-Oxley, organizations need to be acutely aware and be held accountable for their book-keeping practices. In the software sense, this means monitoring, auditing, and reporting of their daily business transactions. The introduction of a SOA on the one hand makes this easier since it may provide visibility into services that can be audited and logged. The introduction of a SOA may also magnify the complexity of this issue. For example, what if a service that was written to perform a not-so-critical business task suddenly starts getting reused by a different business process that require strict auditing, logging, and encryption? How are you going to identify and make the distinction between services that require strict attention to governance rules that are put in place versus those that don’t? [URL=http://soa-zone.com/]Dan Foody[/URL] recently wrote a really good article on this subject that can be found [URL=http://www.ebizq.net/hot_topics/soa/features/7172.html?page=1]here[/URL].
10. Embrace organizational change. As the SOA Center of Excellence maps out the new areas of ownership for business processes that span application silos, and new governance models are put in place to enforce policies, organizational changes are imminent in order to address the types of cross-cutting concerns that result from the team’s efforts. Embrace these changes as they will help the overall SOA project become more successful. Remember, you may be the first to do it within your company, but SOA is a corporate wide initiative and you need to be a team player to make everyone successful at it.
Dave
[返回] 中文XML论坛 - 专业的XML技术讨论区 →
EAI/SOA讨论区 → 『 EAI/SOA基础与技术 』 → SOA就绪检查列表：SOA取得成功的十个关键因素[推荐]
(订阅本版)
2006/8/18 10:41:00
新浪微博
SOA就绪检查列表：SOA取得成功的十个关键因素[推荐]
