To continue reading for free, register below or login
To read more you must become a member of SearchDataManagement.com
For what it's worth, I'm personally not as concerned with the frequent M&A activities that occur in the software industry when it comes to the service-oriented architecture (SOA) vendor space. While a vendor being acquired certainly causes some amount of anxiety for an IT organization, it's important to remember that SOA came into existence as a means of instilling vendor independence for the middleware and integration space.
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.
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.
|
