Sander Hautvast 20 Aug, 2010
Share 
This is the first blog in a series that describes the top 10 of Java EE middleware management problems. It´s title could also be “single point of failure”. This is not about software. Instead, it’s about the person in your middleware team that everybody relies on, and clings to when things get difficult or even worse, get totally out of hand.
Imagine a typical middleware team in a fairly sized company. John is the manager of this team. The middleware team is continuously struggling to keep up with all the new products that are introduced by development teams and their solutions. The team members and Unix administrators Leo and Lloyd are maintaining the J2EE application servers, web servers and a queuing product to connect to the old company’s mainframe. They are fairly successful in their jobs, at least the number of incidents has subsided, performance is reasonably good, they know how to deploy new software versions, and they do middleware upgrades in the evening hours.
The Unix gurus Leo and Lloyd both have a long history with the company and will probably stay with the company until their retirement. The new guy Dave (originally also a Unix administrator) has undertaken the effort of getting to know all this new fancy Java stuff. When Dave is not in the office, Leo and Lloyd are a bit helpless as far as the application server is concerned.
Dave recently improved the availability of the company’s website by introducing clustering, has written deployment scripts to improve on deployment speed and quality, and worked with developers to get better log statements from the application. He shows ambition. He works late hours, seemingly ignoring the continuing stream of incidents and the nagging customers at the helpdesk. Over and over John praises Dave, provides him with raises and bonuses, persuades him with some success to spread his knowledge and hires new people to assist him (they all left by the way).
John has become dependent on Dave for his day-to-day operations and middleware development surrounding the growing middleware management stack and this situation worries John. If Dave ever decides to leave, the company will be in big trouble. A new project wants to introduce BPM tooling and Dave is already reading the product documentation. Leo and Lloyd are not able to keep up with Dave, and by the way, BPM tooling is way out of their league. Hiring an expensive external consultant could ease the pain here, but only temporarily. Some knowledge of the BPM product should be secured in the organization. John has a hard time guaranteeing website stability and supporting innovation in new projects.
Dave is willing, but cannot share his intimate knowledge of the application server, because there’s no one able to understand anything beyond the basics. Dave himself likes his job, but might have other goals and dreams as well, like an occasional holiday or raising a family, things that interfere with the weekend and midnight work. Moreover he has just found out that he is actually tired of the multitude of repetitive tasks he has to deal with every day. He’d rather be a developer, or even an architect. How did he end up here?
John has a “dependency problem”, because he has become “addicted” to Dave who is the “hero” that keeps the middleware operation and middleware development going. This is a risk to the availability of the company’s website and the projects that need work done in test environments. The company may lose customers and projects might run late.
There is a growing need for experts in the middleware field that have more skills than the average administrator, but do understand the administrator’s problems and worries. Often middleware experts are external consultants who assist in development projects and move on to new ones instead of sticking to work they find mindless. So what can John do to maintain a healthy team of middleware oriented professionals?
Above all, John needs to find a person that Dave can team up with. John could try and motivate Leo or Lloyd (or both) to learn the skills needed to get to a certain level of expertise that Dave recognizes. The problem here is that Leo and Lloyd are excellent Unix administrators, Java and BPM are out-of-scope. Another problem might be the (lack of) ability of Leo and Lloyd to learn this new fancy Java stuff and the BPM middleware.
If John can prove to his manager that the middleware team is not properly scaled with regard to the amount of work (the team is undersized) then John could try and find one or more skilled middleware professionals and expand the team. John might be facing a big challenge here because skilled middleware professionals are pretty hard to come by these days, unless you are willing to pay.
Dave’s assignment will be to “share knowledge”. But if Dave does not want to cooperate then John needs to persuade him to change his behavior. He also needs to stimulate Dave to share his knowledge, by stating his expertise in the matter, and by emphasizing the negative effects of his behavior (like his own fatigue or the risk of downtime if he’s on holiday). If that does not help then John might want to dig deeper to find out Dave’s personal motives. Is it competitiveness, prestige, perfectionism or lack of social skills? This might become a psychological exercise.
The problem could also be in the technology itself. If John is not able to support the system with his team members, he could try to eliminate complexity, standardize as much as possible, take out error-prone procedures and automate boring repetitive tasks. Or switch to other technologies that are widely supported.
As it turns out, quite a number of us have been in hero-like situations ourselves. Looking back I ask myself: “What kept me there in the first place? Was it the sense of being needed that felt pleasant? It stopped me from growing as a person and as a professional. I’m happy I left in the end and guess what, they still exist…”
