SOA Plug-and-Play Services

SOA Articles : SOA Plug-and-Play Services by Finacle from Infosys

Shifting economic conditions and rapidly evolving IT strategies along with mergers and acquisitions have left few banks with an appetite to untangle the morass of legacy systems running their businesses. Due to the siloed architecture within banks, where each business unit has their own systems and islands of information, core-banking replacement is a complex integration exercise. Islands of systems have to be either made redundant or integrated with the new solution based on business requirements and processes.

But this, thankfully, is not holding up progress and innovation, thanks, in part, to the increased adoption of Web services and its conceptual cousin, the Service-Oriented-Architecture (SOA). SOA is neither a product nor a solution. It is an integration framework that binds internal and external services to create a solution. With SOA, instead of focusing on different applications that reside on different computers, the emphasis is on business services that represent several different underlying applications. As SOA can seamlessly be put into practice in existing IT environments it ensures that changes in technology and processes during core banking replacements can be phased out and managed effectively.

The plug-and-play benefits of SOA and Web services promises to increase the pace of innovation in financial services. Clearly, by adopting SOA and process driven core banking solutions banks worldwide can achieve tremendous benefits. Following this, this paper describes a banking solution framework which depicts how SOA delivers maximum agility.

Read the complete white paper




About the Author
Finacle solutions address the core banking, e-banking, Islamic banking, treasury, wealth management and CRM requirements of retail, corporate and universal banks worldwide.

Source: SOA Service Oriented Architecture information at goarticles.com

Getting value out of SOA

SOA Articles : Getting value out of SOA by Sandy Cosser

According to Wikipedia, SOA (Service-orientated architecture) can be defined as "a group of services that communicate with each other". SOA is designed to offer simple service solutions to save people and machines a great deal of time. Research firm, Gartner has been studying the adoption of SOA around the world and for 4 years they found that SOA was on the rise. Now, for the first time in 5 years, adoption figures have dropped. Last year's survey revealed that 53% of organisations planned to adopt SOA for the first time, this year that figure was down to 25%.
More bad news for SOA is that companies that have no intention of adopting SOA rose from 7% in 2007 to 16% in 2008. In Paul Krill's article on Infoworld.com, Dan Sholler, Gartner research vice-president, states that there are two major reasons behind SOA's sudden drop in popularity: lack of skills and expertise and no viable business case. Companies also no longer see SOA as essential to their future, but have relegated it to the 'luxury' pile where many IT services find themselves in a recession.

But according to Dave Linthicum, also from Infoworld.com, dropping 'luxuries' such as SOA is an unhealthy reactionary approach and can cost companies more money in the long-run. Linthicum cites Miko Matsumura when he says that companies shouldn't ask whether they can afford SOA now, but rather whether they can afford to miss out on a 5x return in three years.

Linthicum also notes that SOA adoption is widespread in Europe, where he says companies are more forward thinking and future-orientated than companies in the US, who tend to focus on the here and now, as he says the next four months as opposed to the next four years.

Linthicum believes that SOA as a concept has been around a lot longer than many people think, only under a different name. And he contends that the concept of SOA will be here long into the future, although further name changes are likely. He points out that names are unimportant, so long as people continue to buy into the core value of the concept and keep the momentum going, that's what counts.

References:

http://www.infoworld.com/article/08/11/03/SOA_growth_projections_shrinking_1.html http://weblog.infoworld.com/realworldsoa/archives/2008/11/asoa_is_inevita_1.html http://weblog.infoworld.com/realworldsoa/archives/2008/11/soa_is_shrinkin.html

About the Author
Sandra wrote this article for the online marketers DTI Data data salvage and recovery one of the most experienced and expert providers of data recovery services in the UK

Source: SOA Service Oriented Architecture information at goarticles.com

Estimating the Cost of a Service Oriented Architecture (SOA)

SOA Articles : Estimating the Cost of a Service Oriented Architecture (SOA) by David DeWitt

In a recent survey by AMR Research it was found that "Fifty three percent of companies had active SOA projects by the end of 2007." The companies that adopted SOA spent an average of $1.4 million to implement SOA on software and services in 2007. These findings were confirmed in a survey prepared by BEA Systems. The BEA survey reported that half of all enterprises with revenue exceeding $1 billion have shelled out over a million on their SOA efforts and expect to spend even more over the next 12 months.

Financial Services organizations were least likely to be adopt SOA but those that did spent significantly more than their peers in other industries.

So does that mean that most organization will face such a large expense to implement SOA? What is the real cost for a SOA implementation?

In a traditional software estimate one would consider: Software size, Complexity, Technology, and Constraints. These individual factors are counted, weighted, and combined to identify an estimate of total effort. The total hours are then multiplied by cost factors for a total cost estimate.

In the SOA world the underlying fundamentals are much the same. By summing four essential estimation components an estimated cost can be derived. The four components are: Data Complexity, Service Complexity, Process Complexity, and Enabling Technology. (your terms, or a citable source here?)

As with more traditional estimation methods, size matters. In a traditional estimation approach one would identify the size of the problem by estimating lines of code, function points, or by some other method. In the SOA community one is concerned with the number of data elements, the complexity of the data storage for those elements, and the cost to understand and refine each element.

David S. Linthicum of the SOAInstitute.org provides a simple formula for the calculation. Cost of Data Complexity = (((Number of Data Elements) x Complexity of the Data Storage Technology) x Labor Units))

• The "Number of Data Elements" is the number of semantics you're tracking in your domain, new or derived.

• Express the "Complexity of the Data Storage Technology" as a decimal between 0 and 1. (For instance, Relational is a .3, Object-Oriented is a .6, and ISAM is a .8.)

• "Labor Unit" is the amount of money it takes to understand and refine one data element. Dave said this could equal $100, for example.

Example: ((2,000 data elements) X .6 complexity) X $150) equals $180,000 for the total Data Complexity Costs.

Now repeat the same formula for the Service Complexity, Process Complexity, and Enabling Technology. The final total should be within 10 - 20% of the actual costs. However, consideration should always be made for changing requirements, scope creep, changes in technology - and the myriad of additional real life factors that have become lessons learned in traditional software development projects.

The factors that go into a SOA estimate are similar to a traditional estimate in many ways. As was demonstrated above, consideration must be made for size, complexity, staffing, and many other parameters. Products such as SEER for Software™ by Galorath can be used to help identify and quantify the underlying components that make up a SOA estimate. Within SEER for Software the estimate can be built, evaluated, assessed for risk, and delivered as part of a repeatable estimation process.

About the Author
David DeWitt is a Senior Consultant with Galorath based in El Segundo, California. He can be contacted at ddewitt (AT) galorath.com. For more information on the Galorath line of estimating software solutions please visit Galorath.com when estimating software projects or call: U.S. +1 310.414-3222 -- U.K. +44 (0) 1252.724518

Source: SOA Service Oriented Architecture information at goarticles.com