MARK PULLAN OF BJSS - THE ROLE OF AN AGILE ARCHITECT

In this guest blog we hear from Mark Pullan. Mark is BJSS’ Chief Software Engineer, with overall responsibility for technical output from BJSS Project Centres in Leeds and Manchester.

He has 18 years of industry experience and is a strong advocate of both DevOps and Agile approaches, and is especially enthused when such techniques are applied to the delivery of systems with complex engineering requirements.

His achievements include key technical roles on enterprise-class systems such as the 2014 replacement of the NHS Spine and the 2010 redevelopment of a leading global interbank FX platform.

One of the things I've heard from some members of the Agile Community over the years is that that both Technical Architecture as an activity and the role of the Technical Architect are obsolete.

This view is something I fundamentally disagree with, and not only because of a vested self-interest in making sure that we TAs still have jobs to go to.

I've undertaken a number of engagements for BJSS (both consultancy and delivery) where we've had to either review or rescue failing projects. An enduring theme amongst such failing projects was where organisations had adopted Agile for the first time, and in doing so had thrown away practices that had worked perfectly well for them in the past. Often this meant discarding all forms of planning and preparation in the name of emergent architecture and many-a-board covered in post-it notes.

A few of the anti-patterns I've observed to be associated with such emergent (or omitted) architecture seem to be...

-Business value is the only driver of priority. Aspects such as risk or natural ordering of dependencies are disregarded.

-Developer workflow jumping straight from business requirements to source code, with very little consideration of commonality or cross-cutting aspects

-Large-scale 'back-to-square-one' refactors commonplace, often the same code being rewritten over and over and over again as new requirements are drip-fed in.

-No commonality of approach, different parts of the system solving similar problems in very different ways

-‘Copy and paste' employed as a reuse mechanism if time pressures precluded refactoring

-Non-functional requirements being ignored in favour of functional requirements, often rearing their head again in the path to go-live (or worse, in production).

So if architecture is still needed, one thing that I think has happened is that the role of architects within Agile projects has evolved significantly as Agile has become mainstream.

Where we've come from...

A traditional (if somewhat cynical view) paints a picture of an approach where Architecture was the preserve of a team sitting happily in their Ivory Tower, issuing decrees for the developer-folk to obey. Architecture was very much an upstream process, with designs flowing downhill but very little opportunity for feedback from the code-face as to what works in practice. A lack of code-level familiarity often led to over-engineering and reduced maintainability. Tactical decisions made downstream to "get things done" would lead to code that didn't match the design, or wasn't fit for purpose with respect to key non-functional requirements.

Another characteristic of this approach to Architecture was the sheer volume of documentation produced just to communicate between silos. Rather than spending their time thinking and designing, architects would spend the majority of the time writing lengthy documents, and a lack of face-to-face interaction would lead to a corresponding amount of time from the development team reading the self-same documents.

Where we've got to...

Under an agile approach architecture is now a much more integrated activity. The Architecture itself is vitally important, as it provides a framework and set of constraints with which to guide the design activities. In turn, those activities now being very much a collaborative effort involving architects and developers at the same whiteboard.

This conveys a number of distinct advantages:

-Agile architecture is much more about thinking and communication; rich, compact documentation is still as important, but the production of reams of documentation for documentation's sake is diminished

-An integrated feedback loop is provided, with the architecture, design and implementation constantly validating each other; that the implementation matches the design and the design operates within the framework set by the architecture

-Given appropriate architectural constraints and guidelines, more of the design can be just-in-time leading to greater efficiency and more accurate low-level decision-making

-Everyone on the team contributes to the architecture (to a greater or lesser extent), not just those with the corresponding job title.

The Architect now plays the role of the benevolent dictator, with a clear authority and veto, but no longer a lone voice shouting from afar. The pitfalls of design-by-committee are avoided, and a project retains a paper trail that is sufficient for on-boarding new developers, support of the system, and meeting client technical oversight requirements.

Architectural governance is still absolutely vital, and if anything is more important given the dynamic nature of an agile project. If anything, the transition being in the manner in which governance is applied - much less about writing a big (unread) book of rules & principles up front, and more about getting inside the feedback loop and closer to the hands-on decision making (so ensuring there is an architectural governance aspect to the usual agile ceremonies - sprint planning, retrospectives, show-and-tells and the like).

Emergent vs. Evolving Architectures

Although my experiences with failing projects lead me to take a pretty dim view of emergent architecture, it is important that there is flexibility to change the architecture as the requirements change or are better understood. I'd probably term this an evolving approach as opposed to an emergent one, with a number of key characteristics:

-Architecture identifies decision points and manages risks up front, but allows decisions to be deferred until later in order to provide flexibility of implementation.
Refactoring is still an important tool, but it is a high-value activity to improve the system, rather than a constant tax needed to keep the wheels on.

-A level of up-front design allows the client's technologists to be engaged - they can review and have input to technical decisions before they are implemented
There are no sacred cows, we anticipate and expect that the architecture will change over time. The key thing being we start with something tangible with flexibility built-in, not just a blank sheet

-Constant grooming of technical debt; understanding that a small level of technical debt is often helpful in order to run a team efficiently and avoid gilding the lily, but actively managing this debt at the same time

In Summary...

It looks like we architects aren't going away any time soon, if anything, you'll being seeing more of us...