Service Specification Survey Results

Topic: Service Specification

Date: November 2013

Author: David Sprott

Background

After many years of trial and error, Services are today the foundation of the de facto architecture for the enterprise. Whether a service is implemented as a REST API or SOAP Web Service, a specification of some sort is essential for the delivery and operational life cycle management. Casual observation tells us that service specification approaches in common use are highly variable. In our survey, conducted in October 2013 we asked architects, designers and project managers to tell us how they deliver and use service specifications. The results substantiate preconceptions to some extent, but also highlight some very interesting issues.

Background to the Survey

The Service Specification Practices Survey was open for the entire month of October. Invites to participate were made by postings on numerous forum websites, blogs and mass emails to the CBDI Forum membership list, a self-selecting membership that has interest in this topic.

Respondents were overwhelmingly architects, but there were 22% designers and project managers.

Fig 1: Respondents

A majority of the 108 respondents were from large enterprises, but 37% were from medium and small organizations. Commercial, Government and Service Provider organizations were represented almost equally.

Conclusions

Consistency of approach

There is a low level of consistency of approach
The dominant specification approach is “Do it Yourself” (DIY).

There is a wide range of approaches to specification in use. The most frequently cited approach is TOGAF, which is actually a very high level, generic approach to specification. The CBDI-SAE and SOMA approaches, which are much more comprehensive, are widely used, but DIY is overwhelmingly popular. Once “Other” approaches are added to DIY, this represents over 50% of the sample.

Fig 2: Specification Approach(es) Used

Does consistency matter? Given the wide range of methods cited, it would appear that there is indeed a wide interpretation of what effective Service Specification practice is. Respondents who mentioned Zachmann, CoBit, ITIL and Agile Stories as specification approaches, must be adopting a very casual form of specification that may result in suboptimal service architecture and governance.

It was notable that there is significant sharing of specifications with external parties, both ecosystem partners and outsourcers. Both of these types of relationship represent key information based contracts across organizational boundaries, and we might consider informal approaches in this situation to be high risk.

Whilst some industry standards, such as ITIL, TOGAF, SoaML or OASIS, provide some guidance in the area of service specification, the coverage ranges from insufficient to tangental. We might infer the issue is that none of the various standards bodies that ostensibly cover this space would address the entirety of the specification task. Further that these standards bodies have a very poor record of working constructively together to address similar issues.

Specification Perspectives

3. Description level specifications are widely used.

It is notable that outline or high level Service Descriptions are almost ubiquitous, with a Survey result of 85% as shown in Fig 4. This level of specification is extremely useful for planning purposes, and widespread adoption is self-evident. It may also be expected that the format of the Service Descriptions will be relatively similar, as there is close alignment between the leading methods (CBDI-SAE, SOMA and TOGAF).

Fig 3: What service abstraction levels are defined in required deliverables?

4. Implementation independent specifications are produced by a significant majority

An equally interesting survey result shows that 61% of respondents complete some level of implementation independent specification. While well-formed services should, as a matter of principle, encapsulate the underlying implementation, this is by no means universal practice and it therefore a very positive sign of maturity in the marketplace. Implementation independence of course has many other benefits such as the potential to evolve or change the implementation approach without any impact on the service consumer.

5. Detailed specifications are widely produced for logic, exceptions, signatures/schemas.

The survey shows detailed specifications are widely produced for logic, exceptions, signatures and schemas, and by inference these deliverable artifacts are documented in a specification, not left for developers to complete. Further the survey reports a majority indicating that they complete definition of exceptions at the Design stage and a minority complete at Implementation. This same pattern is seen for QoS and Security, Performance, Logic and operation specification.

Fig 4: What elements of a Service Specification do you routinely produce?
And when in the lifecycle are these normally produced?

6. Description level specifications are usually shared with business users.

A notable survey conclusion is that Service Descriptions are shared with business users in 90% of cases. This is a remarkable result indicating that business users are generally well informed about the software services supporting their solutions, and indicates a significant maturing of the market.

What is the audience for Service Specifications?

Fig 5: Who is the audience for Service Specifications?

7. There is significant sharing of specifications with external parties and outsourcers

Similarly the survey shows external parties are an important audience for service specifications at all stages of the life cycle. The cross life cycle average of 62% for outsourced delivery perhaps reflects the market penetration of outsourced delivery. However the cross life cycle average for external service consumers of 61% is a significant indication of cross enterprise ecosystems in action, notwithstanding the 33% service provider participation in the survey.

However it must be said that the predominant audience for the specifications remains the software developers at 92%. And that whilst 90% of specifications are shared with business users, the cross life cycle number comes down to 45%, indicating that most business user involvement is in upfront planning and requirements.

Tool Usage

8. Documents and Spread-sheets are still the dominant tools used.
9. There is significant use of UML models and profiles

Not surprisingly spreadsheets, documents and the IDE remain the dominant support tools. Notwithstanding this, the level of UML and UML profile usage is clearly growing. But the absence of purpose designed tools is highlighted very clearly in the survey. The issue is well known that, while in the early stages of service portfolio and project planning, spreadsheets and documents are perfectly adequate support tools, as the portfolio grows the requirement for service specification assets management becomes urgent. It is of no coincidence perhaps this is an area that is not well served by tools!

What Tools are used?

Fig 6: What Tools are used?

10. A majority of respondents are dissatisfied with tool support for communication of service specifications

The survey results show 64% clearly dissatisfied with tools for communicating service specifications. This may be interpreted as requirements capture, reviewing, reporting and management.

Fig 7: How effective are your current tools are in communicating service specifications between the different roles/groups across the organization?

How can Everware-CBDI Help?

Talk to us about

Service Architecture and Service Specification capability improvement, including reference architecture, process and tooling
How the Everware-CBDI Service Factory can support high quality Service Specification and automated delivery