加拿大华人论坛 美国华人新闻2005: The Year of the SOA?

在加拿大

November 15, 2004 (Computerworld) -- 2005 will be the year of the SOA. Mark it down. According to The Yankee Group, 75% of firms plan to invest in the technology and staffing to enable a service-oriented architecture (SOA). This is a serious movement away from IT solutions of the past and toward standards-based architectures with the promise for the future.To me, this SOA trend is symptomatic of the fatigue experienced by both business and IT end users. They are tired of vendor lock. They've had it with applications that won't interoperate with other enterprise applications. They are fed up with IT architectures that are rigid, expensive to maintain and operate, and inhibit business and IT agility. They are tired of spending ever-tightening IT budgets on internal integration issues that just won't go away. SOA holds the promise to address all of these issues, and as The Yankee Group's survey suggests, many end-user firms agree.So, as these firms embark on their SOA journeys, I wanted to share some thoughts with these SOA adopters to help them avoid some pitfalls. * SOA is a business-driven issue. I urge my clients to focus on their business imperatives first. In other words, what business issues must be fixed or improved or else the company is endangered? The "or else" motivator is what creates the compelling event for moving to an SOA. There will usually be a few business imperatives that are undeniably critical to an organization's future survival. These should be used to help drive SOA initiatives. * SOA doesn't require big-bang investments in technology with nebulous ROI and prolonged payback periods. SOA is achievable in small increments, and the tangible benefits of software and services reuse immediately deliver bottom-line results. In fact, there is often a clear ROI at the project level while an organization builds toward the strategic vision of an SOA. * This phenomenon is one we're unaccustomed to, and often business executives are skeptical. However, the proof is in the pudding. Scope a development project, compare traditional development processes and time to market with a Web services approach, then factor in the enabling infrastructure to operate Web services, and compare. What you will find is that you will have a software solution that costs less, leverages existing IT infrastructure and is reusable. Of course, scaling the SOA to accommodate many Web services requires additional SOA-enabling solutions, such as a Universal Description, Discovery and Integration registry, Web services management solutions and a robust security strategy. * Perhaps a messaging solution or enterprise service bus (ESB) is needed as well. But the price points for these solutions are significantly different from those of enterprise software of the 1990s. In other words, there is a clear cost advantage associated with Web services and SOA across the board. * SOA requires cultural and organizational discipline as much as enabling technology. Organizations should be prepared to educate and train their business and IT executives on SOA. They should plan to create incentives encouraging and enforcing reuse of services in their SOA. They should also design the SOA governance model, governance processes and policies to be enforced in their SOA -- such as reuse policies, security policies and standards policies. * Many of these challenges are organizational and process issues. Their enforcement, however, is both process- and technology-driven. SOA governance must be backed by SOA solutions that can enforce a Web services security policy or an architectural compliance policy both at design time as well as runtime. * SOA does threaten entrenched enterprise software application vendors unless they have embraced Web services and SOA as well. Beware of their desperate attempts to market themselves as an SOA or Web services solution. Perform due diligence to make sure. Evaluate their ability to interface to your enterprise systems using Web services. Do a detailed evaluation of how their application functionality is exposed as services to the outside world as well as their ability to consume services. * If there is no true Web services support, ask for their product road map. Ask them when they will support Web services. Write a performance service-level agreement into your contract with them requiring Web services support by a specific date. Do not let them off the hook on this, and be sure to follow up. * Get to know the various Web services and SOA software vendors. I group them in four fundamental categories of functionality initially, and then map the rest to adjacent or related categories. In my mind, the minimal functionality required for an SOA includes the following: Web services management; services registry (UDDI); Web services security; ESB or messaging bus. Some of these categories are clearly defined, while others are a bit fuzzy. Web services security can be accomplished in multiple ways -- at the Web services management level, at the enterprise level with single-sign-on and access management solutions, or at the XML firewall level with security appliances. In all these cases, the Web service is where security happens. The "how" of security has many choices. Defining a security strategy and a policy that can be enforced at services design and runtime is essential, and let that drive the technology choices for your SOA team. 2005 may well be the year of the SOA. If you are seriously contemplating investing in SOA and Web services capabilities, make sure you do so with business intent in mind. Using the "fix it or else" scenario helps identify clear and compelling business issues that must be solved, as well as potential IT barriers or issues that must be addressed to enable the business outcome. These are critical business-focused starting points for SOA thinking that will help drive a jointly owned business and IT SOA strategy going forward.

  ·中文新闻 悉尼学生因佩戴巴勒斯坦围巾被禁止参加12年级正式课程
·中文新闻 二十年来，联邦政府一直向澳大利亚非法商人收取费用