user-stories – Ben Wilcock

In the previous posts I discussed how I went about building my SOA ‘Entity’ service for Products by using a combination of Java Web Services, Java EE and the CouchDB NoSQL database. In this final post in the series I’m going to leverage some of the technical assets that I’ve created and implement some new user stories using some popular SOA patterns.

My current Product Entity Service implementation is very business process agnostic, and therefore highly re-usable in any scenario where consumers want to discover or store Product information. However, as it stands the Product Entity Service is designed to be used within a trusted environment. This means that there are no restrictions on access to operations like Create, Update or Delete. This is fine within a strictly controlled corporate sandbox but what if I want to share some of my service operations or Product information with non trusted users?

Lets imagine that in addition to our in-house use of the Product Entity Service we also wanted to cater for the following agile ‘user story’…

It’s hard figuring out how to get a balance between agile development and strategic architectural goals, but its not impossible. It’s important to understand that you need both if you are to enjoy sustainable success over long periods. Too much emphasis on the here and now can result in brittle engineering. Whereas too much emphasis on pure engineering can often mean that not enough business value get’s delivered.

My advice is simple. Agile projects deliver functionality based on the requirements fed into the project as User Stories. The key to achieving harmony is to ensure you create user stories that capture both the functional and non-functional requirements of your project. Some agile authors refer to this as ‘building an architectural runway’ – the point being that its very bad to ‘run out of runway’ during take-off.

I realise that. In truth non-functional requirements are often better suited to the acceptance criteria of a story rather than being a story in their own right. However, when your running a programme of projects, committing to architectural evolution in this way will help you to ensure that you never get boxed into a corner. Your software should remain strong enough to support what you currently have, but will have enough headroom left over to accommodate any foreseeable requirements.