Service-Oriented Analysis and Design
a.k.a. SOA Decision Modeling (SOAD)

Project Overview

Perspectives on Web Services discusses service modeling challenges and architectural decisions required during Web services design. However, it does not cover conceptual SOA design issues around service composition and Enterprise Service Bus (ESB). Therefore, Olaf Zimmermann initiated the SOAD project. The motivation for this project is to give SOA practitioners concrete, tangible service modeling and realization advice in a comprehensive and consumable way. The term "Service-Oriented Analysis and Design (SOAD)" first appeared in an article on IBM developerWorks from June 2004. While the original SOAD paper touched upon some solution elements, its main intent was to stimulate a discussion and call for method engineering activities. Several SOAD solutions have been developed since then; for instance, SOMA from IBM.

SOA Decision Modeling (SOAD) complements existing architecture design methods with techniques, architectural knowledge, and innovative tool support required during service realization. Our two central metaphors are architectural patterns, a popular concept to describe proven solutions to recurring problems, and, less known, architectural decisions. Architectural decisions so far have mainly been used to document designs; SOAD extends their usage context and make them an integral element of the design process. Capturing and structuring the decision knowledge is a challenge; practitioners are confronted with hundreds, if not thousands of decisions once the project leaves "Planet PowerPoint": integration and workflow pattern selection, language and protocol choices, security and transactionality, etc. While patterns capture the available conceptual solutions, SOAD models the corresponding problems, along with detailed information about decision drivers (a.k.a. forces, quality attributes) and the best practices that apply. Both enterprise architects and soluton architects can benefit from sharing architetcural decision knowledge.

Selected SOA issues are featured in this article, in this tutorial, and in Olaf's Ph. D. dissertation. The SOAD concepts are applicable to many application genres (including, but not limited to, enterprise applications) and architecural styles (beyond SOA).

SOAD concepts applied to presales design and strategic outsourcing; knowledge modeling principles and practices 2006-2012

Abstract: Capturing and sharing design knowledge such as architectural decisions is becoming increasingly important in firms providing professional Information Technology (IT) services such as enterprise application development and strategic outsourcing. Methods, models, and tools supporting explicit knowledge management strategies have been proposed in recent years; however, several challenges remain unaddressed. In this paper, we extend our previous work to overcome these challenges and to satisfy the requirements of an additional user group, presales architects that are responsible for IT service solution proposals. In strategic outsourcing, such solution proposals require complex, contractually relevant design decisions concerning many different resources such as IT infrastructures, people, and real estate. To support both presales and project architects, we define a common reference architecture and a decision process-oriented metamodel. We also present a tool implementation of these concepts and discuss their application to outsourcing proposals and application development projects. Finally, we establish twelve decision modeling principles and practices that capture the practical experience gained and lessons learned during the application of our decision modeling concepts to both proposal development and architecture design work on projects.

Find the published article here or download the author's version (pre-print).

Decisions Required vs Decisions Made: Connecting Enterprise Architects and Solution Architects via Guidance Models (Book Chapter on Combining SOAD and TOGAF)

Abstract: Contemporary enterprise architecture frameworks excel at inventorying as-is and at specifying to-be architecture landscapes; they also help enterprise architects to establish governance processes and architectural principles. Solution architects, however, expect mature frameworks not only to express such fundamental design constraints, but also to provide concrete and tangible guidance how to comply with framework building blocks, processes, and principles — a route planner is needed in addition to maps of destinations. In this chapter, the authors show how to extend an existing enterprise architecture framework with decision guidance models that capture architectural decisions recurring in a particular domain. Such guidance models codify architectural knowledge by recommending proven patterns, technologies, and products; architectural principles are represented as decision drivers. Owned by enterprise architects but populated and consumed by solution architects, guidance models are living artifacts (reusable assets) that realize a lightweight knowledge exchange between the two communities — and provide the desired route planners for architectural analysis, synthesis, and evaluation. (This chapter appears in "Aligning Enterprise, System, and Software Architectures" edited by Ivan Mistrik, Antony Tang, Rami Bahsoon, Judith A. Stafford. Copyright 2013, IGI Global. Posted by permission of the publisher.)

O. Zimmermann, C. Miksovic, Decisions Required vs. Decisions Made: Connecting Enterprise Architects and Solution Architects via Guidance Models, in: Mistrik, I., Tang, A., Bahsoon R., Stafford, J. (eds.), Aligning Enterprise, System, and Software Architectures. IGI Global, 2013

Download the chapter or find the entire book here.

Architectural Decision Identification in Architectural Patterns and Issue Catalog for SOA and Enterprise Application Development

Abstract: When modeling recurring architectural decisions for reuse, the boundaries of the knowledge asset under construction must be defined in a scoping step. This paper introduces and combines two supporting concepts for this step, pattern-centric decision identification rules and generic meta issues; one particular meta issue catalog is also presented. The resulting general-purpose decision identification method is validated by identifying 35 decisions that recur in enterprise application development and service-oriented architecture design.

Download the paper here.

SOAD and architectural decision modeling featured in SEI Webinar and IEEE Software article

Abstract (IEEE Software article): Architectural decisions are design decisions that are hard to make or costly to change. Hence, mature software engineering and architecture design methods emphasize the importance of architectural decision-making and capture. Capturing decisions after the fact is important, but many inhibitors limit its practice, such as the lack of immediate benefits. The author introduces a novel architectural decision modeling framework called Service-Oriented Architecture (SOA) Decision Modeling (SOAD) that supports repurposing architectural decisions from documentation artifacts to design guides. The SOAD metamodel distinguishes decisions required from decisions made. The article presents several examples dealing with pattern-based SOA design. It also discusses SOAD usage scenarios, which include education, knowledge exchange, design method, review technique, and governance instrument.

Find the SEI Webinar here and the IEEE Software article here

SOAD and architectural decision modeling featured at OOP (January 25, 2011), SEI SATURN and Rationale Innovate conferences

For the 20th OOP, the organizers put together a particularly strong program. SOAD was feaured in the SOA track. In 2010, SOAD/architectural decision modeling presentations and a tutorial were presented at SEI SATURN 2010 (May 17-21, Minneapolis, MN) and Rational Innovate 2010 (June 6-10, Orlando, FL). Please navigate to the conference website to learn about the overall conference programs.

Download the OOP presentation or the in-depth tutorial

ECOWS Keynote, WICSA/ECSA Tutorial, and Ph. D. thesis

Olaf Zimmermann's ECOWS keynote, WICSA/ECSA tutorial, and Ph. D. thesis motivate why existing general purpose and servied modeling methods do not cover software service engineering sufficiently, give examples of recurring architectural decisions, and introduce Architectural Decision Modeling as our solution to the problems perceived on our case studies.

Download the keynote presentation, the conference tutorial, or the Ph. D. thesis (English)

Compliance by Design — Bridging the Chasm between Auditors and IT Architects (Journal Article)

Introduces an approach to architecture design and audit based on control patterns. Keywords: Information systems audit, CAVR, compliance, security architecture, patterns, service-oriented architecture, business processes, enterprise applications

Abstract: System and process auditors assure — from an information processing perspective — the correctness and integrity of the data that is aggregated in a company's financial statements. To do so, they assess whether a compan's business processes and information systems process financial data correctly. The audit process is a complex endeavor that in practice has to rely on simplifying assumptions. These simplifying assumptions mainly result from the need to restrict the audit scope and to focus it on the major risks. This article describes a generalized audit process. According to our experience with this process, there is a risk that material deficiencies remain undiscovered when said simplifying assumptions are not satisfied. To address this risk of deficiencies, the article compiles thirteen control patterns, which — according to our experience — are particularly suited to help information systems satisfy the simplifying assumptions. As such, use of these proven control patterns makes information systems easier to audit and IT architects can use them to build systems that meet audit requirements by design. Additionally, the practices and advice offered in this interdisciplinary article help bridge the gap between the architects and auditors of information systems and show either role how to benefit from an understanding of the other role's terminology, techniques, and general work approach.

Find the published article here or download the author's version (pre-print).

Industrial Case Study: Architectural Knowledge in an SOA Infrastructure Reference Architecture (Book Chapter)

Architecture design work products and their integration in reference architectures, user feedback, knowledge harvesting process, best practices.

Abstract: In this chapter, we present an industrial case study for the creation and usage of architectural knowledge. To establish the context of our usage of architectural knowledge, we introduce business domain, service portfolio, and knowledge management approach of the company involved in the case in a first section. In this first section, we briefly re-view general architectural concepts such as viewpoints, methods, and reference architectures. Next, we introduce a Service-Oriented Architecture (SOA) infrastructure reference architecture as a primary carrier of architectural knowledge in this company. Moreover, we present how we harvested architectural knowledge from industry projects to create this reference architecture. We also present feedback from early reference architecture users. Finally, we conclude and give an outlook to future work.

Find the book online or download the SOAD chapter here

Managing Architectural Decision Models with Dependency Relations, Integrity Constraints, and Production Rules (Journal Article)

Abstract: Software architects consider capturing and sharing architectural decisions increasingly important; many tacit dependencies exist in this architectural knowledge. Architectural decision modeling makes these dependencies explicit and serves as a foundation for knowledge management tools. In practice, however, text templates and informal rich pictures rather than models are used to capture the knowledge; a formal definition of model entities and their relations is missing in the current state of the art. In this paper, we propose such a formal definition of architectural decision models as directed acyclic graphs with several types of nodes and edges. In our models, architectural decision topic groups, issues, alternatives, and outcomes form trees of nodes connected by edges expressing containment and refinement, decomposition, and triggers dependencies, as well as logical relations such as (in)compatibility of alternatives. The formalization can be used to verify integrity constraints and to organize the decision making process; production rules and dependency patterns can be defined. A reusable architectural decision model supporting service-oriented architecture design demonstrates how we use these concepts. We also present tool support and give a quantitative evaluation.

Find the published article here or download the authors' version (pre-print).

Modeling and Sharing Architectural Decisions, Part 1: Concepts

Presents domain meta model, decision identification-making-enforcement steps, SOA examples, relationship to viewpoints, decisions as reusable assets, tool prototype.

Abstract: This series of articles is about architectural decision modeling and its application to Service-Oriented Architecture (SOA) design and deployment. In this article, learn what architectural decisions are, what their relation with architectural viewpoints is, and why IT architects should consciously identify, make, and enforce them. This article introduces architectural viewpoints, existing templates and tools for capturing architectural decisions, and a domain meta model that was extended and optimized for decision-maker collaboration and reuse. You'll also learn about the Architectural Decision Knowledge Wiki, a prototype that supports our decision modeling concepts.

Read the article online

Reusable Architectural Decision Models for Enterprise Application Development

Features decision making framework, domain meta model, decision identification-making-enforcement steps, SOA decision space overview.

Abstract: In enterprise application development and other software construction projects, a critical success factor is to make sound architectural decisions. Text templates and tool support for capturing architectural decisions exist, but have failed to reach broad adoption so far. One of the inhibitors we perceived on large-scale industry projects is that architectural decision capturing is regarded as a retrospective and therefore unwelcome documentation task which does not provide any benefit during the original design work. A major problem of such a retrospective approach is that the decision rationale is not available to decision makers when they identify, make, and enforce decisions. Often a large, possibly distributed, community of decision makers is involved in these three steps. In this paper, we propose a new conceptual framework for proactive decision identification, decision maker collaboration, and decision enforcement. Based on a meta model capturing reuse and collaboration aspects explicitly, our framework instantiates decision models from requirements models and reusable decision templates. These templates capture knowledge gained on other projects employ ing the same architectural style. As an exemplary application of these concepts to service-oriented architecture shows, reusable architectural decision models can speed up the decision identification and improve the quality of the decision making. Reusable architectural decision models can also simplify the exchange of architecture design rationale within and between project teams, and expose decision out come as model transformation parameters in model-driven software development.

Article and Presentation

Service-Oriented Architecture and Business Process Choreography in an Order Management Scenario

Features an SOA and BPEL case study from the telecommunications that went into production in early 2005. Rationale, architecture overview, lessons learned.

Abstract: Effective and affordable business-to-business process integration is a key success factor in the telecommunications industry. A large telecommunication wholesaler, supplying its services to more than 150 different service retailers, enhanced the process integration capabilities of its core order management system through wide-spread use of SOA, business process choreography and Web services concepts. This core order management system processes 120 different complex order types. On this project, challenging requirements such as complexity of business process models and multi-channel accessibility turned out to be true proof points for the applied SOA concepts, tools, and runtime environments. To implement an automated and secured business-to-business Web services channel and to introduce a process choreography layer into a large existing application were two of the key requirements that had to be addressed. The solution complies with the Web Services Interoperability Basic Profile 1.0 and makes use of executable business process models defined in the Business Process Execution Language (BPEL). This paper discusses the rationale behind the decision for SOA, process choreography, and Web services, and gives an overview of the BPEL-centric process choreography architecture. Furthermore, it features lessons learned and best practices identified during design, implementation, and rollout of the solution.

Read the Article

Second Generation Web Services-Oriented Architecture in Production in the Finance Industry

Features a Web services case study (SOAP, WSDL) that went into production in early 2003. Rationale, architecture overview, lessons learned.

Abstract: Effective and affordable business process integration is a key concern in the finance industry. A large German joint-use centre, supplying services to 237 individual savings banks, enhanced the integration capabilities of its core banking system, consisting of more than 500 complex functions, through aggressive use of Web services. Advanced requirements such as heterogeneous client environment, sub-second response times, 300% traffic growth, and interface complexity did challenge today's Web services implementations. To achieve true interoperability between Microsoft (MS) Office/.NET and Java, and to implement more than 500 Web service providers in a short time frame were two of the most important issues that had to be solved. The current, second release of this solution complies with the Web Services Interoperability (WS-I) Basic Profile 1.0. Leveraging the Basic Profile reduced the development and testing efforts significantly. This report discusses the rationale behind the decision for Web services, and gives an architectural overview of the integration approach. Furthermore, it features the lessons learned and best practices identified during the design, implementation and rollout of the solution.

Read the Article

RESTful Web Services vs. Big Web Services: Making the Right Architectural Decision

Features a conceptual and technology comparison of REST and WS-* (SOAP/WSDL/...) using architectural decisions as comparison metric.

Abstract: Recent technology trends in the Web Services (WS) domain indicate that a solution eliminating the presumed complexity of the WS-* standards may be in sight: advocates of REpresentational State Transfer (REST) have come to believe that their ideas explaining why the World Wide Web works are just as applicable to solve enterprise application integration problems and to simplify the plumbing required to build service-oriented architectures. In this paper we objectify the WS-* vs. REST debate by giving a quantitative technical comparison based on architectural principles and decisions. We show that the two approaches differ in the number of architectural decisions that must be made and in the number of available alternatives. This discrepancy between freedom-from-choice and freedom-of-choice explains the complexity difference perceived. However, we also show that there are significant differences in the consequences of certain decisions in terms of resulting development and maintenance costs. Our comparison helps technical decision makers to assess the two integration styles and technologies more objectively and select the one that best fits their needs: REST is well suited for basic, ad hoc integration scenarios, WS-* is more flexible and addresses advanced quality of service requirements commonly occurring in enterprise computing.

Download the Article

Architectural Decisions and Patterns for Transactional Workflows in SOA

Features three conceptual patterns (TransactionBridge, TransactionIslands, StratifiedStilts), layer-specific primitives for system transaction management in process-enabled, workflow-based SOAs. Maps the conceptual abstractions to BPEL engine(s) and SCA technology.

Abstract: An important architectural style for constructing enterprise applications is to use transactional workflows in SOA. In this setting, workflow activities invoke distributed services in a coordinated manner, using transaction context-propagating messages, coordination protocols, and compensation logic. Designing such transactional workflows is a time-consuming and error-prone task requiring deep subject matter expertise. Aiming to alleviate this problem, we introduce a new analysis and design method that (a) identifies recurring architectural decisions in analysis-level process models, (b) models alternatives for these decisions as reusable, platform-independent patterns and primitives, and (c) maps the patterns and primitives into technology- and platform-specific settings. Our method accelerates the identification of decisions, empowers process modelers to make informed decisions, and automates the enforcement of the decisions in deployment artifacts; tool support is available. We demonstrate value and feasibility of our method in an industry case study.

Article and Presentation

Combining Pattern Languages and Architectural Decision Models into a Comprehensive and Comprehensible Design Method

Features 38 architectural decisions for broker-based and/or process-enabled SOA and discusses the synergetic relation between patterns and decisions.

Abstract: When constructing software systems, software architects must identify and evaluate many competing design options and document the rationale behind any selections made. Two supporting concepts are pattern languages and architectural decision models. Unfortunately, both concepts only provide partial support: Extensive upfront education is needed for practitioners to be in command of the full pattern literature relevant in their field; retrospective architectural decision modeling is viewed as a painful extra responsibility without immediate gains. In this paper, we combine pattern languages and reusable architectural decision models into a design method that is both comprehensive and comprehensible. Our design method identifies the required decisions in requirements models systematically, gives domain-specific pattern selection advice, and provides traceability from platform-independent patterns to platform-specific decisions. We validate our approach by applying it to enterprise applications as an exemplary application genre and a SOA case study from the finance industry.

Article and Presentation

Architectural Decision Models as Micro-Methodology for Service-Oriented Analysis and Design

Features the role of architectural decisions in model-driven SOA construction: position statements, required model transformations, research agenda.

Abstract: During the construction of service-oriented architectures, service modelers concern themselves with the characteristics of good services and how such services can be designed. For instance, they look for advice regarding interface granularity and criteria to assess whether existing software assets are fit for reuse in service-oriented environments. There are no straightforward answers to such questions — service identification, specification and realization techniques are required. Service identification and specification are well covered by existing methodologies; for service realization, architectural decision models can be leveraged. At present, the construction of architectural decision models is an education- and labor-intensive undertaking; if such models exist at all, they often are isolated from other artifacts. In this paper, we propose a new engineering approach to service modeling that leverages reusable architectural decision models as its central service realization concept. We outline a multi-level decision tree and position it as a prescriptive service realization methodology for three engagement types observed in practice. The benefits of service engineering with reusable architectural decision models are semi-automatic decision identification in analysis models, improved decision making quality, and better decision enforcement and risk mitigation capabilities

Download the Full Article and the Short Positioning Paper

Tutorial: SOA Principles and Patters, Core Web Services Technologies, SOAD Overview

Our OOPSLA and ECOWS tutorials introduce SOA as an architectural style that manifests itself through top-level architectural patterns such as Enterprise Service Bus (ESB), Service Composiiton (a.k.a. Business Process Choreography), and Service Registry. Modules 2 and 3 present core Web services technologies such as SOAP and WSDL by example. Module 4 presents the original 26 decisions from "Perspectives on Web Services", as well as several more new decision making examples.

Download Tutorial Handouts and Sample Code

Web 2.0 Tool Support for Collaborative Architectural Decision Engineering

Nelly Schuster developed Architectural Decision Knowledge Wiki, the application wiki we use to make the SOAD content available to practitioners, in her diploma thesis, Hochschule der Medien, Stuttgart, Germany, March 2007. The tool is available at the IBM alphaWorks Emerging Technologies website.

Download the tool from IBM alphaWorks or Nelly's thesis here

Other Papers Featuring SOAD Concepts and Decision Content

Several more papers about service modeling appear under Papers and Talks. A complete and up-to-date list of all papers originating from the SOAD project can be found on Olaf's external staff page at the Institute for Architecture of Application Systems (IAAS), Stuttgart University. More papers from the Business Integration Technologies (BIT) team are available at the BIT group page at the IBM Zurich Research Lab.