Friday, March 20, 2009

Application Pwnership

Who owns this application? What can possibly be complicated about such a simple and innocent question?

Unfortunately, the answer to such a question is not that easy. Or at least, we have created software organizations that make it hard to answer.

Though it makes sense to have a division of labor between different teams qualified on certain aspects of software applications, the main problem resides in the partial system views that such a division creates.

Out of developers' hands, an application is oftentimes perceived by QA, DBAs or Operation teams as a giant black box:
(yes, it is a canonical black monolith of 1-4-9 proportions)

In fact, this giant black box has a few keyholes on it and, through these keyholes, they can barely peer into it. Consequently, the black box effect leads to QA teams seeing applications as sets of buttons to push, DBAs seeing them as data and table spaces and Operation teams dealing only with cryptic log files and alarms of all sorts.

No-one knows what is inside this darn black box. And when somethings goes haywire, only the Magician of Oz is deemed able to do something:

Now that everybody is so agile, this kind of concern may sound irrelevant. After all, developers are now generalizing specialists, so the barrier between them and other teams is now significantly lowered. Or is it?

The reality remains for the most part a difficult hand-off of applications between teams. I have seen different tentatives to improve things (including detailed operational manuals), but at the end of the day most of these attempts amounted to shallow knowledge transfers.

Ownership needs more.

Do you have any success story where applications have been successfully pwned by different teams?


David Dossot said...

Obviously, the book of faces has it right and does not have to deal with this kind of pesky details.

Artur Mc Djanoff said...

Well, I think I have one of this success story in mind.
It happen on a big project for french administration. The project was developped without systems skills, lower dba skills and very good developpers.
The great work was made just before the production phase and during this one.
The project leader was understanding the lack of good system sills in his team as integration phase was a failure.

So after a very short period of recruitment, our team was composed of six java developpers ( formely thirsty ), one dba and two system administrators, I was one of them.

In first, we solve the deployment problems; installed three sites, made the load tests and made support from the production Go Live during more than a year.

We have no strictly organization, only very good communication with a small team.

Each part was leader in it technology but all problems were explained to all members and every one was able to propose anything.

I think that each job is very specialized and knowledge tranfert is somehow a difficult.

In my sense, the communication is sufficient as a part may explain a problem to another.

You're right when you talk about blackbox. The best practice is to avoid the blackbox syndrome.
Only an dba may write a document for another dba, and so on for developpers and adminsys.

The solution, I think is to have developpers, dba and adminsys involve in each phase of a project. Then they are able to share their knowledge to their specialists colleagues without knowledge loss.

Artur Mc Djanoff said...

I've forgot the most important in my post : the customer, or business as we often call him, is the only owner of the application.

David Dossot said...


But I am not talking about this kind of ownership. I am more thinking in term of intimate knowledge and the capacity to act responsibly on the application. That is full possession or groking, if you wish.

It's really about "pwning" it!

Artur Mc Djanoff said...

Hi David,

Well, I was too narrow minded in this situation. But my example still feet to the case. The great in this one is that our small team took the project from qualification to exploitation.

There is no one who own the application pwership as everyone is responsible on his part because no one can assume all.

I think a good developpement or exploitation team is composed of developpers ( application developpement/maintenance and problem resolution ), Qualifiers (Qualification tests and problem resolution ), DBAs ( Adminitrative tasks and problem resolution ), operations teams ( Adminitrative tasks and problem resolution ) and one or several problem resolv leader ( in fact, very often the projects leaders );
in differents percentages due to the context.

The knowledge transfert must be operated :
Developpers talk to the developpers
and so on.

The documentation is very important and must live :
- Application architecture
- Systeme architecture
- Operating Manual
- Installation Manual
- stress tests results
- Exploitations Policies ( security, backup, recovery, business continuity)
- Problem database
- Methodologies and processes well documented
and so on