NEWS AT SEI
This library item is related to the following area(s) of work:Software Architecture
This article was originally published in News at SEI on: July 1, 2007
Most of the practitioner-oriented materials about service-oriented architectures (SOAs) build on the SOA hype and focus on the benefits of SOA in terms of achieving business goals. Those benefits are real and substantial, but what about the many design decisions architects must make that affect the system’s performance, interoperability, security, and modifiability? What can architects do to mitigate the risk of failing to meet those quality attribute requirements? According to the Software Engineering Institute (SEI), the answer is an early architecture evaluation.
In their technical report titled Evaluating a Service-Oriented Architecture, SEI researchers Paulo Merson and Phil Bianco, along with Rick Kotermanski of Summa Technologies, describe SOAs and discuss SOA design considerations and tradeoffs that can help the architecture evaluator identify and mitigate risks in a timely and effective manner.
There are many definitions of SOA, but none is universally accepted. However, according to researchers at the SEI, one central notion is common to them all—that of service. An ideal SOA service
From the point of view of a software architect, SOA is as an architectural style where systems consist of service users and service providers. Because SOA involves multiple systems, business entities, and technologies, its overall complexity and the political forces involved need to be factored into architecture tradeoff considerations more than in single-application designs where technical concerns predominate. One method that can be used to conduct SOA evaluations without any adaptation is the SEI Architecture Tradeoff Analysis Method
To guide evaluators and help them identify and mitigate risks to their systems, researchers at the SEI have compiled information about the architectural approaches and design considerations and tradeoffs that are particularly relevant to SOA. Because architectural design decisions determine a system’s ability to meet functional and quality attribute goals, asking the following questions when designing an SOA can be especially helpful:
The right choices will help to achieve the desired interoperability, modifiability and performance.
These design decisions affect quality attributes such as interoperability, performance, modifiability, usability, and, evidently, security.
Because decisions about SOA tend to be pervasive and have a significant and broad impact on business, performing an early architecture evaluation is particularly valuable and highly recommended. Balancing SOA aspects against other software architecture concerns is particularly challenging in an SOA software architecture evaluation.
For more information
Please tell us what you
think with this short
(< 5 minute) survey.