Tuesday, April 08, 2008

Ownership

In the enterprise Software Development Project Management thought process there is this concept that software developers are resources.  I suppose from the initial project development that is arguably true, more or less.  But what happens when the project is over; the deliverables have been delivered.  Who supports the project, who maintains the project and who enhances the project?  Basically who is the technical owner or steward?

This is an important part of the "Software Development Life Cycle" that is forgotten, at least where I work.  I recently came off of a fairly successful project where we delivered a fairly standard application - a web based front end that talked to an EJB service that depending on the request would call other "enterprise" services to perform the requested function.  Kind of like the diagram below:

standard

 

So in the development of this project some of the extended services were already in existence, others were new development efforts.  I had the opportunity to design and implement one of the services.  My intent was for this service to be reused by another application I used to work with, not thinking I would really get the opportunity to see it get reused but I wanted the option to be there.  Well that other applications is getting re-done soon - and I would really like to see that project use the service I wrote for it.

Unfortunately the service I wrote does not really have an owner.  It is out there chugging along quietly behaving by itself so it is pretty much forgotten.  That seems to be pretty typical, when applications work well they are forgotten.  Somehow the concept of project ownership (or maybe stewardship) is a foreign concept in a lot of places.  If someone has developed a service/application they need to be responsible as the steward sure they can transition it to someone lese but applications should never be delivered and forgotten. 

So what does it mean to be a project steward? If you are a steward then you should be the most knowledgeable person on how the application should be evolved and reused.  The steward should be involved when changes are requested or if someone wants to use it.  They should also be responsible for documenting and troubleshooting it.  They don't necessarily have to have the final say in some decisions but their views should be taken seriously. 

When there isn't a steward the services don't get reused and they begin to stagnate, other people start to re-solve the problem the service was written for.  Knowledge is forgotten, documentation isn't written, basically the software dies and that is not good.  Our software creations can only live if we take care of them.  In the world of SOA this part of the equation is forgotten - for services to be maintainable and reusable they have to have someone that is looking out for them.

I think that is why so many open source projects are successful, they have people working on them that care about the project's success and have the sense of responsibility - the end result is owned by them.  Without that commitment software development is not much different from working at McDonald's - you crank out as many cheeseburgers as you can, as quickly as you can.  If some cheeseburgers get undercooked and make people sick - well it's not your fault really....  Someone else is responsible for making sure you do your job right.

We have to have ownership in everything we do - otherwise there is no reason to do anything.  When managers shuffler resources around because resource constraints - all it really does is make a lot of people sick from undercooked cheeseburgers software.

 

-Aaron

2 comments:

Scott said...

Funny you mention that. I am working on a project where we are implementing an Enterprise Repository that is designed to solve many of the issues you mention. As part of this, there is this person that oversees reuse (The Registrar).

Aqualogic Enterprise Repository - ALER

Aaron said...

Let me know how it goes. With out that "Registar" I think the whole concept of SOA fails a very painful death that can bring down a whole team of good developers...