The SOA Difference

With SOA, teams are no longer developing disparate and standalone applications that support individual disciplines within an organization. Instead, teams aim to integrate and consolidate the enterprise in hopes that the new generation of strategic business software minimizes redundancy, increases automation and approaches real-time responses. For example, instead of keying the same information into multiple systems, robust SOA implementations integrate back-end processes. In lieu of accessing multiple applications to complete a key business process, coarse-grained services are composed and invoked through well-defined service interfaces. Instead of running nightly batch jobs, critical business functions can be immediately invoked asynchronously to avoid processing delays.

Technologically, SOA makes solving each of these challenges easier. Realizing the benefits of SOA however, requires more than simply mastering the technology. We must also recognize that architecture, design and requirements are constantly evolving. Technologically, SOA does not solve these fundamental challenges inherent to software development. Compounding the problem with many SOA initiatives is the desire to transform the enterprise by building large scale and complex interconnected software systems.

SOA Challenge

Software development is hard. The difficulty, however, is not writing code or applying a certain technology stack. The challenge lies in the specification and design of the software itself. Therein lies the essential complexity of software development, an idea introduced by {sidebar id=1} Frederick Brooks in his 1987 article titled "No Silver Bullet."[1] The difficult aspect of software development is deciding what, exactly, needs to be built. Deciding what to build is difficult when creating a standalone application. Yet with SOA, the challenge is even more pronounced as we strive to develop services that can be used in multiple contexts by a variety of consumers. Below are three factors contributing to the SOA challenge and not addressed by SOA technologies.

Service reuse, behavior and granularity. One of the greatest disappointments with object-oriented development is failure to achieve the high degrees of reuse promised. While classes are fundamentally too fine-grained to accommodate large scale reuse, the failure is not due to the paradigm itself. The failure is directly attributable to an inability to effectively define class responsibilities. Classes with great responsibility have too much behavior and are limited to only a small percentage of possible clients. On the other hand, classes with minimal functionality typically lack meaningful behavior, and while heavily used, may not offer significant reuse value. Services, while technologically a superior form of reuse due to more coarse-grained functionality, are still difficult to reuse because of behavioral issues. Either a service does too much or not enough to provide true value to clients. As Clemens Szyperski so simply states, "maximizing reuse minimizes use."[2]

 

Service Adaptability. SOA does not guarantee business agility. Business agility is an advantage of correctly architected SOA solutions. Increasing responsiveness to business inquiries and changing requirements ultimately requires software that can accommodate change. Adaptable software requires practices, such as Test Driven Development and refactoring, that embrace change. Additionally, adaptable software must be loosely coupled, so managing dependencies between clases and components is crucial in realizing greater flexibility with SOA solutions.

 

Environmental Complexity. Integrating and consolidating enterprise software systems is not a trivial task. Many SOA initiatives are consumed with exploratory tasks and increased risk due not only to the complexity of the systems involved, but also new technologies that a project team lacks experience with. Combined with heavier weight technologies that often present problems with testability, SOA is a breeding ground for risk. For example, published interface contracts can bog down rapid iterations. Additionally, development tools supporting agile practices are not always available for SOA technologies.

Let's explore the depth of these challenges with an example. Assume we have three services, with the possibility of a fourth (see Figure 1). The Policy Issuance service is responsible for various underwriting tasks, rating to calculate premium and generating policy declarations. The Claim Adjudication service is responsible for performing fraud prevention checks, coverage verification and final payment calculation. Both services use the workflow routing service in situations where breaks in processing require intervention or notification. Each also needs to access Customer Information. In the case of policy issuance, Customer Information might be searched to determine if the policyholder is already an insured and, if not, a new customer record is created. In the case of claim adjudication, Customer Information is accessed so the claimant can be contacted and personal information included on the final payment draft.

While each service depicted has deep semantic implications, it's the Customer Information module where we'll focus our discussion. Foremost, is Customer Information a service deployed to a central location and accessed remotely by Policy Issuance and Claim Adjudication? Or is Customer Information a component deployed with Policy Issuance and Claim Adjudication and invoked in-process by each? How do we manage versioning of the Customer Information module if it's a service? Or a reusable component? What about behavioral differences expected by the various consumers of Customer Information? Since Customer Information is used by multiple services, how can behavioral growth be managed, assuming we are not intimately aware of all present and future consumers?

Each of these are critical questions in the SOA puzzle. Even given this simple scenario, assuming we had detailed requirements, the questions have no clear and concise answers. Failure to adequately address such issues is magnified on SOA initiatives that attempt to integrate and consolidate the enterprise.

SOA And Agile Synergies

SOA initiatives must be built upon an organization's already established set of proven practices and guidelines. Failure to utilize proven techniques, such as design patterns and object-oriented design principles, will likely result in services that fail to realize the oft-cited benefits of SOA. Neglecting important underlying component relationships results in services that are difficult to test, build and deploy. There is, however, a natural synergy between agile practices, and the high risk associated with many SOA initiatives. Agile practices encourage growing an agile architecture and design that accommodate change, resulting in individual services that are maintainable, resilient, and extensible.

Certainly, common values of SOA and agility such as greater business agility, incremental delivery, and flexibility contribute to this adoption. But there are other important characteristics that make SOA and agile practices a natural complement to each other.

Intense collaboration. A natural way to partition SOA development is to create teams responsible for development of individual services. A fundamental principle of agile development is to favor collaboration over documentation. Ensuring other teams remain informed of not only changes to service interfaces, but also service behavior is imperative, especially when multiple service consumers is the intent.

 

Refactoring. Developing adaptable and reusable services must be done by emphasizing use and simplicity, not reuse and complexity. Attempting to develop a service with high degrees of reuse is akin to the failures we've experienced when attempting to realize reuse with objects. Likewise, services are only maintainable if we emphasize the maintainability of the service implementation as we continue to grow it's behaviors. Refining interfaces and semantic behaviors is an ongoing task. Continually improving the existing structure to remain resilient is an imperative part of SOA initiatives.

 

Continuous integration. Creating complex interconnected systems is not something that can be done in a vacuum. Multiple teams, while working to develop loosely coupled services, must also prove that services interact correctly, and provide desirable results. The constant feedback provided by a robust continuous integration strategy helps ensure the contracts between services remain intact.

 

Iterative and incremental development. Agile practices allow you to deliver software incrementally. SOA naturally divides software into modular units. Delivering valued software in well-managed units is imperative to ensuring that enterprise SOA initiatives keep moving forward. Short iterations focused on delivering increments of value, followed by deployment, ensure teams are moving in the same direction. Frequent deployments also offers the critical and constant feedback loops that allow the team to adapt early and learn more as the solution emerges and evolves. Additionally, solutions can be demonstrated to project stakeholders at regularly scheduled intervals.

 

Test Driven Development. Services represent modular and cohesive units of coarse-grained behavior, and loosely coupled services are able to evolve independent of other services. Robust suites of tests provide the courage to quickly accommodate change, allowing service implementations to evolve independently.

SOA is an architecture aimed at providing a loosely coupled, yet integrated enterprise software solution. Agile practices emphasize speeding software delivery. While neither is heavily entrenched in the other, there exists a natural synergy between the benefits of SOA and the ability to deliver reliable software quickly when using agile practices.

[1] Brooks, Frederick P., "No Silver Bullet: Essence and Accidents of Software Engineering," Computer, Vol. 20, No. 4 (April 1987) pp. 10-19.

[2] Component Software - Beyond Object-Oriented Programming - Second Edition, Clemens Szyperski with Dominik Gruntz and Stephan Murer, Addison-Wesley and ACM Press, 2002.

About the Author

Kirk is Chief Technology Strategist at QWANtify, where he leads based on his firm belief in the pragmatic use of technology. In addition to his work on large development projects, Kirk shares his experiences through courseware development, teaching, writing, and speaking at seminars and conferences. Kirk has provided training to thousands of software professionals, teaching courses on UML, Java J2EE technology, object-oriented development, component based development, software architecture, and software process.

{mos_sb_discuss:10}

Comments (0)

Write comment

Show/hide comment form