SOA–Friend or Foe?

A cautious approach to service-oriented architectures can reap rewards and limit risk.

Many of our recent conversations with CIOs brought up the subject of service-oriented architectures (SOA). Since one should never ignore IEAs (Important Emerging Acronyms), we decided to share our views publicly and hopefully aid CIOs in thinking through the implications of SOAs for their businesses.

What will guide us is a theme we have found common in almost all situations: The details seem elusive, and CIOs find themselves struggling to get a clear picture of how these ideas will help, which technologies to invest in, and how to plan and manage SOA projects. And, while architects and developers are universally on an SOA-induced “high,” ever-skeptical management keeps asking why, when, how, and how much?

So, What's New?

So, do SOAs and the accompanying glut of supporting technologies present a new universal cure, a point solution, or a well-orchestrated hoax by vendors looking for more revenue? And why, according to Datamirror research from July 2005, will the expenditures on common distribution platform projects reach $844 million by 2009 in European insurance only?

Let us say immediately the frameworks and concepts “SOA and Co.” present are something we strongly believe in. Loosely coupled systems that use location transparency and reusable business functions (i.e., services) have existed for a long time and have been used with success–think CORBA, DCOM, or DCE.

SOA extends this concept by presenting a complete set of architectural policies, practices, and frameworks that define the context in which services are executed. SOA's main delivery platform–Web Services (WS)–provides “plumbing” and interaction-interoperability based on open standards (i.e., “Internet/Web”).

However, our intention is not to elaborate on architecture or standards that still are being worked out but rather to develop an executive brief for the risks and rewards one can expect from investing in SOA.

It's All About the Business

Rule number one: Implementing a service or, even more important, a complete service-based architecture is a decision that should be made only in the context of the business architecture.

By business architecture we mean the way in which a company is organized and executes its individual business services (i.e., business process steps) to form a value chain to internal and external customers.

Every company contains business process steps such as “retrieve a customer account (e.g., policy)” or “transfer funds electronically (e.g., EFT),” and the path from identification of these steps to the point where they are implemented as services in a specific business application is not necessarily a long one; however, a business case for such a move has to be assessed carefully. Here is why.

o SOA is complex. It requires extensive application but also physical infrastructure–from core services such as security, identity, routing, load balancing, etc., to specific business application services–all of which will become another layer of overhead residing on top of the existing IT infrastructure.

o SOA requires very advanced archi- tecting skill to be able to create services of such granularity and scope they exhibit proper business meaning/context for a specific organization.

o Rearchitecting existing systems, which in many cases are poorly documented, can lead to their unexpected or incorrect behavior.

o The cost of transition even when applying an incremental approach is very high due to the required effort, skill, and products, which in most cases currently are not part of the organization.

o Development and management tools still are not completely mature, and vendors continue in a battle for “standards supremacy.”

Those are the risks. It's time to look at the rewards.

Can SOA Reward Companies?

Yes, by all means. We always argue it is the strategy, structure, and processes that differentiate carriers much more than their technologies. SOA fits well into such a paradigm as its strength lies in enabling the flexible creation and change of business flows. Hence, companies that naturally would benefit from SOA and WS are the ones where:

o Service location independence and transparency are important (geographically distributed operating environment).

o Value chains (supply and distribution) are complex and involve a large number of independent parties.

o Leverage for existing application assets is important (reliance on proprietary applications as a competitive advantage).

o Complexity of operating environment is a challenge (multitudes of separate systems with many common basic functions, e.g., customer lookup).

How Do Midsize Carriers Compare?

Midsize carriers operate largely centralized operating environments (but possibly with disparate and heterogeneous nonintegrated applications).

Existing applications contain a certain degree of proprietary logic that constitutes competitive advantage, but P&C carriers still do not differentiate adequately on using IT.

Insurance in general, but even more specifically midsize insurers, fall into the category of a low-transactional, highly data-intensive industry, compared with most other industries.

Often located outside of major metropolitan areas, finding talent that has the combination of experience and aptitude for this kind of solution can be a challenge for midsize carriers.

So, Is SOA a No-Go?

As we just saw, midsize carriers have few characteristics that would justify wholesale investment in SOA. However, we do see an area where many midsize insurers successfully have experimented and implemented early examples of services-based solutions: agent/broker interaction. It is a near-perfect target for WS and SOA–a specific set of business functions that clearly fit into a predefined business process that need to be exposed to a heterogeneous user community.

Other opportunities where WS and SOA may benefit midsize carriers while limiting the risks are:

o When having a strong need for raising flexibility in business processes and products restrained by a strategy of retaining the existing legacy applications.

o Using services implemented in vendors' packages.

o Extending existing application functionality to a broader and heterogeneous user community.

o In cases of extreme heterogeneity of existing applications (e.g., due to M&A).

o When having a need for realignment of technical infrastructure (often due to security or scalability reasons).

How Much Does SOA Cost?

A better question would be how to build a business case for SOA. Regardless which question you ask, we'll have to disappoint you. We don't know. We feel at this point there is insufficient cumulative industry experience for a credible, top-down (i.e., by extrapolation from relevant cases) business case development.

Hence, the only rational strategy we can support is the one of being slow and cautious. Start with a small, limited-functionality prototype, use the bottom-up approach for cost, and establish a structured and comprehensive measurement program to evaluate the benefits.

We also should point out we are rather skeptical about the promise of simplified environment and reduced cost of operating an SOA-based infrastructure. History shows, more often than not, new infrastructures are added to (or on top of) existing ones. Nothing simple nor less costly about that.

However, for midsize carriers with largely centralized operations, this is less of a concern or a justification.

Is SOA for You?

Aside from assessing your specific environment and strategies regarding the aforementioned risks/rewards, we offer the following four additional criteria that should be viewed as enhancing the case for SOA:

o If you anticipate significant changes in the IT environment due to business strategy that leads to creation of a highly heterogeneous operating environment (e.g., new acquisitions/M&A).

o If you already have in-house experiences with distributed transaction processing systems (CICS, CORBA, DEC, various middleware, etc.).

o If you have a very process-mature IT organization experienced with incremental delivery.

o If you're purchasing a new, service-based business application that can be used as a starting point for building an SOA foundation.

If you already have decided to sit back and wait for the mud to settle, don't surrender yet. You could miss an opportunity to make a small change to the way you think about IT, which may result in a fundamental change in the way your business operates. This indeed may be your “no guts, no glory” moment.

Marek Jakubik, a former CIO of Zurich Financial and Pitney Bowes, is a co-founder and managing director of the Insurance Technology Group (www.insurancetg.com; 416-214-3445). He can be reached at [email protected]. Vladimir Orovic, who spent the last 15 years advising CIOs and CEOs, is a co-founder and managing director of the Insurance Technology Group ([email protected]).

Want to continue reading?
Become a Free PropertyCasualty360 Digital Reader

Your access to unlimited PropertyCasualty360 content isn’t changing.
Once you are an ALM digital member, you’ll receive:

  • Breaking insurance news and analysis, on-site and via our newsletters and custom alerts
  • Weekly Insurance Speak podcast featuring exclusive interviews with industry leaders
  • Educational webcasts, white papers, and ebooks from industry thought leaders
  • Critical converage of the employee benefits and financial advisory markets on our other ALM sites, BenefitsPRO and ThinkAdvisor
NOT FOR REPRINT

© 2024 ALM Global, LLC, All Rights Reserved. Request academic re-use from www.copyright.com. All other uses, submit a request to [email protected]. For more information visit Asset & Logo Licensing.