The Pragmatic Architect

The role of a Software Architect is not a purely technical role within an organisation.

While you are tasked with ensuring technical competence you must also have an appreciation for the business goals of your organisation and understand what is required of you to help achieve them.

The majority of companies are not in the software production business, they are in the solution delivery business.

That means that being a Software Architect is a delicate balance between ensuring software is being built in the right way but also ensuring that it ships to customers so it can deliver value.

This requires a pragmatic outlook taking into account many different factors and influences and finding a way forward on all fronts.

Debt Accounting

Technical debt is incurred whenever a sub-optimal choice is made in the solution to a problem.

This is very different from implementing something badly, instead this can mean not dealing with all edge cases, not optimising performance or not implementing all possible variations of a feature that may be technically possible.

This amounts to trying to rationalise the scope of work and ensuring that something that is viable is achieved within opportune timescales.

Viable in this context means not only that it delivers tangible value to users but that the value is delivered via the application of viable engineering, meaning it is testable, scaleable and adaptable.

Whenever you chose to incur technical debt, and you will be faced with situations where you have to, ensure that you understand the nature of the debt, the limitations it will impose and how you will engineer it out of the product when the time comes.

No project is free of tech debt so having an effective strategy for dealing with it is an essential skill.

Maximising Opportunities

As an Architect your primary goal within your organisation is to engineer the solutions it requires, but achieving this by the application of solid engineering principles is no less important.

These dual responsibilities will often clash which is why you must always be on the look out for opportunities to advance both causes when they arrive.

Your organisation will primarily be concerned with the delivery of features, the details will be left in your hands, so learn to recognise an opportunity to deliver a solution and advance your underlying engineering platform at the same time.

Alternatively by having a close understanding of any previously incurred tech debt you may also be able to advance a solution that addresses these issues as well as delivering the required value.

In this sense you can save others in the organisation from themselves by giving them the solution they need rather than necessarily the one they are asking for.

Pragmatism in knowing which battles to fight would also come under this banner, knowing when the business imperative is too strong to try and turn the situation in an opportunity for refactoring or engineering. 

All in the Presentation

Architects often cross the divide in an organisation between the technical and the non-technical.

This often means developing two different forms of communication, you must be able to explain technical concepts to those being asked to implement them but conversely explain the same items in plain english to those being asked to fund or resource the development.

One set of people want to understand the detail and get to grips with the technicalities of what is being asked for and one does not.

When talking to non-technical people through an architecture the conversation has to focus on the benefits that will be realised by taking a particular approach, shaping the conversation like this enables people to make the correct decisions.

As proud as you may be of your solution, the details of your genius will not have the desired impact on your non-technical colleagues, it is much better to talk in terms of outcomes rather than the technicalities of getting there.

Being a valuable member of a team usually involves being well rounded enough to able to see problems and challenges from multiple perspectives.

As an architect being a zealot who only ever thinks about the technology will ultimately decrease your value to the team and reduce the effectiveness of your solutions.

In any aspect of life finding balance can be difficult but simply being open to the possibility that an organisation has goals beyond simply producing software is a good start.   

One to Rule Them All

Software engineers often display a strong preference for compartmentalisation, a place for everything and everything in its place.

With this in mind it might seem like heresy to suggest that all source code for an estate of products should be stored in a single code repository.

Naysayers will scoff at the notion but many organisations that maintain extremely large code bases, namely Google, Facebook and Microsoft, have moved to the concept of a monolithic repository with every line of code in a single place.

Have these development teams taken leave of their senses or could it be that the benefits of having one repository to rule them all are too good to ignore?

A Wonderful View

Having the ability to view a entire code base all at once can enable us to identify patterns across many different areas of code that may otherwise be difficult to spot.

Tools that produce such metrics as duplication, technical debt or even security issues gain a whole new power to deliver insight when they are scanning every line of code you have at once.

Having the whole code base in view will also empower developers to find more ways to share code, by performing even relatively simple searches through the IDE developers will be able to uncover where similar problems have already been solved to the one they are facing.

This increased capacity for collaboration coupled with a more inclusive attitude to code ownership can reduce the need to re-invent the wheel and ensure re-use becomes a default approach.

Atomic Refactoring

Its frequently the case that we are prevented from doing the right thing because of the potential pain in trying to manage the change across multiple code bases.

Once all the code is in a single place not only is it easier to envision the changes that need to happen but it can be implemented in a single atomic operation.

Even a simple yet wide reaching change such as re-naming a class or changing a namespace can be achieved across the entire estate in a single operation.

This can also prevent refactoring getting off to a false start where the true impact of a change isn't fully realised before implementation begins.

The freedom this gives a development team to contemplate refactoring that they would never normally be brave enough to attempt can liberate them to do the right thing on a much more regular basis.

Simplified Dependency

A potential headache in maintaining any code base relates to the management of dependencies.

This can be tough enough when dealing with dependencies on 3rd parties but when we create a large set of interconnected internal code bases we only increase the size of this potential nightmare.

By essentially building all our internal dependencies from source we reduce dependency hell to its smallest possible size.

The benefits of atomic refactoring and a complete view of the code base also make the job of updating a dependency easier and more palatable then may normally be the case.

Many reading this might be thinking isn't this desire for a monolith going against many of our ways of thinking for creating independent pieces of code such as SOA or micro-services.

This is where I feel we need to draw a distinction between how we organise our source code and how we deploy it output.

A single repository doesn't have to mean a vast single solution or project.

It is possible to realise all the benefits described in this post whilst still on a day to day basis working on a small and specialised area of the code base.

The fact that it is possible to load the entire code base doesn't mean that has to be the normal course of operation, but the fact we can if we choose to see our entire world at once gives us the ability to more effectively shape it.

It would be wrong to suggest that moving to a single repository is pain free, it does place extra stress on tooling and all the companies mentioned that have adopted the approach have had to adapt their ways of working, but the potential benefits it can bring are difficult to ignore.