Chaaaaaaaaaaaaaaa-ching!
There it goes again, the sound of yet another vendor's cash register signaling the purchase of SOA enabling tools by a customer who may or may not have any legitimate rationale for doing so besides succumbing to propaganda. Could the most recent cha-ching be the result of a customer hoping for instantaneous deployment flexibility or software reuse? Or, could this customer be hoping for immediate productivity improvement and reduced integration efforts that are thought to be implicit by simply writing a check with lots of digits?
The savvy SOA customer, however, understands that the "A" in SOA stands for architecture and that any vendor cha-chings must be justified by engineering analysis showing how purchased products and selected development tactics are compatible with or enable the objective system's architectural objectives. Because the term architecture probably has as many definitions (and mis-definitions) as SOA, it is important that I establish the definition used as a basis in this article:
Software Architecture = {Elements, Form, Rationale}
Elements represent the development products at the heart of a software system: the classes, threads, components, and processes, for example, that provide a system's core functionality. The property of Form describes how the Elements are related to one another in terms of classes grouped into deployment components, connections between processes, and how processes are allocated to nodes. The property of Rationale describes the motivation for grouping Elements into a particular Form. For example, the motivation for developing product line software significantly influences the commonality objectives of Elements and what their Form may be in terms of defining deployable components. On the other hand, if low latency and high performance are the driving Rationale in a system, the granularity of Elements might be more coarse than otherwise and the grouping of those Elements may occur in a Form where they can execute on the same processor.
A system's Quality Attributes (QAs) are typically the foundation of the Rationale motivating the definition of the corresponding system's Elements and their corresponding Form. These QAs, or –ilities, are typically represented by a collection of considerations that may include performance, scalability, security, product line, survivability, and safety that must be prioritized and used as program-wide beacons to be used as a basis of guiding all technical and programmatic and decisions. Doing anything else constitutes design and development based on personal preference, reliving past experience, and conjecture.
As opposed to following a true QA driven approach for developing software architecture, some aspiring SOA aficionados become intoxicated with its flexibility enabling properties and fail to consider other QAs, such as performance and security, which might very well be jeopardized as the result of rash decisions made while in the impaired state. One of the extremely important responsibilities of an architect is to realize that not all QAs can always be simultaneously met with the desired fidelity and that priority based tradeoffs will have to be made to achieve the appropriate balance.
For those who know me or have read Death by UML Fever, I am not a proponent of gargantuan software modeling efforts assuming that the weight of UML artifacts is directly proportional to architectural goodness. That being said, there is often great value in creating a design model that shows a general roadmap of the software architecture. A popular model for conveying this roadmap is the 4+1 View Model of Architecture where each of the views captures a different aspect of the architecture. The Logical View depicts the classes and relationships between those classes that implement a system's functional requirements. The Implementation View shows how the elements of the Logical View are grouped into deployable entities. The Process View shows how the elements of the Logical View are mapped into processes and threads. The Deployment view shows how elements of the Process View are mapped onto a system's computing resources. The "+1" View represents the architecturally significant set of use cases that are analyzed and implemented to drive development and evolution of the other four views simultaneously.
As opposed to endlessly debating what SOA may or may not be, or arguing about whether today's SOA is an entirely different beast than the approaches of those 'old' CORBA-based systems, a much better investment of time would be for the architects to understand a system's needs and choose whichever technologies and design tactics that will accommodate those needs. I learned a very important lesson early in grade school that might serve as great guidance to those soliciting guidance on usage of SOA: those who talk about it the most, do it the least. I have yet to meet a true SOA practitioner that yaps about its salvation qualities the same way that some vendors and some analysts do. The decision to use SOA (or not) as well as identifying the design tactics that enable success should be based on achieving functional and Quality Attribute goals as opposed to being pressured into technology-centric decisions, often by those blindly advocating usage of the latest software engineering silver bulletry to avoid hard work.
About the author
Alex Bell is a software architect with The Boeing Company and has over 25 years of experience in the software industry.
References
D.E. Perry, A.L. Wolf: Foundations for the Study of Software Architecture. ACM SIGSOFT Software Engineering Notes vol. 17 no. 4, October 1992
Non-functional properties, -ilities, that drive software architecture. (Software Architecture in Practice, 2nd edition" (Bass, Clements, Kazman, Addison Wesley, 2003)
Philippe Kruchten IEEE Software 12, 6 (Nov. 1995) pp 45-50
