A little over a year ago, Aquila Heywood set out on a course to transform the way our business works. We've embraced Agile principles and have re-imagined the way we deliver software. Throughout the transformation we guided ourselves by ensuring that we are:
All three are essential to making Aquila Heywood an ongoing success; however, the next few days give me an opportunity to focus on the items 2 and 3. Are we still building things right? How we can we improve our team's velocity? How can we deliver value to our customers more quickly? In the past year, we've transformed the way we develop software by bringing in new tools and new processes, and introducing techniques such as XP, Continuous Integration and Continuous Delivery. We've got a lot more to discover, which is why I'm pleased to be attending the JAX London Conference this week alongside six other Aquila Heywood developers. This conference focuses on Java and Software Innovation; this is an opportunity to see what is new in the industry, what we can learn from what other companies are doing, what's new in the world of Java and pick up some ideas to transform the way we work further.
It's important to challenge what we do and how it could be improved – getting insights from others going through similar transformations is an efficient and effective way of doing this. It also gives us some perspective and the chance to think about our challenges in new ways.
I'm particularly looking forward to hearing about the changes in the recently-released Java 9, and keen to hear anything to do with improving the way teams work and the metrics of software development.
Day 1 of Jax began with 'Architecture with Agility', a workshop run by Kevlin Henney, looking at Agile and systems architecture. It was an enjoyable and thought-provoking workshop. He proposed that an architectural definition should answer three questions:
Whenever a change is proposed, the above should be answered and documented in a visible way within the Company.
Before we started our agile transformation at Aquila Heywood just over a year ago, the majority of developers had an understanding of the architecture, but not always the rationale behind it.
One question that comes to mind is what an Architect is and what a company would want from one. In the software development industry, an Architect can take on many roles: a mentor, a communicator, an observer, an advocate, an experimenter, a developer and so on (by no means an exhaustive list). Surely we strive for all developers to have a range of these qualities?
One aspect of the Agile Transformation involved taking a look at how architectural decisions were made. The Company decided to move away from having an Architect job role and try a forum-based approach. This approach gives developers the opportunity to engage with architectural decisions and give them a forum to pose questions regarding the rationale behind the way some of the components interact. It allows fresh graduates/new joiners the opportunity to gain knowledge of the current architecture and bring fresh ideas to the table. Taking advantage of people coming into the codebase later in its life is key since, with a fresh pair of eyes, new perspectives are gained and new questions can be posed.
'All architecture is design, but not all design is architecture. Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change.'
To conclude, we must remember that among the parties most affected by the systems architecture are the developers. They live and breathe it, and it affects their day-to-day decisions and the way they code. Documenting the rationale behind architectural decisions is key, giving developers a platform to pose questions concerning those decisions and allowing them to shape the future of the systems architecture.