We have been hearing about service-oriented architecture (SOA) for some time. Now, major software players are starting to lay out their plans and strategies. Some are even willing to assign delivery dates. As a company, you cannot ignore SOA, since we are constantly told that, from a software perspective, it is the best thing since sliced bread or, to use an updated analogy, the TV remote control. Regardless of your views, chief information officers (CIOs) need to outline their plans and be prepared to respond to executive management's question: "What are we doing?" This note sounds the alert, raises the flag, or fires the warning flare as to why converting to SOA does not appear to be an easy transition and cannot be accomplished with smoke and mirrors. Accordingly, we will look at the basics of SOA; the rollout plans of major software vendors; the benefits of SOA; concerns about SOA; and why the implementation of SOA won't be easy.
This is Part One of a two-part research note. Part Two addresses concerns about SOA and how your organization can migrate to an SOA environment.
What is SOA?
SOA is a collection of services or groups of components that perform business processes such as credit verification, currency conversion, or inventory availability. SOA employs an architectural style for building applications by combining loosely coupled and interoperable services. By being loosely coupled, an application does not have to understand or even know the technical details of a service to call it. As a result, SOA attempts to deliver platform independence, and is not tied to a specific technology.
Examples of SOA can be found in our everyday lives. A common example is a DVD player. The player offers the service of playing a DVD. You can play multiple DVDs in the player. You can even play the same DVD in another player, but the sound quality may not be the same. SOA, however, should not be confused with object-oriented programming (OOP). Following our DVD example, in OOP the DVD would come with its own player, not to be separated. This diminishes one of the primary advantages of SOA, namely reusability. To understand the evolution of SOA, see research note Architecture Evolution: From Mainframes to Service-oriented Architecture.
Being loosely coupled also helps to screen some of the technical complexity of programming, a potentially big boost for productivity. For example, you do not need to know how a credit check is performed to complete a customer's order. You just need to know what information, such as customer ID and order amount, the credit checking service needs to return an approval or rejection. The process is similar to when televisions were built with individual electronic components and repair meant replacing a component and not the entire set.
With SOA comes new terms and concepts, or old concepts with a new lexicon, both of which mean some difficult decisions lie ahead. With the use of services you can expect a lot of messaging traffic. Accordingly, you will need technology to manage this traffic and its flow on the information highway. An enterprise service bus (ESB) facilitates the connection of legacy systems to services. It also transforms and routes traffic. ESBs are particularly effective for long-running processes, invoking multiple services such as purchasing, which can encompass item look-up, pricing, discount terms, and more. After being developed and tested, services must live somewhere. Typically, services are published in registries or directories while being stored in repositories. This combined infrastructure controls secured access, specifies the input parameters, and enforces run-time performance parameters. Relative to performance and after services enjoy wider and wider acceptance, reporting and alerts are needed to ensure that applications are taking full advantage of SOA. Other difficult choices such as development platform, integration with web services, and testing and debugging protocols remain, and must coexist with your current technology and network topology.
Major vendors are starting to lay out their visions for SOA. Based on its NetWeaver development and integration platform (see research note Multipurpose SAP NetWeaver), SAP's approach is to deliver narrowly defined models or packages rather than release large-scale updates of closely interlinked components. By providing business process models, SAP provides the means of getting you up and running quickly, assuming that the models can fit within the constraints of your business.
Attempting to merge the software code resulting from its recent acquisition of PeopleSoft, Oracle's Project Fusion endeavors to provide a more open environment. Accordingly, Oracle's approach is to provide tools to model your business processes. These tools include a business process development platform and middleware and database components, which are open to third party vendors. This business process management (BPM) approach can deliver a more open framework, resulting in components tailored to your environment. So, while SAP's approach could simplify and accelerate the overall process of implementing SOA, Oracle's plan may provide greater adaptability of the unique aspects that make a company successful.
Referring to the "real approach" to SOA, Microsoft advocates a more incremental method, using advancements in .Net Framework, SharePoint, 2007 Microsoft Office System, Exchange Server, and Vista (see research note Subtle (or Not-so-subtle) Nuances of Microsoft .NET Enablement). Unlike the enterprise infrastructure-centric approach, Microsoft touts a wave approach to deliver SOA interoperability gradually to the Microsoft Dynamics product lines. Microsoft Dynamics, formerly known as Microsoft Business Solutions, includes Axapta, Great Plains, Navision, and Solomon. In so doing, some features will be available now instead of waiting for the full rollout. Originally known as Project Green, Microsoft has committed to an initial phase called Wave 1, which is nearing completion. It is expected to achieve a common look and feel throughout Microsoft Dynamics. Obviously, this is where Office 2007 and Vista will set the tone. Expect to see left-pane navigation bars for easy access, top-page trails for traversing back to a previous point of reference, and user ribbons, which will replace the traditional menus and toolbars with a set of tabs of common and most relevant commands. Wave 2 is expected for release in 2008 or 2009 as product lines continue to move away from coding to model-based development using Visual Studio .Net tools and languages. Once this transition is complete, Microsoft can consider merging product lines. Microsoft shares two potential obstacles with Oracle. First is seamlessly integrating acquired software packages to present a consistent and familiar theme. Second is adopting a model building capability as opposed to delivering the models, potentially sacrificing delivery speed for the sake of flexibility. While Microsoft's architecture vision appears to be clearer due to our familiarity with and the release of Office and Vista, the starting point for merging product lines is vague, particularly when compared to SAP and Oracle.
Given SAP's increased interest in penetrating the small and medium enterprise (SME) market, its approach of providing process models ready for deployment makes a lot of sense. For companies with information technology (IT) resources, availability of Oracle's modeling tools allows enterprises to grow their own services, customized to their business requirements. However, Microsoft's similar approach is somewhat baffling given its predominance in the SME space.
Vendor plans are, at best, sketchy, as more vendors are jumping onto the SOA bandwagon in an attempt to generate new software revenue streams. After digesting the over-hyped Y2K phenomenon, many companies are adopting a reasonable wait-and-see attitude before taking another bite of the technology apple. Can you blame them?
What Are the Benefits of SOA?
Be assured that the benefits of SOA are significant and achievable, and deserve careful evaluation and analysis. Reviewing some of the more substantial benefits justifies this cautious stance.
Service Reusability
Nowadays programs are rarely written from scratch. Typically, you start with a familiar program that most emulates the functionality you are trying to re-create, or that provides structural consistency. Now take this philosophy and incorporate built-in services and routines. Service reuse is the real power of SOA. Companies are finding that development time is significantly reduced, program logic flow greatly simplified, and duplication of effort eliminated. A well-maintained, tested service can be reused across the entire enterprise. Recent surveys indicate that service reusability is the most often cited benefit delivered by SOA. This should not be surprising. The concept of reusability has been the nirvana that IT groups have been trying to attain since the first IFTHENELSE statement was coded. Whether SOA will achieve this objective remains to be seen. Remember, IT can also stand for independent and temperamental.
Agility
Recall that one of the problems associated with contending with Y2K was interpreting the two-digit year designation. Finding every date routine in every program was considered a nightmare, warranting a complete replacement of legacy systems. Suppose that date handling was a called service that ensured correct formatting and calculation of periods of time. Y2K would not have been the worrisome beast that everyone thought it was. The analogy can be applied to more frequently changed business processes. Want to attract more customers by changing the pricing policy? Is bad debt increasing at an alarming rate, making you want to tighten credit checking procedures? If these processes were being supplied as centrally located services, accommodation of these business changes can be quick and immediate. If done correctly, SOA gives new meaning to agility and the concept of turning on a dime.
Corporate Governance and Security
Unfortunately, this next benefit bemoans the sad state of IT, but is necessary for SOA to be effective, namely "Tell them and they will comply." Corporate governance promotes compliance with policies and standards and ensures that everyone is marching to the same beat. Developers can be persuaded/encouraged/forced to use repository-based services if they ever want their applications to see the light of day. As a result, SOA can facilitate compliance with the US Sarbanes-Oxley (SOX) law and industry-specific regulations, thereby making it increasingly important to give sufficient notice to SOA governance. And, if personnel modeling business processes understand the need of using services, the need to provide secured access to these services is a natural follow-on. But this can be a double-edged sword. If you require the use of services, a communication channel must be established to let everyone know and find what is available for reuse. While registries and directories can help facilitate this communication, proactive methods must be added to supplement these passive tools.
SOURCE:http://www.technologyevaluation.com/research/articles/soa-from-a-management-perspective-part-one-18864/
No comments:
Post a Comment