Whenever I'm at a client I tend to ask, "Who decides what open source packages are acceptable?" Nine times out of 10, people will say something about an "Architecture" group. Maybe there's a single architecture group that sets standards across the entire department, or, more often, there are several groups that offer a set of services that may overlap. The more moving parts in an IT department the less clear people are about who will be responsible for running Nexus.
Take one example: I encountered a company that had a central architecture group alongside another team that managed deployments. There was some confusion: who would manage Nexus. Eventually they decided that Nexus fell under the auspices of the Architecture group because this group was setting license policy and that's why they were bringing it in in the first place. I had two takeaways from this:
- This is an entirely new problem that most organizations haven't adapted to yet - having a comprehensive view of everything in your Development Infrastructure stack.
- While everyone was cordial, there was some tension. Some unknown set of overlapping responsibilities that wasn't entirely development nor ops. I do think that while DevOps preaches harmony it may also encourage lack of clarity for who is responsible for running something like a repository manager.
...and this wasn't a one-off situation. Take OSS governance as an example: it could be a function of Legal. At other times, it is performed by a group that works for the CTO. But, it's still all over the map. In some cases you might have individual technical development groups that take the initiative. Even though no one is telling them to, they understand what's coming.
When it comes to leadership, I do think there's something of a leadership vacuum for development infrastructure...
...Enter the ALM Architect
I was recently checking out Tasktop Sync, if you've never heard of Tasktop Sync or Tasktop Dev you should take a look. If you've downloaded Eclipse you've probably been exposed to Mylyn. Tasktop Dev is a commercial version of the open source tool. Mik Kersten, TaskTop's CEO has been at this for many years, his efforts have often overlapped with Sonatype's as Tasktop and Sonatype are both very involved in the Eclipse Foundation. Kersten has started to use a new term "ALM Architect" as he did in the Eclipsecon 2012 keynote.
So, is the ALM Architect the missing leader in the IT department? Would the ALM Architect be the person ultimately responsible for directing decisions around continuous deployment, repository management? Maybe...
ALM? What do you mean by that?
First, let's talk about ALM. You don't hear us using the term ALM too often, but our tools and products fit very squarely into this area. From Wikipedia: "Application Lifecycle Management (ALM) is a continuous process of managing the life of an application through governance, development and maintenance." So, yes, if there is to be an ALM architect, I think they make decisions about builds, CI servers, repository managers, etc.
I think it is the norm right now for most organizations to have as many approaches to ALM as there are development teams. Some corporations do consolidate all teams on a single technical standard, but, in most organizations, reality forces teams to adopt different approaches for different projects. Many corporations could benefit from centralizing the decision-making process for ALM "design" into a single group, and things would be more efficient if you could sit back and say, "Right, repository managers, that's the responsibility of the ALM Architect".
ALM is getting more and more complex over time...
While I think this job description has promise, I have yet to meet anyone that would call themselves an "ALM Architect". What's relevant about this term is that it captures the evolving scope of the job. Here's what I mean...
A few years ago, you could have a build manager. They simply managed the build and set up a simple CI server. Maybe they also ran the SCM system. That all worked fine until the emergence of cloud-based approaches to development, continuous deployment, and an array of development infrastructure technologies that is increasingly both heterogeneous and highly-integrated.
Get that? Five years ago you used a fairly bland collection of technologies and everyone used the same tools. Today, there's a new tool, language, SCM system, or development approach introduced in the stack every month. From Cloud-based frameworks to different build tools, you need to support a heterogeneous development infrastructure or people are going to be less productive. If that business unit needs to deploy an app to Heroku to meet a deadline even though it is against policy, well they might have independent decision authority to just go off the roadmap and make it happen. Likewise with GitHub, how many times did GitHub show up by surprise because one of the engineers just put it on a credit card?
Conclusion: I think ALM Architect is something you'll hear more often because Development Infrastructure isn't getting any simpler.
That's what I think of when I think about an ALM Architect. Someone who is responsible for setting high-level strategy, recommending which technologies are used, and managing the ongoing task of adapting your development infrastructure to constant change. Do you have an ALM Architect on staff?
