Saved by virtualization

Building VMWare images is pretty straightforward. Set some parameters like number of CPUs, disk size, etc., install the OS and you're done. But what do you do when you guessed the wrong size for the disk? If you've installed Linux with LVM, then it's a simple matter of extending the VMWare drive size then resizing the logical volume onto a new disk partition. Even easier when you have good instructions.

Thank you virtualization.

Plagued by Jira

I absolutely love Jira. It's true. I think it can be totally abused and misused (like any tool), but when it's used correctly, it's an invaluable tool to the development and operations teams.


Sadly it appears as though "Jira is down" is more common than I thought. We were plagued with this at el Fiver and it appears the plague has followed me to Nokia.

Jira is down, Jira is up, Jira is down again...

Architects, agilists, roles and responsibilities

I spent some time this weekend thinking about what my new role will mean (just as soon as I get out of release hell).

• In general, where and how does a software architect fit into an organization that is (trying to be) Agile?
• In practical terms, what are an agile architect's roles and responsibilities?

Architects and Agilists

To help spur the debate in my mind, I first watched an insightful talk by ThoughtWorkers Martin Fowler and Rebecca Parsons from QCon 2008. Fowler and Parsons presented some very refreshingly realistic means and ways to bring architecture in general into the fold with Agile teams and organizations. Some things stood out and really resonated with me though.

They talk about architects as coaches, mentors and guides. This is very anti-ivory tower and very much in line with how I would like to see architects interact with teams. That is, not as the all powerful beings to be feared with all of the power to lay down the law, but instead as customers and members of the team.

In Scrum, a Product Owner is part of the Scrum team and is responsible for the functional requirements of the product. They are involved intimately with the team and work regularly with the team to achieve the goal of added functionality. In the same sense, an architect can be responsible for defining, presenting and explaining non-functional requirements to the team. Just as the Product Owner is intimately involved with the team, the architect should be as well, sitting with them on a daily basis and working with the team to achieve not just the added functionality, but the added non-functional requirements as well.

Pie in the sky dreaming? Maybe, but you have to start somewhere.

Roles and Responsibilities

Assuming you can actually figure out a way to work successfully in this brave, new, Agile world, what exactly is it that an architect should be doing. There are of course all sorts of architects (application, enterprise, integration, blah blah), but let's not complicate matters. I'm referring here only to small organizations (or small parts of larger organizations as is my situation) and the roles and responsibilities of a general software architect. Here's what my list currently looks like (I do think it's too long though).

• High-level technical vision, planning and documentation
• Development best practices and standards
• Building prototypes, common tools, general solutions and reusable components
  • Engage the teams in both defining and executing on such tasks
  • The people often best suited to build prototypes are those with knowledge of the intimate details
  • Building reusable components comes from first building usable components
  • Management of common Java libraries (lib)
  • Management of Maven parent poms, static analysis tool configuration, etc.
• Service integration between internal and external components of the system
• Technical oversight
  • Internal and external APIs (binary/Java APIs, service/REST APIs)
  • Code quality and encouragement of best practices
  • Coaching of and adherence to "Agile" software development principles for module design and implementation
• Performance, scalability and high-availability requirements
• Deployment and configuration strategies
• Monitoring and statistics gathering and tracking strategies
• Interface between technical teams (operations, first line support, etc.), business stakeholders and development teams on technical matters
  • Technical: deployment, configuration and monitoring
  • Business: statistics
• Coordination with QA and release engineers
  • Integration, performance and load testing strategies
  • Release, migration and upgrade strategies
• Coaching and working directly with development teams on a regular basis
• Technical customer to the agile development teams
  • Able to add technical user stories to the product backlog
  • Works directly with the product owners to prioritize and trim the product backlog

Summary

I don't know if I'm the right person for this job. I try to always remain humble and I know for damn sure that there are people out there that are better suited for this role. Given that, I can't see a better solution to the numerous problems (both technical and organizational) that we are currently faced with. If all goes well, I would love to see a day when I can shorten that list, where I have to worry less about the technical quality of each team and of the decisions they make. Time will tell.

So now to you. What is your ideal architect? How do they interact with teams? What are their roles and responsibilities?

After Tuesday...

...there are still lots of things to do. A nice reminder from Bob Martin and just in time for our first production release on Tuesday. Fingers crossed...

The Nabaztag

Well, I've caved and bought a Nabaztag. How can you resist when they're just 99€!

Funny timing too since we are looking to hire the guy that wrote the Hudson CI Nabaztag plugin. Looks like I'll have to make Nokia buy one for each team too!