There are several common steps that we recommend when folks are undertaking an SOA initiative to reduce or mitigate SOA risks. Everyone has their own area of interest or focus when it comes to best practices and risk mitigation. In order to keep the scope of my remarks within a reasonable length, let me offer up a few data-oriented service recommendations.
More on SOA data services and architecture
Learn SOA strategies for handling big data and beating latency
Find out how the rise of SOA is causing integration gateways to converge
Read about how the automated function point can improve SOA estimates
Categorize and document services during the design phase. It's important to identify service categories (and subcategories) as a means of establishing a framework for service definition, design and development. This also ensures that reviewers can quickly understand the scope of service design that is being undertaken. We often encourage our clients to identify their data services by subject area (e.g., customer, product, etc.) or functional capability (cleanse, augment, match, etc.). Processing services are the most common initial services to be developed. It's common to differentiate high-level (or business) services (Invoicing, Purchasing, etc.) from lower level (or functional) services (lookup/search, retrieving records, etc.).
Differentiate data from processing services. It's important that data services are establishes defined separate from their processing services brethren. We often find folks implementing services based on the calling conventions and interfaces of an individual software development project. The end result tends to reflect a set of application-centric functional conventions, not services that simplify application communication and functionality development. There's rarely any attention paid to defining services that relate to retrieving, defining or modifying business data. Without well defined data services, your SOA environment will be hampered in its ability to support different business areas or applications.
Identify a series of usage scenarios for each service. Because of the visibility and buzz that web services and SOA receive from the media (and even internal to most companies), it's important to prevent the SOA development effort from being perceived as a "field of silver bullets and dreams." All too often, we find that services are designed, developed and delivered to an underwhelmed audience. The disappointment isn't caused by the technical staff diverging from the project plan or goal; the problem occurs because the folks relying in the individual services didn't fully understand the scope of functionality that was going to be delivered. The value of the usage scenarios is that it dramatically reduces the likelihood that there will be any misunderstanding regarding the capabilities of the SOA components.
Leverage existing data management rigor. Since the premise of SOA is to establish a shared data and processing infrastructure, it's important that everyone that utilizes the services, either from a development or a usage perspective, understands the details. We're not talking about the internal workings of the service; we're talking about the inputs, outputs and processing results of the service. If data is manipulated within the service — like a zip code lookup — or delivered — like providing customer address details — it's important that the data and the processes are referred to using terms that are already in use within your company. If everyone uses zip code, calling a service a PostalCodeLookup is a bad idea.
Dig Deeper on SOA data services and architecture
Related Q&A from Evan Levy
Learn the difference between change data capture (CDC) and data federation. Find out how companies can use both data integration technologies to ... Continue Reading
Embarking on a data integration project? Make sure you know common data integration issues and challenges before beginning your next integration ... Continue Reading