Service-Oriented Analysis and Design
a.k.a. SOA Decision Modeling (SOAD)
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).
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.
O. Zimmermann, C. Miksovic, J. M. Küster, Reference architecture, metamodel, and modeling principles for architectural knowledge management in information technology services. Journal of Systems and Software, vol. 85, no. 9, pp. 2014-2033, Sept. 2012, doi: dx.doi.org/10.1016/j.jss.2012.05.003
Find the published article here or download the author's version (pre-print).
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: Mistrík, 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.
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.
O. Zimmermann, Architectural Decision Identification in Architectural Patterns, Proc. of WICSA/ECSA SHARK 2012, ACM Digital Library, 2012
Download the paper here.
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.
O. Zimmermann, Architectural Decisions as Reusable Design Assets. IEEE Software, vol. 28, no. 1, pp. 64-69, Jan./Feb. 2011, doi:10.1109/MS.2011.3
Find the SEI Webinar here and the IEEE Software article here
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
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)
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 company’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.
K. Julisch, C. Suter, T. Woitalla, O. Zimmermann: Compliance by design - Bridging the chasm between auditors and IT architects, Computers & Security, Volume 30, Issues 6-7, September-October 2011, Pages 410-426, ISSN 0167-4048, DOI: 10.1016/j.cose.2011.03.005.
Find the published article here or download the author's version (pre-print).
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.
O. Zimmermann, P. Kopp, S. Pappe, Industrial Case Study: Architectural Knowledge in an SOA Infrastructure Reference Architecture. In: M. Ali Babar, T. Dingsøyr, P. Lago, H. van Vliet (Eds.), Software Architecture Knowledge Management: Theory and Practice, Springer-Verlag, 2009.
Find the book online or download the SOAD chapter here
Comprehensive coverage of key SOAD contributions, overview of SOA guidance model, decision modeing patterns. Keywords: Architectural decision, architectural knowledge, decision dependencies, decision tree, dependency pattern, enterprise application, integration, knowledge management, model, SOA, Web services, UML
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.
O. Zimmermann, J. Koehler, F. Leymann, R. Polley, N. Schuster, Managing architectural decision models with dependency relations, integrity constraints, and production rules, Journal of Systems and Software, Volume 82, Issue 8, SI: Architectural Decisions and Rationale, August 2009, Pages 1249-1267, ISSN 0164-1212, DOI: 10.1016/j.jss.2009.01.039.
Find the published article here or download the authors' version (pre-print).
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.
O. Zimmermann, N. Schuster, P. Eeles, Modeling and Sharing Architectural Decisions, Part 1: Concepts. IBM developerWorks, August 2008.
Read the article online
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
O. Zimmermann, T. Gschwind, J. M. Küster, F. Leymann, N. Schuster, Reusable Architectural Decision Models for Enterprise Application Development. In: Overhage S. Szyperski C. (eds.), QOSA 2007. LNCS, Springer, Heidelberg (2007)
Article and Presentation
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 widespread 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.
O. Zimmermann, V. Doubrovski, J. Grundler, K. Hogg, Service-Oriented Architecture and Business Process Choreography in an Order Management Scenario, Companion to the 20th Annual ACM SIGPLAN Conference on Object-Oriented Programming, Systems, Languages, and Applications, OOPSLA 2005, October 16-20, 2004, San Diego, CA, USA
Read the Article
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.
O. Zimmermann, S. Milinski, M. Craes, F. Oellermann, Second Generation Web Services-Oriented Architecture in Production in the Finance Industry, Companion to the 19th Annual ACM SIGPLAN Conference on Object-Oriented Programming, Systems, Languages, and Applications, OOPSLA 2004, October 24-28, 2004, Vancouver, BC, Canada
Read the Article
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.
C. Pautasso, O. Zimmermann, F. Leymann, RESTful Web Services vs. Big Web Services: Making the Right Architectural Decision. In: W.-Y. Ma, A. Tomkins, X. Zhang (eds.): Proc. of WWW 2008, ACM Press (2008).
Download the Article
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.
O. Zimmermann, J. Grundler, S. Tai, F. Leymann, Architectural Decisions and Patterns for Transactional Workflows in SOA. In: Krämer, B., Lin K.-J., Narasimhan, P. (eds.): ICSOC 2007, LNCS 4749, Springer, Heidelberg (2007)
Article and Presentation
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.
O. Zimmermann, U. Zdun, T. Gschwind, F. Leymann, Combining Pattern Languages and Architectural Decision Models into a Comprehensive and Comprehensible Design Method. In: Garlan D., Woods E., Proceedings of Seventh Working IEEE/IFIP Conference on Software Architecture (WICSA) 2008. IEEE Computer Society, Los Alamitos (2008)
Article and Presentation
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 multilevel 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
Zimmermann O., Koehler J., Leymann F., Architectural Decision Models as Micro-Methodology for Service-Oriented Analysis and Design. In: Lübke, D. (ed.), Proc. of the Workshop on Software Engineering Methods for Service-oriented Architecture 2007 (SEMSOA 2007), Hannover, Germany, online CEUR-WS.org/Vol-244 (2007)
Zimmermann O., Koehler J., Leymann F., The Role of Architectural Decisions in Model-Driven Service-Oriented Architecture Construction in: Skar, L.A., Bjerkestrand A.A. (eds.), Best Practices and Methodologies in Service-Oriented Architectures (OOPSLA 2006 Workshop), Unipub (2006)
Download the Full Article and the Short Positioning Paper
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
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.