'Morning! (or whatever form of salute that suits better your time zone)

Today I'll be blogging about my thoughts and quite brief experience to this day as a developer who is learning whatever is needed, in order to become a systems administrator ambassador, and I'll do this in an attempt to better understand what this role entails, and to try to describe to you why is this middle-man position is so much needed in the world of software development today.

At present day, I work for vLex, an online legal information platform. This enterprise is located at Barcelona, Spain, and it's been growing since its birth back in 1998 (this I read from their page, I've only been working there for 3 years now), but I believe that the growing curve has taken a steep step since an argentinean IT team was formed about 6 or maybe 7 years ago.

This team, of which I'm part of, consists now of seven persons, and works closely with a smaller team in Spain in order to improve and maintain the platform, solving the needs of the clients and learning whatever technology is required along the way. A part of the team in Spain consists of the much scorned but needed systems administrators. Those kind of employees you've probably heard being characterized regularly as practical nazis (even from a professor at my university) because of their jealousy when it comes to managing the IT infrastructure of the company, with regard to the developers that use that infrastructure in order to add value and build the product that the enterprise is trying to sell. If you've ever read any of The Daily WTF articles that have anecdotes about the adventures of IT workers around the world, there seems to be an infinite source of short sightedness in this kind of fellows.

Nevertheless (and before my colleagues from spain kick me out of the sysadmin team if they ever read this), their job is clearly a must have at any enterprise that needs to maintain an IT infrastructure in order to provide a layer of service to any other part of their staff. From the developers that use that infrastructure to maintain and develop new software, up to the management layer, and back to the sales team that engage in.. well, sales. The productivity of those other parts of the enterprise sinks (if it doesn't completely cease to be) when they have to deal directly with the intricacies and gears underlying the tasks that they've been hired to perform.

On the other hand, and perhaps so we can balance this out, we as developers have certain vices that don't come easy when we are talking about taking care of that infrastructure we so much need, so the labour of the team that keeps the circus running in the background is easier, or at least not so much a pain in the arse. From security measures we never bother to take, to shortsightedness when it comes to assesing the resources, profiling our creations, and measuring the impact we could have in order to safely execute a program we just developed so that it won't tear down the entire system and ruin the party for everyone. We also sometimes do our fair share of the mistakes.

In summary.. come on, let's admit it, we need that layer of technicians so they can save our butts when somethings falls apart (being this a webserver, an oracle database, or anything else that requires some level of specialization and experience in order to get it working smoothly), because even if we developers could work our way around to solve the issue at hand, we may also break something else because the mentality of a developer is not the same of as that of a sysadmin. The sysadmin is more concerned with security and performance of the system, whether the developer seems to lean more to "let's just get this thing working so we can get back to coding".

Perhaps all of this, combined with the distance that comes when there's a team working for you overseas, brings a storm of lack of communication that pretty much difficults the work for both sides of the pond. For the last two years of work I've been a witness to all kind of misunderstandings that provoke friction, animosity and distrust between members of both parties. It's not easy to overcome this, and I believe that productivity has been sometimes hindered because of those events.

This year a different approach has been brought to life from the upper layers of management that kind of address this issue. Some practices of the Scrum agile methodology are being followed, and I've been appointed as "Systems Ambassador", a position that didn't exist previously. My job is to specifically address the issues that concern both the sysadmin team and the development one, as well as having a view of the entire picture, something that up to this day only the C.T.O. had.

Extracted from my job description:

- Help in the transference of essencial information between the Sysadmin and Dev teams, at stand-up meetings.
- Maintain the local development environment of the argentinean dev team running smoothly.
- Lead on the research of new technologies regarding systems architectures, write improvement proposals, develop new pilot projects on them.
- Gain trust from both sides, but mostly from the Sysadmins through a careful administration of the tasks at hand related to that specific area.
    This last point is related mainly to politics and the issue I've been ranting previosly about: smoothing all the roads that come and go between people that have different scopes, and improving the communication among them. It entails being "politically correct", and also able to perform nicely on both sides, as a developer, and as a sysadmin. It involves some kind of interdisciplinary art, although we are only talking about IT. It also involves getting in touch with the people behind the proffesional, so whenever shit hits the fan, we will have the necessary trust in the work that our colleague is doing and not start blaming each other.

    In addition to all of this, there's another aspect that has come to life recently with the new tools that a Sysadmin needs in order to maintain and report the status of the systems, and focus on the big picture instead of being consumed by petty tasks. I'm talking about administration tools like Chef or Puppet.

    This tools provide a framework that puts up a layer of abstraction between the sysadmin and the system itself, and they do it by giving the administrator an API where he can code his needs. There's a real need to think as a developer in order to be able to do this, so in the long term there must also be some kind of transformation of the Sysadmin mentality towards the Developer one, just as my job is to take the road on the other way.

    I haven't had any experience yet with those tools, but from what I read, there's more to them of programming language than of the old configuration files, so they should be treated the same way we treat we treat our source code: with repositories and versioning systems. And they are a must now as the infrastructure keeps on growing and growing, and the team is overwhelmed with all kind of incidences and troubles that arise on an everyday basis. We need to see the big picture and manage it accordingly.

    In the end, the line between our worlds is getting blurried, and that implies that there'll be more learning to do and communication skills to shape up. But this ambassador stuff not only applies in this kind of scenarios between two teams that do different kind of work. It's a must whenever there are groups of people that need to work together and there's a big gap between, be that 1000 kmts, or just that they work on different perspectives of the same problem. We must improve our communication skills, precisely because we don't want to, and have always been more comfortable dealing with a computer than with a human being.

    I'll be blogging about my experiences this year on this subject, but also on other stuff... at random, but always about IT, so I stay on topic with the name of the blog.

    Hope you learned something from reading this! :-)
    Enlaces a esta entrada
    Related Posts with Thumbnails