Understand the importance of architecture in SOA
Your software development team has decided to embrace Service-Oriented Architecture (SOA) and enable your enterprise to take advantage of its benefits, including increased responsiveness, better alignment of IT and business activities, and overall lower IT costs through reuse of existing assets and easier integration.
When adopting an SOA approach, architecture becomes even more critical—after all, the "A" in SOA does stand for architecture. Although software architecture has long been touted as crucially important to successfully building IT systems and applications, unfortunately, many software development project teams often just give lip service to the idea of architecture rather than actually practice it.
Explore the benefits of architecture
Let's start by examining the reasons that software architecture is important and why SOA makes it even more important.
- Abstraction: By providing abstractions of software systems, architecture creates a simplified view of the software so that it can be easily described and understood while hiding details. This view often includes providing an abstraction of existing running implementations.
- Addresses all concerns: All validated concerns (whether functional requirements, qualities, or constraints) are addressed in a coherent way with an architecture. Architecture separates concerns and addresses them separately, while at the same time making sure they are not conflicting.
- Communication: Architecture provides different perspectives (also referred to as "views" or "contexts") of a system for different stakeholders with different concerns, allowing all stakeholders to communicate and understand what the system is (in their terms).
- Consistency: Adopting architecture styles and principles—such as the ones included in architecture frameworks, reference architectures or architectural patterns—results in consistency across projects, which improves interoperability of IT systems.
- Reuse: Architecture by its very nature enables reuse because it provides a description of the building blocks of an IT system that may be reused in future assemblies. Also, existing assets, such as existing implementations, can be reused within new solutions once they have been included in your architectural specifications.
- Team work: The structural aspect of architecture allows for the assignment of tasks to teams that can work both in parallel and physically separated from each other. Think, for example, of assigning individual components to teams. Once described at an architectural level, these components can be designed, implemented, and unit-tested in isolation.
- Accountability: Architecture includes the record of design (architectural) decisions, which make explicit when, why, and by whom a decision was made and what alternatives were considered.
- Prescription: Architecture provides an unambiguous description to the designers of specific parts about what each part of the system is and how it behaves. Also, it provides clear specifications to guide the implementers (developers).
These concepts are explored more in depth in this and upcoming installments in this series.
Who uses architecture?
Software architecture is the responsibility of the software architect, who uses it to communicate with stakeholders, provide accountability, and assign work to teams.
A specific architecture provides different views, each with a focus, and each addressing concerns that are relevant and can be understood by specific stakeholders. An example in the case of SOA is the service collaboration view, which describes the behavior of services in an environment with other services. This view is used to communicate with designers, who specify how this interaction should be realized, and implementers, who specify how the interaction should be implemented. The architecture is also used to communicate with stakeholders, irrespective of where they are in the development process. For example, an architectural overview is used by the software architect to present the solution to users, managers, projects sponsors, or project managers.
The software architecture also acts as a record of the decisions made. For example, the software architect can address functional and nonfunctional requirements of a system by making architectural decisions on structure and behavior, usually using specific architectural patterns. The architecture description includes the rationale behind choices, the alternatives envisaged, as well as a record of how each requirement is addressed in the architecture. The software architect is responsible (accountable) for addressing all of the requirements. In the same way, designers and implementers are responsible for respecting the architecture and addressing the parts of the architecture to which they are assigned.
Finally, as the software architect works closely with the project manager, the structure of the architecture is used to assign work to teams. The structure can, for example, be based around packages or components. The realization (design) and implementation (code) work of the specific parts of the architecture can then be addressed by buying software packages, outsourcing to providers, or developing in house, optionally by separate teams.
Examine the role of abstraction in SOA
In "Who uses architecture?" you learned that architecture is important because it facilitates abstraction of the future (or current) system. In this section, we define "level of abstraction" and introduce those levels of abstractions which that are critical to SOA.
What do levels of abstraction provide?
Abstraction provides a simplified view of the software where it can be completely described and understood while hiding irrelevant details, allowing you to show only the information that is relevant to a given context. Abstraction allows for communication with people with different goals and skills, using terms they understand, and reducing underlying complexity.
You have probably heard the phrase "higher/lower level of abstraction" or "abstraction layers" many times. The goal of levels of abstractions is to reduce complexity. Higher levels of abstraction have less detail; lower levels have more.
An analogy that applies to levels of abstraction is that of a black-box view (a higher level that does not show implementation details) and a white-box view (an inside look at how things work). For example, a conceptual analysis model is a higher level of abstraction than a detailed design model because it omits details of the design components and elements (which show how the architecture is realized). As you move down abstraction levels, you would need more elements to represent the same thing.
The important thing is that a specific level of abstraction is relevant to a set of people (for example, design level for designers and implementation level for developers).
Key SOA levels of abstraction
Please note that these four levels of abstraction are not the only SOA levels of abstraction. This section describes what abstraction means and how it relates to SOA by listing levels that are important in an SOA context. Also, note that it looks at an SOA development project (for example, from business process modeling to code implementation) and not at the deployment or management of production applications.
There is no official list of levels of abstraction in an SOA environment. However, the following levels of abstraction are important to consider when architecting service-oriented solutions (ordered from higher to lower):
Figure 1. Key SOA levels of abstraction
- Business. This level of abstraction makes sense to business people, such as business strategists or analysts. The shape of the business architecture is formed at this level. Elements of a business architecture include organization charts, business goals, key performance indicators (KPIs), business processes and their activities and, in the case of SOA, conceptual business services. Component Business Modeling (CBM), detailed in Part 2, belongs to that level of abstraction.
- Analysis. Analysis and design are considered a single discipline by the Rational Unified Process, and usually, analysis elements evolve into design elements. We like to make the distinction, however, because analysis can be considered the level of abstraction where IT meets the business. It is the most conceptual IT level, and it is paramount to the SOA promise of providing business value. With SOA, the key analysis-level activity is called service identification, which results in a set of conceptual services identified as needed, and business aligned, and which form the input into more detailed design.
- Design. Design is about defining core elements of the architecture, and also, at a more detailed level, the design documents about how the architecture is realized. This article series is targeted primarily at this level. With SOA, the design elements are oriented around services, service interfaces, or service interactions. A key characteristic of the design is that it should trace back to elements at higher levels of abstractions (for example, business processes or use cases), including requirements. This ensures that there is a record of how the design addresses requirements and also allows for change impact analysis. Note that design is not the implementation of the architecture, but the design of what the architecture is and how the architecture should be implemented (when derived from analysis) or an abstraction of the code (when abstracted from implementation). (Please note that these two design views should be reconciled.)
- Implementation. Implementation is the code level of abstraction. As described in the next section on model-driven development, development tools and frameworks can be leveraged to generate much of the implementation from models at higher levels of abstraction, particularly from design models. This allows for higher-quality code and for improved developer productivity (freeing them to focus on the business logic).
Architectural significance and requirements
RUP explains the software architect as follows: "The software architect has overall responsibility for driving the major technical decisions, expressed as the software architecture. This typically includes identifying and documenting the architecturally significant aspects of the system, including requirements, design, implementation, and deployment views of the system." Requirements and architecture are pillars that cross various levels of abstraction, and are not limited to a specific level of abstraction. For example, a requirement may be described at a high level of abstraction in business terms, but another one can be a very detailed technical description.
Requirements, whether functional (required capabilities) or nonfunctional (qualities and constraints) have a direct impact on the architecture. They need to be fully specified and understood by the architect, who should validate them as they are gathered and analyzed. Validation needs to occur to make sure that, for example, all requirements are traceable to a business goal (in the business architecture), there are no conflicting requirements, and all of the requirements are "implementable." Sometimes people refer to architecturally significant requirements; the architect should also keep in mind that an SOA solution (with reusable assets) and its requirements will evolve over time. That means that he or she needs to pay particular attention to maintainability and scalability. Note that for SOA projects, it is typical for functional requirements to be initially discovered by modeling business processes (at a business level of abstraction); RUP then recommends formalizing these requirements using use cases (at an analysis level of abstraction).
Most of the work associated with requirements or architecture happens in a specific phase of a project, described in the following section.
Relationships between levels of abstraction
Now that we have identified the key levels of abstraction, let's take a closer look at the relationships between them.
If you look at these levels of abstraction you can see that the same sorts of "decisions" are specified at each of these levels: that is, detail about how the software is structured in terms of parts, what these parts look like, how they fit together, and how they behave. These decisions are recursively nested and add increasing detail at lower levels of abstraction. And, as noted previously, decisions specified at the higher levels constrain those at the lower levels.
An "architecturally significant decision" indicates a decision that is important at an architectural level of detail. The design level of abstraction contains all the most important decisions about software structure, packaging, interfaces, and connections which constrain all of the lower-level decisions in the implementation level. By most important, we mean those decisions that provide the overall architecture with a structure that will hold up best over time. For example, we decide on architectural parts (components) and interfaces that are least likely to change unnecessarily over time. An example of an unnecessary architectural change would be to change an interface just because the persistence mechanism has changed. The impact of this type of change should be limited to a change in implementation (and therefore limited to implementation level of abstraction).
As you can see, architecture summarizes the most important decisions about the software (and hardware) and limits them to those decisions that will stand the test of time. It may seem like a fine line to decide what is and what is not part of the architecture, but this separation is important in allowing us to manage the complexity of the software models. It is also the ability to make these distinctions that is one of the most important skills of an experienced software architect.
Service-Oriented Architecture building blocks: The SOA Solution Stack
Software architecture reduces complexity by abstracting key concepts, and separating concerns. For the service-oriented domain, the SOA Solution Stack provides 9 layers (separation of concerns) and their logical architectural building blocks (abstractions) that can be used to represent a Service-Oriented Architecture at a high level of abstraction.
Figure 2. The SOA Solution Stack
For more information about the SOA Solution Stack, read the article, "Design an SOA solution using a reference architecture"* (see Resources section). For the purpose of this article, simply note that an SOA solution's concerns can be separated into five functional layers and four nonfunctional layers. The five functional layers are:
- Operational layer. Includes all custom or packaged application assets in the application portfolio running in an IT operating environment, supporting business activities
- Service components layer. Contains software components, each of which provide the implementation for, realization of, or operation on a service
- Services layer. Consists of all the services, including abstract specifications of a collection of (one or more) business-aligned IT functions defined within the SOA
- Business processes layer. Defines compositions and choreographies of services exposed in the services layer
- Consumers (or presentation) layer. Provides the capabilities required to deliver IT functions and data to end users to meet specific usage preferences
Note that the bottom functional layers are more of concern to service providers, whereas, the top ones are more for service consumers to focus on.
The four nonfunctional layers are:
- Integration layer. Provides the capability to mediate, route, and transport service requests from the service requester to the correct service provider
- QoS layer. Provides an SOA with the capabilities required to realize nonfunctional requirements (NFRs)
- Information architecture and business intelligence layer. Ensures the inclusion of key considerations pertaining to data architecture and information architectures
- Governance layer. Covers all aspects of business operational life-cycle management in SOA
The UML 2 Profile for Software Services
The Rational Unified Process for Service-Oriented Modeling and Architecture (RUP SOMA) provides SOA guidance that is included in a RUP process and method. (See Resources for more information.) In RUP SOMA, a Service-Oriented Architecture is represented in the service model work product. Going hand in hand with the service model is the Unified Modeling Language (UML) 2.0 Profile for Software Services, which defines a common language to describe Service-Oriented Architectures at a high level of abstraction. This profile can be seen as defining building blocks for the SOA Solution Stack. All of the service model work product artifacts (which have matching services profile stereotypes) are architecturally significant, including:
- Service specification. The interface that groups a set of operations for a service definition; operations, and their parameter types or messages, are also architecturally significant.
- Service consumer. The consumer of one or more services.
- Service provider. The software element (usually a component) that provides a set of services.
- Service. Provided by a service provider, a service identifies a provided service specification (and optionally one or more required service specifications in the case of a composite service).
- Service collaboration. Used to model the interaction between a set of services to realize some behavior (often initially specified at the requirements level by a use case).
- Service partition. Logical or physical boundaries of the system (structure), partitions are usually associated with specific qualities (policies). Partitions also allow for the assignment of parallel work (for example, by assigning the design of a particular set of parts to one team, and of another set of parts to another team). Service partitions can provide a useful mechanism to model individual service-oriented (IT) systems.
For further information on the service model elements and the technique associated with creating them, see Resources.
Explore the role of architecture within the software development process
The architecture is the responsibility of the software architect, and we just explained that it crosses multiple levels of abstraction. So when do the architecture activities take place?
Figure 3 shows the RUP, its disciplines, phases, and iterations.
Figure 3. The Rational Unified Process
Architecture is not shown in the picture, so when does it take place? When does the software architect perform most of his tasks? The four RUP phases are:
- Inception. Achieves concurrence among all stakeholders on the life-cycle objectives for the project
- Elaboration. Baselines the architecture of the system and provides a stable basis for the bulk of the design and implementation effort in the next phase
- Construction. Completes the development of the system based upon the baselined architecture
- Transition. Ensures that software is ready for delivery to its users
A well-established software architecture activity does the following:
- Starts during the inception phase, when the software architect assesses risks and performs the initial analysis
- Peaks during elaboration, when the software architect specifies most of the design and helps assigns work for construction
- Usually finishes during construction, when the software architect ensures that the code respects the design
As you can see, most of the architecture work is performed during the elaboration phase of a project.
In this article, you learned how using abstraction allows for clearer and easier presentation of a complex design, speeding the overall development process. You explored levels of abstractions that are relevant when architecting SOA solutions and artifacts that can be used to model service architectures. Finally, you examined where architecture and the role of the architect fit in the software development process.
The authors wish to extend appreciation to their architect colleagues, with a special thanks to Franco Potepan and John Catlin for their review of this article.
- See Wikipedia's entry on software architecture.
- Read essays on software architecture from Carnegie Mellon Software Engineering Institute.
- Learn the SOA vocabulary with this SOA Terminology developerWorks series.
- Find out more about The Open Group Architecture Framework (TOGAF).
- Read the article, "Model-Driven Software Development" (IBM Systems Journal, Volume 45, Number 3).
- Read "The UML 2.0 Profile for Software Service" (developerWorks, Apr 2005).
- From IBM Redbooks®: Building SOA Solutions with the Rational SDP.
- Read The Rational Unified Process: An introduction (Third Edition) by Philippe Kruchten (Addison-Wesley Professional; Dec 2003).
- Read "Design an SOA solution using a reference architecture" (developerWorks, Mar 2007).
- Browse the technology bookstore for books on these and other technical topics.
- Take advantage of developerWorks Live! technical events and webcasts.
- In the Architecture area on developerWorks, get the resources you need to advance your skills in the architecture arena.
- Check out IBM on demand demos to learn about various software products and technologies from IBM.
- Stay current with developerWorks Live! technical briefings.
Get products and technologies
- Plugin: RUP for Compliance Management Plug-in V1.0.
- The Rational Unified Process for Service-Oriented Modeling and Architecture (RUP SOMA).
- Download IBM product evaluation versions and get your hands on application development tools and middleware products from DB2®, Lotus®, Rational®, Tivoli®, and WebSphere®.
- Participate in the discussion forum.
- Use the power of social networking with developerWorks blogs and get involved in the developerWorks community.