Caught in a crossfire that I don’t understand*
(Badlands – Bruce Springsteen)
Back then in the early days of the 21st century every IT project seemed carefully structured, beautifully organized and especially very well documented. Most of these projects followed some version of the Rational Unified Process (http://en.wikipedia.org/wiki/IBM_Rational_Unified_Process), process framework created originally by IBM. In order to reflect at least my personal experience in such projects properly I’d rather use the term RIP-based projects here. I simply can not get rid of the nasty feeling, after a few years of involvement in such projects, that the RUP framework itself has been developed so that one can sell expensive tool licenses to customers. Rather big IT consulting companies used it usually to set up a huge organizational structure around each RIP-based project enabling them to sell an almost unbelievable amount of man days additionally. If you’d like to find out more about all the roles and artifacts described by the RUP framework (why for heaven’s sake?!), here you’ll find a nice introduction to some of these:http://www.ibm.com/developerworks/rational/library/4871.html.
Actually these 21(?!) artifacts are related to Analysis and Design alone. The one role that really caught my eye as I read the article myself today was the role described as a Capsule Designer. Don’t know exactly what the idea behind the role is and don’t really care, haven’t met one so far unfortunately either, but it sure does sound like a person that I have very much missed in every RIP-based project so far. Some kind of pain killing capsules would certainly have been helpful at times. Since the 1st of January this year there even seems to be an even better alternative role of Joint Developer in both Washington State and Colorado in the US at least.
There has been a discussion about feature vs. component teams in Scrum for quite some time already, but the teams involved in RIP-based projects were actually hardly teams at all, rather groups of individuals organized in organization units that reflected the developed system later on perfectly according to the Conway Law (http://en.wikipedia.org/wiki/Conway%27s_law). The Conway Law states that organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations. I’ll try to describe some of these groups in the following lines according to my own experience and with my own words obviously.
1. Business
Mostly good looking girls and a few smart looking, suit wearing external male consultants with proper washing habits. As a regular geek you get to enjoy being with ’em in some of those meaningless meetings and in the company’s cafeteria. If you happen to be good looking or at least humorous and charming persona yourself this is the group to watch out for at those after-work release parties, if any.
2. Agencies
Experts in taking a few of the artifacts produced by the RIP framework and turning these into some kind of nice looking user interface. They are NEVER collocated with the rest of the people involved in the project. That way they are able to enjoy their own mostly awesome looking office spaces. A geek responsible for building the UI later on almost never gets to see ’em. He is of course provided with an email including the attachment containing all the photoshop files that the designer has sent to the release management after the work on the UI has been successfully finalized for ever and ever.
3. Architects
They are responsible for producing quite a few artifacts of the RIP-based process, either with Rational (surprised?) Software Architect or with Visio and Powerpoint in case of a rather lightweight approach to architecture, for organizing and attending meetings and writing according meeting minutes. Since they are rather busy drawing boxes and all kinds of lines between ‘em, a proper description for this role would rather be a cartoon architect. The one thing a cartoon architect does NOT EVER do is write code. The best cartoon architects are those who were lucky enough not to ever be forced to write code in the first place. They became cartoon architects immediately after they got their college degree in computer science and a well paid job in a huge international consulting company. Hallelujah!
4. Frontend Devs
Developers responsible for implementing the upfront design provided by UI designers and adapting the same (actually mostly completely changing it in despair) over the lifetime of the RIP-based project. Since the design agency gets involved into the RIP-based process very early indeed and usually only once the frontend developers are on their own when in comes to delivering the UI that makes the business people (no one really cares about the user actually) happy. That’s one of the main reasons why these guys almost never get outsourced to that Kingdom of Far Far Away though.
5. Backend Devs
Usually some geeks obsessed with interface specifications, full blown application servers and, in case they are really evangelical about their role, database stored procedures. They are really fond of moving Strings around and can not stand building anything clickable. The problem that they usually don’t anticipate before it’s too late indeed is that the final destination of their team and the software they build in a RIP-based project is almost always the Kingdom of Far Far Away.
6. EAI Devs
After having spent some years as a backend developer there is a chance that one, if lucky enough of course, gets promoted into the EAI team. These guys build the integration backbone in order to connect all those backend systems with each other successfully. It’s perfectly logical that the affection for SOAP based interfaces and interface specification documents reaches its highest levels exactly here. These guys usually tend to adore the Command pattern since it enables ’em to focus their work on the software itself without ever having to understand or deal with the business intention behind all those commands floating around. It’s a pure application server nirvana at this layer indeed. They share the same final destination as their fellow backend developers though. At the end of the road the Kingdom of Far Far Away awaits.
7. Ops
These guys are technically responsible for shipping the software produced during the RIP-based project, if any, into production. They write required deployment scripts, adjust property files accordingly after having read the release notes provided by the developers. Usually they are not involved into the whole process until the very end and only in a very unlikely case that the RIP-based project actually delivers something shippable. Mostly not collocated with the rest of the people involved in the project.
8. Component Testers
For each component involved into the RIP-based project there is an according component test team. It’s usually based on manual testing and some issue tracking software that the component test team (located in the Kingdom of Far Far Away already from the beginning) is using in order to communicate with the developers who are supposed to fix all the identified issues. In most cases when there is a valid issue identified the release management reduces the severity and priority of the issue at hand so that it can be ignored until after the release party of the RIP-based project, if any.
9. Integration Testers
In case the RIP-based project actually delivers more than one shippable software component at some point the integration test team gets involved. It usually gets involved very late in the project since it does take significant time before 2 software components can be deployed successfully into the according integration environment. The team is usually located in the Kingdom of Far Far Away already from the beginning as well.
10. Release Managers
Usually quite a few of external, suit wearing, really expensive dominantly male consultants. Very experienced and highly skilled Excel and Blackberry users. Spend significant time in according release management meetings and in company’s cafeteria with above mentioned girls from the business department whenever possible. The main task of the successful overall release manager is to hide the actual status of the RIP-based project from the higher management for as long as possible. The main task of the successful release manager responsible for the delivery of a single component of the entire system is to hide the actual status of his own component from the overall release manager for as long as possible. His main goal is to report problems only AFTER at least one other release manager had to report these and to blame everything on the late delivery of the colleague of course.
11. Data Warehouse Specialists
Responsible for providing business related reporting to higher management. They are usually not really an official part of any RIP-based project. At some point they do get involved though and would really like to suck up all of the database data developers produced into their star schema so that it can be analyzed and reported properly. The development teams are usually confused by their sudden appearance and don’t really know what to think of it. They’ll never get to see any of those management reports anyway. And any time the operational database schema changes due to further development later on, the data warehouse guys tend to become really upset since this usually breaks their ETL data suck up pipeline. Quite a few escalation meetings are to be expected in this area between different building blocks. Mostly will these conflicts be resolved by a main cartoon architect who will, after an according change request has been properly submitted and budgeted, open his cartooning tool and draw a new line between the data warehouse and some of the EAI boxes available and click the Save icon accordingly (cartoon architects tend not to use keyboard shortcuts).
I was lucky enough though to leave the kind of working environment described above quite a few years ago already since I desperately wanted to develop working software instead of mainly writing documents and doing politics that huge organisational structures basically feed on.
So in case you still happen to be working in the kind of environment described above, I’d actually have only one advice for you to follow … run like the wind blows my friend … RUN!
