This pilot was the first real test of the work of the group I had joined, known as Architecture Technology Pathfinding(ATP). The architecture in the title was actually multiple architectures, and multiple uses of the word.
The main Architecture was about application structure, and it was a detailed description of an N-Tier environment, with interfaces invoking Business Services which would then invoke Data Services and such. The implementation of it was based around the BEA web server product, and DHL Systems had in fact been an early customer and supporter.
But how do you define the applications? We were strong adherents to the Zachman Architecture Framework for starting with concepts, then models, then implementations of models down to code. Frank and I were focused on the Data Column of Zachman, with overlap into the Process column when defining the CRUD functions on data. In the application architecture these CRUD functions were the lowest level services that supported everything else. The overall approach across the architecture was service-based, with a service being defined and made available through an exposed interface, so that everything behind the interface was unaffected by what used it (and vice-versa) as long as it could provide what the interface said it needed. Very OO, of course, and a hint of SOA (which had not appeared as a term yet).
The other main use of ‘architecture’ was that as used in RUP, summarized as development of an application by first creating an overall architecture for the app, and then building it up in the multiple iteration approach of RUP (not Agile, which wasn’t a well-known term yet either). Selling RUP and its iterative approach was a big desire of the key people in ATP, as a means of moving away from a big-bang approach to development that had failed in the past.
The thing was, it had to be sold to IT execs in DHL proper, and there was one of those for almost every country in the world (although we focused on the USA and Europe as the likely place that success of RUP would then spread from.) Many an IT exec had blown off iterative, mainly because it was believed you could not define a specific end date for iterative development, and so you could not estimate it. The fact that past projects with planned target dates and estimates had usually missed both by wide margins didn’t count. The execs wanted something that made big-bang work, not something different they could not understand or felt they could control. However, the whole combined Architecture approach espoused by ATP had taken some time to develop, and had involved some other DHL areas, so it could not just be ignored. That is why the pilot for Shipment Tracking was devised, to illustrate the use of the Architecture and Methods. The complications came when the design started and some non-believers tried to undercut the whole thing….more next time.
No comments:
Post a Comment