InfoQ

InfoQ

News

My Bookmarks

Login or Register to enable bookmarks for unlimited time.

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

Evaluating SOA Readiness: A Perspective

Posted by Dilip Krishnan on Jan 21, 2009

Sections
Enterprise Architecture
Topics
SOA Appliance ,
SOA Platforms ,
SOA
Tags
Adoption ,
Best Practices

David Conway an independent Enterprise Architect and SOA Consultant, shares his perspective on SOA readiness in an organization. He characterizes SOA as an agent for reducing the TCO (Total cost of ownership) as a result of sharing and reusing composable services.

Once you've understood why an organization needs SOA, he states that “SOA is a form of solution it can only be effective if it solves the problem at hand. So the [next] step “in being ready” is to clearly understand the problem that you are trying to solve.” and gives examples of classes of problems one can hope to solve using SOA.

  • We have really useful data trapped in legacy systems that we would like to release to new user groups to increase customer satisfaction
  • Our admin processes are manual, inefficient and costly as we continually re-key the same information in multiple systems
  • We find it really difficult to get our existing systems to communicate with new supplier systems
  • Our business systems cannot scale to meet our continuously growing user community

He cautions that since SOA is a unique in that it emphasizes cross organizational sharing, and that “it […] challenge[s] an organization to change how it thinks, communicates, delivers, supports and manages. He outlines some of the challenges that any organization needs to be aware of in order to be ready.

  • Communication Channels An organization will have to invest in both informal and formal communication channels to promote information sharing.
  • Governance SOA will initially require a Governance function as you will not achieve business wide coordination without some degree of control. 
  • Budget Sharing information and processing across an enterprise means a single initiative may involve multiple departments. A budgetary approach that allocates budgets on a departmental basis may struggle to encourage the level of collaboration necessary to deliver an optimized solution.

In addition to these organizational challenges he goes on to list the things one needs to know (paraphrased) to evaluate an organizations’ readiness in moving forward with an SOA.

SOA requires skilled analysts - SOA enables business process re-engineering. Your analysts must be skilled in gathering business requirements so they can analyse a process and remove redundancy.

SOA requires knowledgeable technical staff  - Developers and designers need to be proficient with messaging standards and messaging patterns, XML technologies, SOA platforms and tools. They also need to know the strengths and limitations of SOA apply that knowledge to their solutions.

Building Services incurs costs – He categorizes costs as up-front costs i.e. service deployment, service registry for discovery,  security etc. which can be borne over the life-time of a program and the right choice of tools can help to minimize some of these; and operating costs associated with testing, which involves services testing as well as client application testing and maintenance of the service.

Managing Vendor Lock-in – In choosing platforms and tools, vendor lock-in is unavoidable in any enterprise IS. The best strategy is to pick the vendor that best suits your profile, adopt popular industry standards where possible and try to be smart about how and when you upgrade.  

Is your organization ready for SOA? Be sure to read the original essay.

  • This article is part of a featured topic series on SOA

No comments

Watch Thread Reply

Educational Content

New-age Transactional Systems - Not Your Grandpa's OLTP

John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.

Cool Code

Kevlin Henney examines code samples to see what can be learned from them starting from the premise that one won’t write great code unless he knows how to read it.

Collaboration: At the Extremities of Extreme

Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.

Yesod Web Framework

Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).

Transactions without Transactions

Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.

Attila Szegedi on JVM and GC Performance Tuning at Twitter

Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.

10 tips on how to prevent business value risk

One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.

Interview: Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives

InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.