There's small changes you make when developing that you often disregard as too simple to matter. One such example is shown below.
Dates should be ordered: YEAR, MONTH, DAY. (e.g. YYYYMMDD, YYMMDD, YYYYMM). Time should be ordered: HOUR, MINUTES, SECONDS (HHMMSS). The reason for this is that files will always be sorted in correct chronological order.
As a build manager I use this most in my Gradle scripts for ordering the build output logs.
on Monday 2 September 2013
Service oriented architecture is really starting to take flight in my organisation, but despite how mesmerising this new architecture is, its worth noting how much more difficult debugging has become.
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!
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!
Subscribe to:
Posts (Atom)