distributedlife

One of my favourite topics in the design of a service oriented architecture. In my experience the majority of services are designed to be enterprise in nature but end up being implemented as project services. Let me explain the difference:

Enterprise service: A service built to support the business that can be consumed by anyone, anywhere for any reason. Enterprise services have the highest levels of quality, availability and performance necessary to support predetermined use and spikes that occur through service mash-ups.

Project service: A service built to support the business that can only be consumed by a discrete set of consumers that are constructed at the same time. The service is coupled to the set of allowed consumers as there is no guarantee of correct behaviour via an untested consumer.

Why would you build a project service?

It’s cheaper. There is less to test, less to implement. The code can be of a lower standard. Shortcuts can be taken. It could be a wrapper for an existing service that uses an older technology and wrapping it reduces interoperability issues. The service may only need to exist for a short period of time; months rather than years.

Why would you build an enterprise service?

This is the goal of services and service oriented architecture; discrete deployable components that can be utilised and marshalled in new or interesting ways. There is a reduction in future deployment costs as the service is already available for use and has been tested against all potential consumers not just those that already exist.

The trick with enterprise services is getting them well defined, future proof and aligned with business scope. Failing to do so will result in changes, retesting, versioning issues, etc.

The downward spiral

What I have experienced is that design and architecture want enterprise services but end up with project services due to a number of constraints:

First and foremost is that the decision to implement services was taken when there was nowhere near enough time to implement them as enterprise services. Building enterprise services takes time because they can’t make assumptions about who is calling them. This impacts their interfaces and can place additional requirements on security and auditing.

Secondly there has been a lack of business buy in for services. Services are for the business but sometimes it seems to me that IT is pushing services as a solution to give agility, mobility or whatever to the business but it isn’t what the business necessarily understands or cares about. They want that agility and don’t necessarily care how it’s implemented.

So if we want business buy in and a business definition of scope then we have some work to do to make it happen. Until then we have an IT definition of scope. I personally think the latter is fine if the system architect is on her game. Scope is scope as long as it is well defined and has a purpose.

An immature development environment is next on the list. “Team! Go out and build services. They are just like objects but over the wire”. A lack of experience in implementing services results in lower quality; poor design decisions; interfaces that are not well defined, that don’t do as they say and a set of services all built in slightly different ways making configuration and maintenance a nightmare.

In the end the enterprise services come out as project specific. The development team realises that they have to get what they need for their project done now and to hell with the future. We’ll never use these services again anyway…

So is it just better to implement project services from the word go or is it better to shed responsibilities as the due date draws near? In some organisations a project service still needs to implement exception management, auditing, security, validation and the functionality itself. If we start shedding these features then we are going to be doing less than we must.

If we limit the service to only one consumer then we can start making assumptions about what is being passed into the service. In reality these assumptions do nothing but leave untested properties on fat interfaces generating a technical debt that will have to be paid if we ever attempt to use these services again.

What do I think?

Previously as my role as lead of the service testing team I pushed hard for enterprise services. That was how we were testing and the bugs were plentiful. But we ran out of time and the services were reclassified as project and the bugs gleefully went out to production.

I no longer hold the viewpoint that we should start with, or design for enterprise services.

Firstly an Enterprise service shouldn’t be designed to cater for all future applications that may need to be developed. An Enterprise Service is built so that future applications can leverage this behaviour but the end goal of unknown future applications shouldn’t drive the design of an Enterprise service.

A well defined service will only do what it has to do anyway.

We should be building our enterprise services for how the business is now with implementations that exist for now. In time the Enterprise Services will change to meet the changing business needs. This is inevitable. It does not mean however that we should generate coupling between our consumers and our enterprise services just because the consumer happens to exist now. It also doesn’t mean that we pre-empt that business change.

I now think that an iterative service development approach where the project requirements are built with a contract that is business focussed that may leave bugs in the implementations. We couple this construction with full on automated service testing so that when it comes time to consume the service again we have a full suite of tests and a list of outstanding defects to work from. We may not need to extend the interface; just define an implementation against a set of contracts and a set of tests. If we want a service to support mash-ups then we will naturally need to fix all those bugs and flesh out those implementations.

This approach relies on a mature and experienced service testing team; if you don’t have that you can read this article here where I talk about different ways you can structure your service testing responsibilities. You may be able to find a configuration to support your organisation.

It just seems to me that trying to define and build a fully fledged enterprise service before it is ever used is a little bit waterfall and we all know how hard that is. Services are meant to provide agility and flexibility; perhaps we should start building them that way.