Developing an application that is new and has it's own database can be pretty easily done offline. By offline I mean disconnected from the client's networks and systems. Since the application is new and the database is new the developers are generally free to develop within corporate standards. It is very easy for a developer to disconnect from the corporate network and take their work somewhere else to work more productively. They are free to use tools that they have used for years and even new tools that they have found useful. What does all of this have to do with modeling integration points?
Well if you have to integrate with existing systems or third party systems then it isn't possible to disconnect from client network. It is often necessary to use a client machine to develop the code since these machines submit to heavy scrutiny and corporate security policies. License violations are also of concerns to organizations that have hundreds of thousands of dollars at stake. This can lead to a less productive developer since the tools and techniques they have developed may not be applicable on a machine absent of the technologies and tooling required. The client processes for obtaining software usually amounts to weeks of back and forth emailing and in the end usually denial of the tool or technology requested.
The other issue that comes about with external integration is the black box effect. It is complicated to describe exactly how the two systems will interact at a protocol level. There for when writing the requirement the writer simply places a black box around the integration point by saying "system A will integrate with system B and do thus and such". Wow! In those few words there is a ton of complexity that gets glossed over.
So why am I blogging about this? I have wondered for several years now if this is not just an engineering problem that needs to be solved. How many devices do we have that communicate through the USB interface. Do you have any devices that use serial, parallel, firewire, etc...? Why not treat these third party integration points as if we are designing a new device that communicates over USB? I am getting a little over my head talking about hardware but I want to give visual that everyone can understand. What makes USB work is the ability to standardize the interaction between the computer and the device.
I believe that with some thought a simple process can be put in place to model these integration points. Once the model has been created and verified, say by a unit test suite, then the developer is free to move to a more productive mode of operation. Disconnecting from heavily regulated client networks and moving into a productive development environment focused on developing high quality code in a rapid and reliable manner. I have a simple form that I am developing that will document the desired interactions between systems and hopefully will turn the black box into a transparent box that can then be estimated easily and validated for accuracy.
This will also help focus the implementation effort on implementing the new system instead of the quirks of the external system. While this should eliminate the black box nature of the specification process it will not remove the need for integration testing. It will still be necessary for the system to be integration tested once dropped in place but the system can be developed off the client network. Happy developers and hopefully more cost competitive fixed bid projects. A topic for another time.
Level 1 Discussion Form
No comments:
Post a Comment