I am telling this story as a build manager, and not a developer. The application is simple; Spring MVC front end, a service bus and a hand full of services (one for getting bank details, addresses and a third for generating documents).
SOA favours buy over build, and that is indeed what we did; in most cases we purchased off the shelf web services, the UI was developed by a third party, and the service bus was configured internally.
Round 1 of the build involved deploying the application and its stubs. This went well and we were able to successfully run through the customer journey. As the stubs were developed by the team writing the front end, they had a great deal of control over what the stubs done - our developers provided the WSDL and the third party developed to that spec.
Round 2 started integrating the service bus, and each service being sure not to add too many variables at once. Defects were raised, but for the most part this was pretty successful too. The early exchange of the WSDL meant we were all singing off the same hymn sheet.
Round 3 is when we finished adding new features, changed WSDL's and started hammering through the defects list. This is where the problems started. The interesting thing here is that because you have a lightly coupled architecture its easy to lose track of what each person is working on. We had one regression with the address lookup feature which we instantly put down to the new build of the UI - in actual fact the problem was due to the service bus not changing the config to take the change made to the UI. Whilst the problem sounds simple, it involved a lot of running around between different teams trying to isolate the problem, and because SOA is still maturing (as are the staff working around it) governance is still a little thin on the ground.
GET YOUR GOVERNANCE IN EARLY!
0 comments:
Post a Comment