News on Monday
more>>
SharePoint Tech Report
more>>


   

 
 
Download Current Issue
ISSUE 7/1/2009 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?


 
Is the mystery Borland suitor Serena?
Borland software is considering an offer from another company after a preliminary deal with MicroFocus. Is Serena the new company?
06/30/2009 01:55 PM EST

Windows 7 - An eBayer's dream product?
Windows 7 pre-orders can make people money on eBay.
06/29/2009 03:48 PM EST

Know thine cloud provider
Cloud computing require companies to understand compliance and regulation. Third parties will play a big role in regulated industries.
06/29/2009 02:58 PM EST

 

Microsoft Worldwide Partner Conf.
7/13/2009 to 7/16/2009
New Orleans
Microsoft

OSCON (Open Source Convention)
7/20/2009 to 7/24/2009
San Jose
O'Reilly Media

XBRL Technology Workshop & Summit
7/28/2009 to 7/30/2009
Santa Clara
XBRL US

ACM SIGGRAPH
8/3/2009 to 8/7/2009
New Orleans
ACM SIGGRAPH

OpenSource World (formerly LinuxWorld)
8/12/2009 to 8/13/2009
San Francisco
IDG World Expo


 
Most Read Latest News Blog Resources

Guest View: Riding the Rails of SOA Quality




November 15, 2007 — 
In a recent meeting I attended, someone asked, “Who owns the overall quality of a SOA in an enterprise?” My initial response was, “No one does,” which immediately drew blank stares.

What I meant is that no one person is solely responsible for defining or governing quality in a service-oriented architecture. The word “quality” is a noun that describes a characteristic of a system or a degree of excellence. From a grammatical standpoint, it is similar to the word height. If we talk about a 5-foot-tall person versus a 6-foot-tall person, we can immediately picture a difference in height. The concept of quality, however, is not so black and white.

After all, a quality experience for one person may not be the same for the next. From an enterprise standpoint, the quality of a system or a SOA cannot easily be measured in inches or centimeters. If a SOA does not perform as desired when new services are added, is this due to poor quality of the SOA or the individual service?

After my meeting, I continued thinking about this concept while riding back to the office on the Acela Express, Amtrak’s high-speed train. We were whisking along at what appeared to be more than 100 mph. As I sat looking out the window, I was startled by another train that blasted past us in the opposite direction. We were collectively moving so fast that I couldn’t see passengers on the other train, yet we were only a few feet apart.

At that moment I was very glad that quality and governance were working together.

Following This Train of Thought
Relating the different elements of my train ride to different components of a SOA, the concept of quality and governance working together became much clearer. The train itself is like a service: Quality is measured by how smooth the ride is, the speed at which it travels, and the fact that the windows don’t pop out from the forced air pressure as we pass other trains. All of these factors are the domain of the quality engineers who manufactured the train and those who maintain it.

The fact that we departed and arrived on time certainly could affect my perception of a quality experience, but is more akin to an application built on those services, not necessarily the train itself. The fact that we didn’t collide with the train coming the other way was determined by a governance rule that comes from a higher overall train authority. The higher train authority is not necessarily concerned with how Amtrak treats its customers or how fast, slow or bumpy the ride is, so long as the train fits within its governance rules of height, width and stability to ensure safety.

From Amtrak’s perspective, quality boils down to creating a positive customer experience that prompts people to return in the future—perhaps choosing the train as an alternative to driving or flying—and recommend the service to others.

In this case, however, who owns overall quality? Again, no one does.

Quality is determined by the collective effort of the train company, the train system and the higher train authority. In addition, the business culture of each entity ultimately determines what quality is and how employees should deliver desired results. Some countries have notoriously late train systems while in other countries, train authorities would consider it dishonorable if a train arrived more than three minutes late. Culture typically flows from the top down and can make all the difference in whether quality levels are achieved.

Companies are very similar. Some push for the utmost experience and strive for ultimate perfection in their goods and services, while others are more relaxed and accept the fact that “good enough” can be sufficient to still achieve business objectives and keep costs down, while satisfying customer needs. For example, I am willing to wait for a few more validations when making a bank transfer than I am when shopping online. I am more understanding if a book arrives in the mail a day later than promised than if money is missing from my bank account.

So how does quality factor into a SOA where independent services and composite applications, often created by different groups, interact directly with one another?

Each piece of a SOA must have the infrastructure in place to ensure that it meets and continues to meet the desired level of quality. Like the train and the railway, much of this infrastructure already exists, and the software development industry is well versed at testing at the service level within the software development life cycle. We also understand the value of testing standard applications on top of services—to ensure the train arrives on time.

From a SOA perspective, we need to document policies in a standard way and verify whether governance rules are being followed, or whether performance issues will occur if one more service is added to the mix. We also need new ways of testing interactions between services coming from different departments or business units of a company. How do these groups communicate when they are using different languages, platforms and definitions of quality? A testing system that is agnostic to these differences and facilitates collaboration is very important as a SOA grows.

Another issue that affects quality within a SOA has to do with change.

Greater Agility
The biggest hope from most SOA initiatives is to gain a greater agility to easily adjust to market dynamics. But agility means that pieces of an SOA have to change, making SOA quality a critical requirement when building and deploying interacting components that are constantly coming and going, changing and evolving, and to a greater or lesser extent interacting. How do we know that the system will run at the same level of quality today as it did yesterday—or even more important, predict that it will run the same tomorrow as it does today?

For this to happen, testing and validation tools need to work in conjunction with governance systems. This will ensure that prior to governance accepting a change to the system, it will automatically rerun the appropriate tests and validation checks to ensure that quality expectations are being met.

So while no one person or entity owns the overall quality of a SOA, it is important to put the right infrastructure in place to allow teams to define and maintain the level of quality that the culture of the company demands, and ensure the level of quality that services and composite applications need in order to keep the train moving forward smoothly and efficiently.

Frank Grossman is co-founder, president and CTO of Mindreef, which sells test and quality assurance software for SOAs.


Share this link: http://www.sdtimes.com/link/31356
 

Add comment


Name*
Email*  
Country     


  • Comment
  • Preview
Loading