While the notion of SOA continues to emerge, those who are implementing SOAs today are faced with a variety of challenges, including the complexities of SOA, and the work involved with understanding their existing problem domain and requirements. Those who want to get SOA right the first time quickly understand the benefits of a sound architecture and a good set of SOA design approaches.

However, the understanding of how you approach your SOA, and best practices around building a SOA, are clearly lacking. Those who are looking to gain the benefits of SOA are perplexed by the wide reach of the technology, its links with traditional enterprise architecture, and how the game has changed since the structured and object-oriented analysis and design days.

Truth be told, SOA is not something you buy, it's something you do. Thus, while the focus has been on the technology in the last few years, as people begin to implement SOA, the focus is now on the process. So, how do you create a SOA? In this article I'll walk you through the notion of SOA, and the unique aspects of the architecture, as well as the design considerations, including the ability to leverage best practices as a guide. In essence, what's working, and what's not.

Understanding the Basics
While there is this notion that SOA is all new and thus requires new approaches, the fundamentals of SOA are firmly based in more traditional requirements, analysis, and design techniques, but with the concept of services and service-based solution instances as the new direction. To that end, you can consider the steps to the construction of a SOA as basic approaches, and with a foundation in traditional enterprise architecture and traditional application analysis, design, and development...processes that should not be all that new or scary for many who are facing SOA today.

Next we should define a "SOA Meta Model" or a reference model to better understand the notions of SOA and the component parts that are required. Figure 1 represents one view of SOA, working up from the data, to the data abstraction layer, to the data services, to the services, to the orchestration layers, and finally monitoring and event management. Note that both governance and security are typically bound to all layers. Also note the way you build this stack to meet your specific needs could be very much like this or very different depending on your requirements.

The Procedure
Considering all the basics, you can divide the steps to creating a SOA into the following major steps:

1. Definition of the Domain
2. Semantic Level Understanding
3. Service Level Understanding
4. Process Level Understanding
5. New Services Configuration and Design
6. New Processes Configuration and Design
7. Technology Selection
8. Deployment
9. Testing

Note that both governance and security are systemic to the above processes, as is performance engineering. Moreover, you may have special requirements that require additions or deletions to these steps. We're also not defining most of the sub-steps here due to space constraints.

Defining the Domain
You can't boil the ocean, so you must define the scope of your SOA in an enterprise. Most SOAs are best implemented in small steps, such as moving a single division or a portion of a division to SOA, instead of an entire enterprise all at once. Small successes lead to larger, more strategic successes over time, and you need to establish the demarcation lines at the beginning of the project to provide better focus and understanding (see Figure 2)

Also note that now is a good time to do a proof of concept (POC). This is done at this point so the architect can understand the candidate technology a bit better, which means the right expectations are set as to the final solution. A POC also helps the architect understand the possibilities and limitations for considering service and process design in the target. It's really a point of learning, not a point of selection. Keep that in mind.

Semantic-Level Understanding
You can't deal with information you don't understand, including information bound to behavior (services). So it's extremely important for you to identify all application semantics - metadata, if you will - that exist in your domain, allowing you to deal properly with that data (see Figure 3).

Understanding application semantics establishes the way and form in which the particular application refers to properties of the business process. For example, the very same customer number for one application may have a completely different value and meaning in another application. Understanding the semantics of an application guarantees that there will be no contradictory information when the application is integrated with other applications at the information or service levels. Achieving consistent application semantics requires an information integration "Rosetta Stone" and, as such, this represents one of the major challenges to creating your SOA.

Defining application semantics is a tough job since many of the existing systems you'll be dealing with are older, proprietary or perhaps both. The first step in identifying and locating semantics is to create a list of candidate systems. This list will make it possible to determine which data repositories exist in support of those candidate systems.

Any technology that can reverse-engineer existing physical and logical database schemas will prove helpful in identifying data within the problem domains. However, while the schema and database model may give insight into the structure of the database or databases, they can't determine how that information is used in the context of the application or service; that's why we need the next steps.

A data abstraction, or a data services layer, provides the loose coupling between the services and the underlying databases/information stores. This provides a point of configuration to both deal with the differences between the data as physically represented and the preferred logical representation to the SOA.

Moreover, as both the data and service requirements change over time to align with the business, the data abstraction layer can be easily reconfigured to account for the differences, and since not coupled, require a minimal amount of work. For instance, the physical databases in many instances doesn't have to be changed, just the abstraction. In essence you've created an agile data layer to go with your agile services and process layers. Without this you'll find that holistic agility with your SOA is difficult to achieve.