Here’s a topic for which I’d really like some community input, and I think it’s something that many of my readers have probably had to do, are doing, or would be interested in the result. If you’re adopting SOA, you’re likely using a Service Registry/Repository of one form or another. It can range from a set of scribbled notes on a whiteboard or post-its in some architect’s office/cube, to Excel, to one of the many vendor products available for this purpose. So, assuming you are actually using one of these mechanisms, what are you recording about your services, the consumers of those services, and how/where are you capturing the relationship between the two? In this post, I’m going to start with the first question, the answer to which constitutes what I call the technical service record. Please note that the focus of this is on services that have a programmatic interface, and not the broader business service or ITIL service space, although I am very interested in the overlap between this record and the service record that would existing in an ITIL v3 Service Portfolio.
Here’s a list of items that could be recorded about a service to get the discussion started. For each item, I’ve provided a description of what that item is, whether it is optional or not, the visibility of that item (public, consumers only, service manager only, etc…). Please contribute your thoughts on other attributes that could/should be captured along with its optionality (is that a word?) and visibility.
|Name||Human-readable name of the service||Yes||Public|
|Description||Human-readable description of what the service does||Yes||Public|
|Owner/Manager||The person accountable (in the RACI sense) for the service. At a minimum, this is the person to contact in order to begin using the service.||Yes||Public|
|Question: Should the owner be public, or only visible to registered consumers? A registry/repository could facilitate interaction with a potential consumer without publicly revealing the owner’s name.|
|Interface Type (or should it be types?)||The technical interface type, such as SOAP, REST, POX/HTTP, etc.||Yes||Public|
|Internal/External||Is the service exposed internally, externally, or both?||Yes||Public|
|Note: External users can only see services exposed externally.|
|Service Type||Taxonomy classification for purposes of mapping to technology platform||Yes||Internal Only|
|Production WSDL URL||URL for the production WSDL (Required for Web Services)||No *||Consumers|
|Deployment Platform||On which logical platform is the service hosted?||No *||Internal Only|
|Deployment Location||What is the physical location(s) of the service? Preferably, this should be a link into the CMDB.||No *||Internal Only|
|Test Plan/Scripts||A link to a test plan or specific test scripts for the service as provided by the provider.||No *||Internal Only|
|Performance Profile||The expected resource utilization of the service.||No *||Internal Only|
|Development Cost||The cost incurred in creating the service.||No *||Internal Only|
|Estimated Integration Cost||Expected cost for consumers to integrate service usage.||No *||Internal Only|
|Current ROI||Current development ROI generated based upon development cost, cost to integrate, and current number of consumers||No *||Internal Only||Status||Status of the service: Planned, in development, in production, decommissioned)||Yes||See below|
|The visibility of this is directly tied to the state. For internal services, status is open to the public. For external services, a service should only be visible if it is in production.|
|Version||The version of the service associated with this record.||Yes||Public|
|Created Date||The date this record was created.||Yes||Internal Only|
|Modified Date||The date this record was last modified.||Yes||Internal Only|
Of course, now that I attempted to put this list down with some simple attributes, I’ve realized that whether or not things are required or visible to particular parties are dependent on the status of the service, whether it is exposed externally or not, the interface type, etc. It’s just hard to make that fit into an HTML table and still have this entry be readable. Anyway, if there isn’t anything proprietary or confidential about the structure of your service records, consider sharing it here. I promise to publish the end result of this effort here for all to share for free. This isn’t limited to Web Services, either. If you’re using REST, what information would you provide about the collection of resources that comprise the service to potential users of those services? I would guess that many of the above attributes would still apply, and could certainly be accessed themselves through a REST interface, since a serivce record is a resource in and of itself.
Thanks for your participation! If you’d prefer to send me your information directly without publicly posting it here, send me an email at todd at biske dot com or you can send me a direct message on twitter at toddbiske.