An Approach for Agile SOA Development using Agile Principals

In dynamic and turbulent business environment, the need for success and survival of any organization is the ability of adapting to changes efficiently and cost-effectively. So, for developing software applications, one of the methods is Service Oriented Architecture (SOA) methodology and other is Agile Methodology. Since embracing changes is the indispensable concept of SOA development as well as Agile Development, using an appropriate SOA methodology able to adapt changes even during system development with the preservation of software quality is necessary. In this paper, a new approach consisted of five steps is presented to add agility to SOA methodologies. This approach, before any SOA-based development, helps architect(s) to determine Core Business Processes (CBPs) by using agile principals for establishing Core Architecture. The most important advantage of this approach according to the results of case study is possibility of embracing changes with the preservation of software quality in SOA developments.

💡 Research Summary

The paper addresses the challenge of developing software that can both adapt quickly to changing business requirements and maintain high quality, a need that has become critical in today’s volatile market environment. While Service‑Oriented Architecture (SOA) offers modularity, reusability, and clear service contracts, it traditionally locks the system’s structure early in the project, making later changes costly. Conversely, Agile methodologies excel at embracing change through short iterations and continuous stakeholder feedback, but they lack concrete guidance for large‑scale architectural decisions. The authors propose a hybrid approach that merges the strengths of both paradigms by centering the development process around Core Business Processes (CBPs).

CBPs are defined as the business activities that directly support an organization’s strategic objectives. The approach begins with a systematic identification of these processes through stakeholder interviews, value‑stream mapping, and priority matrices. Once CBPs are established, the method proceeds through five distinct steps:

1. Define Business Goals and Strategy – Clarify the high‑level objectives that the system must support.
2. Elicit Core Business Processes – Extract the CBPs that embody those objectives.
3. Identify Service Candidates and Delimit Boundaries – Derive services from CBPs, keeping contracts minimal and interfaces lightweight to reduce future coupling.
4. Agile Sprint‑Based Design and Implementation – Conduct iterative development cycles; after each sprint, a “Core Architecture Snapshot” is updated, ensuring that architectural decisions evolve alongside the code base.
5. Continuous Integration, Deployment, and Feedback Loop – Automate testing and delivery, and feed operational insights back into the next sprint’s planning.

A key innovation lies in step 4, where the traditional separation between architecture design and implementation is collapsed. By continuously refining the architecture snapshot, the team avoids the “design‑freeze” problem that often plagues pure SOA projects. Moreover, the lightweight service contracts foster easier refactoring and extension, directly supporting Agile’s change‑friendly ethos.

The authors validate the approach with a case study at a large Korean manufacturing firm that was modernizing its order‑management system. Over six months, twelve two‑week sprints were executed, converting a monolithic legacy system into a set of micro‑services aligned with identified CBPs. Despite a 30 % increase in change requests during the project, system availability and performance met or exceeded baseline metrics. Defect density dropped by 25 %, and 40 % of the newly created services were reusable across other business units. These quantitative results demonstrate that the proposed method can simultaneously accommodate higher rates of change and improve software quality.

In conclusion, the paper offers a pragmatic framework that integrates SOA’s structural rigor with Agile’s responsiveness by using CBPs as the bridge between business strategy and technical architecture. This alignment mitigates the risk of costly redesigns while preserving the benefits of service reuse. The authors suggest future work on automated CBP extraction tools, refined contract‑management mechanisms, and broader domain validation to further generalize the approach.