Organizations, vendors, and the trade media have embraced the concept of service-oriented architecture (SOA). In an SOA environment industry standards like the XML markup language and various Web service technologies are used to expose software as "services." By exposing software as services, organizations can more easily access these systems, as well as tie multiple services together with their own business logic to create "composite applications." SOA investment is compelling for so many IT departments because it:

• Reduces the cost and time of system integration. The relative speed and low cost of SOA solutions compared to previous integration efforts allows organizations to respond swiftly to new challenges, such as changing market conditions, mergers and acquisitions, and regulatory and compliance demands.
  
  
• Can be rolled out incrementally, allowing IT to demonstrate significant return on investment (ROI) each step of the way. With budgets tight and a history of failed integration efforts, proposed IT solutions can't demand major upfront commitments of organizational resources.
  
  
• Allows IT to reuse existing, proven, and paid for systems. There's rarely a compelling reason to spend money and devote development resources to rewrite working applications in modern computing languages and techniques. Instead, IT can squeeze maximum value out of their existing technology assets by service-enabling them -- essentially keeping the old software in place, but retrofitting a service layer on top.
  
  
• Is built on industry standards and therefore delivers vendor independence. Many organizations are hostage to a particular flavor of technology or product that depends on a vendor's proprietary ways to interact with other systems. Adopting a service mentality means that IT can continue to adopt best-of-breed applications -- as long as they offer standards-based interfaces.

 

A weak SOA foundation will become exposed over time

While the benefits of adopting SOA are clear, the reliability, performance, and security of its services and composite applications depends on the underlying software. For example, imagine a scenario where an organization creates a composite app designed to outmaneuver the competition. The composite app is built from three internal and one external, third-party service. IT is leveraging all the latest SOA standards, but as the systems grows, its reliability plummets as one of its linchpin services -- actually, the software that has been service-enabled -- fails under a heavy transaction load. Weeks later, a security vulnerability in the source code of another application also surfaces as the system is expanded and the original app is confronted with unexpected conditions and data input. The once vaunted SOA is now a victim of the poor underlying software.

As IT increases its SOA adoption, the quality of the code of the underlying applications becomes more critical. The modern service front end of an application may mask inherent deficiencies, but these issues will come to the surface the more widespread the SOA adoption becomes. The problem will grow as departmental apps that never underwent the scrutiny of their more prominent enterprise-class software siblings are integrated in to new workflows and composite apps. Management apps tailored to the SOA environment will eventually locate failure and weak points, but it will be up to IT to repair any underlying architectural weaknesses and remove code defects.

 

Needed: Certification of SOA components

For SOA to remain a viable long-term concept, the underlying apps will have to be improved. Service-enabling weak links won't magically make the SOA chain strong. The same investment in improved processes and tools that organizations should be making to improve their code quality should be used to shore up the SOA foundation.

Even as IT is rolling out directories and processes for reusing services and deploying services that may impact the service level agreements of the underlying apps, they need to act on another issue: certifying applications for SOA use. This certification process will ensure that a service-enabled app that is made available for use in a composite application has been analyzed, debugged, and certified for wide-scale use. Apps undergoing SOA certification should, at the very least, include information that relates to their:

• Reliability, scalability, and security. Popular services will attract new users, and the apps must be able to scale without degradation (assuming additional hardware is supplied to meet demands needs), handle incoming data formats they were not designed for, and deal with malicious activity.
  
  
• Proper use. Many composite app components may have been designed for internal consumption, but in a service-centric world, a business need may require that they are linked to a external system. If an app just can't be relied on for external use, composite app developers should know this before they test or deploy a new system.
  

IT that adds SOA-level certification to its existing development practices and ensures that composite app developers use only certified software will eliminate future headaches and head off the potential SOA backlash.

Note: This research note originally appeared in g2zero, a software development community site that New Rowley helps manage.