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.
SOURCE:-
http://www.technologyevaluation.com/research/articles/soa-from-a-management-perspective-part-one-18864/
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.
SOURCE:-
http://www.technologyevaluation.com/research/articles/soa-from-a-management-perspective-part-one-18864/
SOA with my assessment of what it is really good, from the perspective of the software I also like your comments.
ReplyDeletefriv 10