IBM BluemixDevelop in the cloud at the click of a button!

Exploring the fundamentals of architecture and services in an SOA, Part 1: Use architecture and levels of abstraction to create a better SOA

Why is architecture important in SOA?

In this first article in the series, get a closer look at the elements of a Service-Oriented Architecture (SOA), examine the benefits of architecture, learn how levels of abstraction help improve the development process, who creates and uses the architecture, and where architecture belongs in the software development life cycle.

Share:

Bertrand Portier, IT Architect, IBM

author photoBertrand Portier works for IBM SWAG SOA Advanced Technologies (formerly EIS). He is heavily involved in Service-Oriented Architecture, model-driven, and asset-based development. A regular speaker at conferences and the author of several technical articles, he has also co-authored an IBM Redbook about SOA solutions.


developerWorks Professional author
        level

Gregory Hodgkinson (greg.hodgkinson@7irene.com), SOA Lead, IBM

Gregory HodgkinsonGregory Hodgkinson is a lead consultant at Prolifics (www.prolifics.com). Previous to that he was a founder, director, and the SOA lead at the company 7irene. He has 10 years of experience in software architecture, initially specializing in the field of component-based development (CBD), then moving seamlessly into service-oriented architecture (SOA). His extended area of expertise is the software development process, and he assists Prolifics and IBM customers in adopting RUP framework-based agile development processes and SOA methods. He is still very much a practitioner, and has been responsible for service architectures for a number of FTSE 100 companies. He presents on agile SOA process and methods at both IBM (Rational and WebSphere) and other events and has also co-authored a Redbook on SOA solutions.



04 September 2007

Also available in Chinese

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
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
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
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.

Summary

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.

Acknowledgements

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.

Resources

Learn

Get products and technologies

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into SOA and web services on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=SOA and web services
ArticleID=253132
ArticleTitle=Exploring the fundamentals of architecture and services in an SOA, Part 1: Use architecture and levels of abstraction to create a better SOA
publish-date=09042007