Bick Group

David Linthicum

Subscribe to David Linthicum: eMailAlertsEmail Alerts
Get David Linthicum: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: SOA & WOA Magazine, ERP Journal on Ulitzer

SOA & WOA: Article

Building a SOA...

Best Approach and Best Practices

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.


More Stories By David Linthicum

David Linthicum is the Chief Cloud Strategy Officer at Deloitte Consulting, and was just named the #1 cloud influencer via a recent major report by Apollo Research. He is a cloud computing thought leader, executive, consultant, author, and speaker. He has been a CTO five times for both public and private companies, and a CEO two times in the last 25 years.

Few individuals are true giants of cloud computing, but David's achievements, reputation, and stellar leadership has earned him a lofty position within the industry. It's not just that he is a top thought leader in the cloud computing universe, but he is often the visionary that the wider media invites to offer its readers, listeners and viewers a peek inside the technology that is reshaping businesses every day.

With more than 13 books on computing, more than 5,000 published articles, more than 500 conference presentations and numerous appearances on radio and TV programs, he has spent the last 20 years leading, showing, and teaching businesses how to use resources more productively and innovate constantly. He has expanded the vision of both startups and established corporations as to what is possible and achievable.

David is a Gigaom research analyst and writes prolifically for InfoWorld as a cloud computing blogger. He also is a contributor to “IEEE Cloud Computing,” Tech Target’s SearchCloud and SearchAWS, as well as is quoted in major business publications including Forbes, Business Week, The Wall Street Journal, and the LA Times. David has appeared on NPR several times as a computing industry commentator, and does a weekly podcast on cloud computing.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.