Implementing Service Oriented Architecture (often times abbreviated as SOA) in an organization can save the organization resources as well as provide a standard product across the entire organization. As many large organizations try to become more agile in the changing market they rely on Service Oriented Architecture to ensure that they are not recreating the wheel when they create a new application. This discussion will provide a brief overview of Service Oriented Architecture, the benefits an organization can experience from implementing Service Oriented Architecture, drawbacks to service oriented architecture, and finally, considerations that need to be made when thinking about implementing this architecture in an organization.
Many organizations these days rely on IT to enable their businesses to meet customer needs. It is no secret that IT projects can take a long time to go from concept to out-the-door. With the increasing need for quick turnaround in IT, Service Oriented Architecture has become the preferred architecture standard for many large, increasingly agile organizations. (3)(6)
According to The Open Group SOA Working Group "Service Oriented Architecture is an architectural style that supports service-orientation. Service-orientation is a way of thinking in terms of services and service-based development and the outcomes of services." The group goes on to explain that a service "is a logical representation of a repeatable business activity that has a specified outcome". (1) Microsoft describes Service Oriented Architecture as "a loosely-coupled architecture designed to meet the business needs of the organization". (2) With this definition we can expand thinking about Service Oriented Architecture from just an application development prospective and consider how we could provide infrastructure and security services across the organization. We will discuss those options later in this report, but for now we will consider SOA from just an application development (web service) perspective.
(9)
Consider a company that has multiple web applications that provide location data to users (think "where is the closest Metrolink station to me?"). Without Service Oriented Architecture in place, each web application would have a designated development team to build and maintain the application. With this form of development practice, the data returned could vary depending on how the business analysts interpreted the business requirements, the development team implemented those requirements into the application. One app could base the location results on a radius from the point where the user is standing. Another app could base the location results on time it would take to travel by car to that location.
With Service Oriented Architecture the location search and results would be the responsibility of one team, we will call it the "location services" team. This team would be the only team in the organization that is required to interpret the business's needs and develop a solution for those needs. When one of the application teams is interested in including a location "service" in their application, their application would simply call the "location service" team, utilize their common, standard code, and return back a common, standard result to the user.
A report in 2003 by Gartner noted that as time goes on, not adopting Service Oriented Architecture will become a competitive disadvantage for most enterprises. (10) "Evolving tools, skills and best practices will make development of SOA-style applications easier than development of monolithic applications. This change will shift the massive software industry mainstream into the new software-engineering reality." (11)
Service oriented architecture works by passing descriptive information through XML files from one service to another service, a GUI application to a service, and/or a service back to a GUI application. Metadata describes the type of data that the service allows as well as whether or not the service allows for null values to be passed through. (4) The Web Services Description Language (WSDL) describes the service themselves and Simple Object Access Protocol (SOAP) describes the communications protocols. (5)Users/clients who call services simply do so by passing an XML to that service. The service will then interpret the XML file for the information that has been passed to it and will then return the requested data.
(14)
There are many benefits that an organization can experience when utilizing Service Oriented Architecture. Any organization can utilize Service Oriented Architecture, as it is not specific to any platform, development language or brand... it is simply a school of thinking. The first main benefit of a SOA environment is not recreating the wheel on each team. The second benefit is making sure that information being returned to clients is consistent across the applications. Finally, as discussed before, Service Oriented Architecture allows a business to be more agile and get applications from concept to production quickly. When it comes time to create a new business application services can be easily combined to create that application. In this section we will discuss these benefits in more depth.
Code re-use is a very important aspect of application development in general, however in Service-Oriented Architecture it is the backbone feature. With this feature it is easy to pinpoint several benefits. The first benefit is that less resources are needed to create each application. In the case of a location service, often times specialized application development professionals are needed with very specific experience. Rather than having several of these professionals distributed across several application development teams an organization can have one team dedicated to location services and therefore limit the overall need for that specialized skill. This is not just limited to location services, but any kind of service that processes payments or is highly confidential might need professionals with special trainings and certifications, which can come at a cost.
Secondly, consistency across applications is achieved through Service Oriented Architecture. (12) When only one service is being called by multiple applications an organization can ensure that clients of all of the applications are getting the same level of service. An example has already been made regarding the location service, however think of the issues that could arise with payment processing if each development team was left to code their own payment processing applications. In the world of hacking and security breaches there is more pressure on businesses than ever to provide secure payment systems to their customers. By implementing Service Oriented Architecture an organization can at least minimize the risk of writing faulty/penetrable code. Organizations are able to concentrate their specialized resources onto one team, focus development and privacy attention on one service and then make that service available to all of the user applications. This aspect is important when there are specified standards and regulations that need to be met in order for applications to be compliant.
Another core value that leaders see in Service Oriented Architecture is the abilityt o make changes without having a ripple effect across multiple applications. When changes are made to loosely coupled services they do not affect the functionality of other services. Service users are just made aware of the changes through documentation and updated messaging protocols. (12)
Quality Assurance testing times can also be positively affected by the use of Service Oriented Architecture. When a new customer GUI app is built that is utilizing services offered within an organization, that application only needs to test their connectivity to the service itself rather than the logic behind the service. The service team is responsible for the accuracy of the code within the service, and since changes to the service are less frequent the code within a service is relatively stable.
Finally, when an organization wants to release a new application to their users it only needs to create the framework and user interface of the application (and any feature that is not available within their organization as a service) since the services can provide the main functionality. This can drastically cut down the time that is needed for an application to go from concept to production ready. Service Oriented Architecture works to make the inflexibile and expensive IT architecture a thing of the past.
Let's quickly consider infrastructure as it pertains to SOA. Many IT organizations are divided into departments that have their own security teams, applications and hardware. Each department is responsible for the maintenance and security of their own applications and hardware. With Service Oriented Architecture any of these teams (networking, database management, security, storage, etc.) could be consolidated into one large team, providing the same level of service across the organization and eliminating the need for repeating resources.
Service Oriented Architecture is a very beneficial way of developing applications and providing infrastructure services to an organization and clients. A survey done by CA Technologies found that 92% of SOA initiatives met or exceeded the objectives of business units. However, with the good can also come the bad. When all of the applications within an organization rely on one service for a piece of functionality and that service does not work as expected, it can prove to be crippling for an organization. This is a big concern when considering implementing Service Oriented Architecture across an organization.
Take a payment service for example. If that payment service is not secure and every application is utilizing that payment service the organization will face much more trouble than if only one application of many were utilizing that faulty service. When considering infrastructure in SOA the same issues can arise. If there is one team responsible for authentication of users and that team has an issue the entire company may have trouble logging into their computers. In the next section we will discuss how to avoid these issues in a successful implementation of SOA.
Another drawback to using Service Oriented Architecture in an organization is that the organization will need to adapt their existing applications to support the architecture choice. This will take a considerable amount of time and money on the front-end in order to achieve the long-term goal of reusable code. A survey done in 2008 showed that the average SOA budet for companies in 2007 was $4.9 million and some of the companies reached close to $11 million. (7)
When considering implementing service oriented architecture some analysis and consideration needs to be performed to determine if this architecture style can benefit the organization. Service Oriented Architecture is not just an IT initiative, it is a tool that can impact an entire business. SOA can serve as a very powerful business tool, enabling the business to be agile and align the IT offerings to the business needs. However, often times the potential that SOA can bring to a business is not fully understood by those within the business units. (10)
Suggestions for adoption include starting with experimental activity. This early adoption and learning should affect internal clients and not be used for mission critical activities. This will create a basic level of understanding of the key drivers of SOA. Once this is established users are likely to see the benefits of expanding and integrating with more systems. Deployments should then be made to areas where business processes are heavily used to see immediate business benefits. Management of SLAs should be performed to ensure that services are consistent and wideley used services should be exposed and made available for consistency and efficiency. Eventually it will be useful for a business to deploy services for intra and inter organization use and these services will become an integral part of the business's offerings. Organizations can then collaborate and integrate with 3rd parties.(12)
Expanding on this idea of collaboration with 3rd parties, Service Oriented Architecture can enable businesses to profit in areas where they hold expertise. (13) We will use the location services example again. If a business excels in location services, a company might buy/lease the right to access their service instead of creating their own service. This gets rid of the pressure for a company to excel in areas that are not in their realm of business.
When implementing Service Oriented Architecture businesses may find it difficult to determine a specific set of communiction/transaction standards that can be applied to their business needs. (10) This is a challenge because Service Oriented Architecture is different and means different things for every organization depending on how they plan to use it. Leaders of SOA efforts will need to determine which standards their company will need to meet in order to meet quality expectations as well as regualtions set forth by governing bodies.
Other concerns of practicitioners surround quality issues, including performance, reliability and availability. When considering adoption of Service Oriented Architecture an organization needs to consider how they will provision resources to the services and how they will monitor both provider and consumer usage. (14)
IT Governance is another consideration that will need to be placed at the forefront of thought when considering the implementation of Service Oriented Architecture. (10) Since services are used across domains and often by both internal business units and external clients, IT governance can become challenging. It is suggested that a specific entity is placed responsible for the governance of the services and their usage in order to ensure that there isn't any misuse of the service or the information provided. This entity will also be responsible for ensuring that various regulatory acts (SOX, HIPAA, etc) are being followed by the services. (15)
(15)
An organizational structure realignment may be necessary when implementing Service Oriented Architecture. It is suggested that organizational structure be based around the business's main tasks, essentially forming service teams. By doing this, these teams will be able to focus their efforts on providing higher level services and will be able to cover all of the business requirements and objectives in a more timely manner than if they were required to focus on all aspects of an organizational application. From a managerial perspective this division of services allows for better administration of each team, as organizations with duplicated efforts generally have higher overhead. (12)
The alignment of business needs and technology will certainly have an affect on the culture of an organization. With Service Oriented Architecture allowing the business to drive the decisions and model business processes as services boundaries between the business and IT departments are likely to be affected. IT Managers can become worried about losing their influence and position when the business leaders are the ones to define these processes. This, in fact, is already the case with IT budgets being put in the hands of business units and not the IT departments that use them. There is, however, a continued need for experts in the domain to help bridge the gap between the business units and the IT development process. IT management will also still be required to interface among development teams as well as define dependencies of services as more organizations or groups begin to use that service.(16)
Another interesting point refers to developers of the services themselves. Open source software developers encourage the sharing of software amongst entities to contribute to the development of new ideas. However, there is a more old-school approach to software development which is often not addressed. Some software developers and commercial software companies strive to create software with multiple dependencies. This practice ensures that those software developers are indispensible and must be kept around in order to continue to develop and expand the current software used. This mentality will need to be addressed by management and the benefits of Service Oriented Architecture will need to be made clear in order to overcome this mentality. (16)
Service Oriented Architecture has made a large impact in many organizations from its early adoption. A blog post written in 2012 by Joe McKendrick of ZDNet says that Service Oriented Architecture framework and software revenues grew 24% over original projections in the year 2011. The rapid growth is attributed to more frameworks being needed to build cloud computing and more framework being needed in data centers to interconnect applications. (17)
The widespread adoption of Service Oriented Architecture has given software vendors the ability to make their software functionality widely available for integration through Web Services. It has also helped align IT to business needs, applications to infrastructure, and platforms to technology. (18) According to the SOA Manifesto, Service Oriented Architecture prioritizes business value over technical strategy, strategic goals over project-specific benefits, intrinsic interoperability over custom integration, share services over specific-purpose implementations, flexibility over optimization, and evolutionary refinement over pursuit of initial perfection. (19)
With the benefits of Service Oriented Architecture come large impacts to the way an IT organization is laid out as well as how decisions are made. IT leaders must familiarize themselves with both the technical considerations as well as the social considerations when implementing Service Oriented Architecture within their organization. After what can be a lengthy and technically involved implementation process, Service Oriented Architecture can decrease the amount of errors caused by making coding changes as well as reduce overhead and redundancy.
