Software Architecture for Developers: Technical leadership by coding, coaching, collaboration, architecture sketching and just enough up front design (2014)

II. THE SOFTWARE ARCHITECTURE ROLE

This part of the book focusses on the software architecture role; including what it is, what sort of skills you need and why coding, coaching and collaboration are important.

8 The software architecture role

Becoming a software architect isn’t something that simply happens overnight or with a promotion. It’s a role, not a rank. It’s the result of an evolutionary process where you’ll gradually gain the experience and confidence that you need to undertake the role. While the term “software developer” is fairly well understood, “software architect” isn’t. Here are the things that I consider to make up the software architecture role. Notice that I said “role” here; it’s something that can be performed by a single person or shared amongst the team.

1. Architectural Drivers

The first part of the role is about understanding the business goals and managing the architectural drivers, which includes the requirements (both functional and non-functional) and the constraints of the environment. Software projects often get caught up on asking users what features they want, but rarely ask them what non-functional requirements (or quality attributes) that they need. Sometimes the stakeholders will tell us that “the system must be fast”, but that’s far too subjective. Non-functional requirements and constraints often have a huge influence on the software architecture, so explicitly including them as a part of the software architecture role helps to ensure that they are considered and taken into account.

2. Designing Software

It should come as no surprise that the process of designing software is a part of the software architecture role. This is about understanding how you’re going to solve the problems posed by the architectural drivers, creating the overall structure of the software system and a vision for the delivery. Despite how agile you to strive to be, you probably do need some time to explicitly think about how your architecture is going to solve the problems set out by the stakeholders because your software system isn’t going to do this itself.

A key part of designing software is technology selection, which is typically a fun exercise but it does have its fair set of challenges. For example, some organisations have a list of approved technologies that you are forced to choose from, while others have rules in place that don’t allow open source technology with a specific licence to be used. Then you have all of the other factors such as cost, licensing, vendor relationships, technology strategy, compatibility, interoperability, support, deployment, upgrade policies, end-user environments and so on. The sum of these factors can often make a simple decision of choosing something like a rich client technology into a complete nightmare. Somebody needs to take ownership of the technology selection process and this falls squarely within the remit of the software architecture role.

3. Technical Risks

What we’ve looked at so far will help you focus on building a good solution, but it doesn’t guarantee success. Simply throwing together the best designs and the best technologies doesn’t necessary mean that the overall architecture will be successful. There’s also the question of whether the technology choices you’ve made will actually work. Many teams have a “buy over build” strategy and use products (commercial or open source) because of the potential cost savings on offer. However, many teams also get burnt because they believe the hype from vendor websites or sales executives in expensive suits. Few people seem to ask whether the technology actually works the way it is supposed to, and fewer prove that this is the case.

Technology selection is all about managing risk; reducing risk where there is high complexity or uncertainty and introducing risk where there are benefits to be had. All technology decisions need to be made by taking all factors into account, and all technology decisions need to be reviewed and evaluated. This potentially includes all of the major building blocks for a software project right down to the libraries and frameworks being introduced during the development.

The question that you need to ask yourself is whether your architecture “works”. For me, an architecture works if it satisfies the non-functional requirements, works within the given environmental constraints, provides the necessary foundations for the rest of the code and works as the platform for solving the underlying business problem. One of the biggest problems with software is that it’s complex and abstract. The result being that it’s hard to visualise the runtime characteristics of a piece of software from diagrams or even the code itself. Furthermore, I don’t always trust myself to get it right first time. Your mileage may vary though!

Throughout the software development life cycle, we undertake a number of different types of testing in order to give us confidence that the system we are building will work when delivered. So why don’t we do the same for our architecture? If we can test our architecture, we can prove that it works. And if we can do this as early as possible, we can reduce the overall risk of project failure. Like good chefs, architects should taste what they are producing. In a nutshell, this is about proactively identifying, mitigating and owning the high priority technical risks so that your project doesn’t get cancelled and you don’t get fired.

4. Architecture Evolution

More often than not, software is designed and then the baton is passed over to a development team, effectively treating software development as a relay sport. This is counterproductive because the resulting software architecture needs to be taken care of. Somebody needs to look after it, evolving it throughout the delivery in the face of changing requirements and feedback from the team. If an architect has created an architecture, why shouldn’t they own and evolve that architecture throughout the rest of the delivery too? This is about continuous technical leadership rather than simply being involved at the start of the life cycle and hoping for the best.

5. Coding

Most of the best software architects I know have a software development background, but for some reason many organisations don’t see this as a part of the software architecture role. Being a “hands-on software architect” doesn’t necessarily mean that you need to get involved in the day-to-day coding tasks, but it does mean that you’re continuously engaged in the delivery, actively helping to lead and shape it. Having said that, why shouldn’t the day-to-day coding activities be a part of the software architecture role?

Many software architects are master builders, so it makes sense to keep those skills up to date. In addition, coding provides a way for the architect(s) to share the software development experience with the rest of the team, which in turn helps them better understand how the architecture is viewed from a development perspective. Many companies have policies that prevent software architects from engaging in coding activities because their architects are “too valuable to undertake commodity coding work”. Clearly this is the wrong attitude. Why let your software architects put all that effort into designing software if you’re not going to let them contribute to its successful delivery?

Of course, there are situations where it’s not practical to get involved at the code level. For example, a large project generally means a bigger “big picture” to take care of and there may be times when you just don’t have the time for coding. But, generally speaking, a software architect who codes is a more effective and happier architect. You shouldn’t necessarily rule out coding just because “you’re an architect”.

6. Quality Assurance

Even with the best architecture in the world, poor delivery can cause an otherwise successful software project to fail. Quality assurance should be a part of the software architecture role, but it’s more than just doing code reviews. You need a baseline to assure against, which could mean the introduction of standards and working practices such as coding standards, design principles and tools. Quality assurance also includes ensuring that the architecture is being implemented consistently across the team. Whether you call this architectural compliance or conformance is up to you, but the technical vision needs to be followed.

It’s safe to say that most projects don’t do enough quality assurance, and therefore you need to figure out what’s important and make sure that it’s sufficiently assured. For me, the important parts of a project are anything that is architecturally significant, business critical, complex or highly visible. You need to be pragmatic though and realise that you can’t necessarily assure everything.

Collaborate or fail

It’s unusual for a software system to reside in isolation and there are a number of people that probably need to contribute to the overall architecture process. This ranges from the immediate development team who need to understand and buy in to the architecture, right through to the extended team of those people who will have an interest in the architecture from a security, database, operations, maintenance or support point of view. Anybody undertaking the software architecture role needs to collaborate with these people to ensure that the architecture will successfully integrate with its environment. If you don’t collaborate, expect to fail.

Technical leadership is a role, not a rank

The software architecture role is basically about introducing technical leadership into a software team and it’s worth repeating that what I’m talking about here is a role rather than a rank. Often large organisations use the job title of “Architect” as a reward for long service or because somebody wants a salary increase. And that’s fine if the person on the receiving end of the title is capable of undertaking the role but this isn’t always the case. If you’ve ever subscribed to software architecture discussion groups on LinkedIn or Stack Overflow, you might have seen questions like this.

Hi, I’ve just been promoted to be a software architect but I’m not sure what I should be doing. Help! Which books should I read?

Although I can’t stop organisations promoting people to roles above their capability, I can describe what my view of the software architecture role is. Designing software might be the fun part of the role, but a successful software project is about much more.

Create your own definition of the role

In my experience, although many software teams do understand the need for the software architecture role, they often don’t have a defined terms of reference for it. Without this, you run the risk of the role not being performed in part or in whole.

Most of the roles that we associate with software development teams are relatively well understood - developers, testers, ScrumMasters, Product Owners, business analysts, project managers, etc. The software architecture role? Not so much. I regularly ask software teams whether they have a defined terms of reference for the software architecture role and the usual answer is along the lines of “no” or “yes, but we don’t use it”. Often people working for the same team will answer the question differently.

Although the need for thinking about software architecture is usually acknowledged, the responsibilities of the software architecture role often aren’t clear. In my experience, this can lead to a situation where there is nobody undertaking the role, or where somebody is assigned the role but doesn’t really understand how they should undertake it. If the role isn’t understood, it’s not going to get done and we have little hope of growing the software architects of tomorrow.

Regardless of what you call it (e.g. Architect, Tech Lead, Principal Designer, etc), my advice is simple. If you don’t have something that you can point at and say, “this is what we expect of our software architects”, take some time to create something. Start by agreeing what is expected of the software architecture role on your team and then move to standardise it across your organisation if you see benefit in doing so.

9 Should software architects code?

Since I created a website called Coding the Architecture, I guess the answer to this question shouldn’t really come as a surprise. In my ideal view of the world, software architects should code. Somebody once told me that the key characteristic of a good architect is the ability to think in an abstract way. You can also think of it as the ability to not get caught up in the details all of the time. That’s fine, but those boxes and lines that you’re drawing do need to be coded at some point.

Writing code

My recommendation is to make coding a part of your role as a software architect. You can do this by simply being an integral part of the software development team. In other words, you have a software architecture hat and a coding hat. You don’t need to be the best coder on the team, but the benefits of being hands-on and engaged in the delivery process are huge. After all, there’s a difference between “knowing” and “doing”.

Appreciating that you’re going to be contributing to the coding activities often provides enough incentive to ensure that your designs are grounded in reality. If they aren’t, you’ll soon experience that pain once you understand the problems from a developer’s perspective.

In addition to the obvious benefits associated with creating a software architecture that can actually be implemented by real people, contributing to the coding activities helps you build rapport with the rest of the team, which in turn helps to reduce the gap between architects and developersthat you see on many software teams. To quote Rachel Davies and Liz Sedley from their Agile Coaching book:

If you know how to program, it’s often tempting to make suggestions about how developers should write the code. Be careful, because you may be wasting your time - developers are likely to ignore your coding experience if you’re not programming on the project. They may also think that you’re overstepping your role and interfering in how they do their job, so give such advice sparingly.

Building prototypes, frameworks and foundations

Although the software architecture role is much easier to do if you’re seen to be one of the development team, sometimes this isn’t possible. One of the problems with being promoted to or assigned as a software architect is that you might find that you can’t code as much as you’d like to. This may be down to time pressures because you have a lot of “architecture” work to do, or it might simply be down to company politics not allowing you to code. I’ve seen this happen. If this is the case, building prototypes and proof of concepts related to the software system in question is a great way to be involved. Again, this allows you to build some rapport with the team and it’s a great way to evaluate that your architecture will work.

As an alternative, you could help to build the frameworks and foundations that the rest of the team will use. Try to resist the temptation to build these things and then hand them over to the team because this approach may backfire. Software development is driven by fads and fashions much more than it really should be, so beware of building something that the rest of the team might deem to be a worthless pile of old-fashioned crap!

Performing code reviews

There’s obviously no substitute for coding on a real project, and I wouldn’t recommend this as a long-term strategy, but getting involved with (or doing) the code reviews is one way to at least keep your mind fresh with technology and how it’s being used. Again, you could damage your reputation if you start nitpicking or getting involved in discussions about technologies that you have no experience with. I remember having to explain my Java code to an architect who had never written a single line of Java in his life. It wasn’t a fun experience.

Experimenting and keeping up to date

You need to retain a certain level of technical knowledge so that you can competently design a solution using it. But if you are unable to contribute to the delivery, how do you maintain your coding skills as an architect?

Often you’ll have more scope outside of work to maintain your coding skills; from contributing to an open source project through to continuously playing with the latest language/framework/API that takes your fancy. Books, blogs, podcasts, conferences and meetups will get you so far, but sometimes you just have to break out the code. I’ve certainly done this in the past and one of the upsides of a long commute on public transport is that it does give you time to play with technology. Assuming you can keep your eyes open after a hard day at work, of course!

The tension between software architects and employers

I’ve been fortunate in that I’ve retained a large hands-on element as a part of my software architecture roles and I’ve written code on most of the development projects that I’ve been involved in. I’m a firm believer that you’re in control of creating your own opportunities. The reason I’ve remained hands-on comes down to expressing that it’s a crucial part of the role. For me, it’s simple … coding is essential when designing software because I need to keep my skills up to date and understand that what I’m designing will work. Plus, I’m not ashamed to admit that coding is fun.

Unfortunately many organisations seem to think that coding is the easy part of the software development process, which is why they see an opportunity to save some money and let somebody else do it, often in another country. Such organisations view cutting code as “low value”. Tension therefore arises because there’s a disconnect between the seniority of the software architect in the organisation and the value associated with the coding activities.

In my experience, this doesn’t happen in small organisations because everybody usually has to get involved in whatever is needed. No, it’s those larger organisations where the tension is greatest. I spent some time working for a medium size consulting firm where my job grade put me as a peer of the management team, yet I still wrote code. In some ways it was quite an achievement to be graded as an “Executive Manager” and write code on a daily basis! Yet it often felt very uncomfortable, as other managers would regularly try to push my name into boxes on the corporate organisation chart.

Being in this situation is tricky and only you can get yourself out of it. Whether you’re in an organisation where this is happening or you’re looking to move on, be clear about how you view the role of a software architect and be prepared to stand your ground.

You don’t have to give up coding

With this in mind, it should come as no surprise that I’m regularly asked whether software architects can continue to code if they are to climb the corporate career ladder. This is a shame, particularly if these people really enjoy the technical side of what they do.

My take on this is yes, absolutely, you can continue to code. For me, it’s quite frustrating to hear people say, “well, I understand that I’ll have to give up coding to become an architect or to progress further up the career path”. There are lots of organisations where this is the expectation and it’s reassuring that I’m not the only person to have been told that coding doesn’t have a place in the senior ranks of an organisation.

As a software architect, you take on a great deal of responsibility for satisfying the non-functional requirements, performing technical quality assurance, making sure the software is fit for purpose, etc. It’s a leadership role and coding (leading by example) is one of the very best ways to make sure the project is successful. And besides, if software architects don’t remain technical, who is growing the software architects of tomorrow?

Don’t code all the time

To reiterate my advice, software architects don’t have to give up coding. However you do it, coding is a great way to keep your technology skills sharp in our ever-changing world. Many people believe that software architecture is a “post-technical” career choice but it requires deep technology skills alongside a breadth of experience and more general knowledge. It requires T-shaped people who are able to answer the question of whether their design will actually work. Leaving this as an “implementation detail” is not acceptable. Just don’t code all of the time. If you’re coding all of the time, who is performing the rest of the software architecture role?

10 Software architects should be master builders

Applying the building metaphor to software doesn’t necessarily work, although in medieval times the people that architected buildings were the select few that made it into the exclusive society of master builders. The clue here is in the name and a master builder really was a master of their craft. Once elevated to this status though, did the master builder continue to build or was that task left to those less noble? Fast-forward several hundred years and it seems we’re asking the same question about the software industry.

State of the union

Software architecture has fallen out of favour over the past decade because of the association with “big up front design” and “analysis paralysis”. Much of this stems from the desire to deliver software systems more efficiently, with agile approaches being a major catalyst in reducing the quantity of up front thinking that is performed by many teams. The net result is that the role of “an architect” is now often seen as redundant on software teams. Many teams are striving to be flat and self-organising, which on the face of it negates the need for a single dedicated point of technical leadership.

The other factor here is that many believe the role of an architect is all about high-level and abstract thinking. I’m sure you’ve seen the terms “ivory tower” or “PowerPoint” architect used to refer to people that design a solution without ever considering the detail. If we go back in time though, this isn’t what the architect role was all about.

Back in time

If you trace the word “architect” back to its roots in Latin (architectus) and Greek (arkhitekton), it basically translates to “chief builder” and, as indicated by the name, these people were masters of their craft. In medieval times, the term “architect” was used to signify those people who were “master masons”, where “mason” refers to stonemasons because that’s what the majority of the buildings were constructed from at the time. This quote summarises the role well:

A master mason, then, is a manipulator of stone, an artist in stone and a designer in stone.

This quote could equally be applied to us as software developers.

Did master builders actually build?

The key question in all of this is whether the master builders actually built anything. If you do some research into how people achieved the role of “master mason”, you’ll find something similar to this:

Although a master mason was a respected and usually wealthy individual, he first had to prove his worth by going through the ranks as a stonemason and then a supervisor, before being appointed to the highest position in his trade.

The Wikipedia page for architect says the same thing:

Throughout ancient and medieval history, most architectural design and construction was carried out by artisans—such as stone masons and carpenters, rising to the role of master builder.

Interestingly, there’s no single view on how much building these master masons actually did. For example:

How much contact he actually had with this substance is, however, debatable. The terminology may differ but, as I understand it, the basic organisation and role of the medieval master mason is similar to that of the chief architect today – perhaps a reflection of the immutable fundamentals of constructing buildings.

Only when you look at what the role entailed does this truly make sense. To use another quote:

A mason who was at the top of his trade was a master mason. However, a Master Mason, by title, was the man who had overall charge of a building site and master masons would work under this person. A Master Mason also had charge over carpenters, glaziers etc. In fact, everybody who worked on a building site was under the supervision of the Master Mason.

To add some additional detail:

The master mason, then, designed the structural, aesthetic and symbolic features of what was to be built; organised the logistics that supported the works; and, moreover, prioritised and decided the order of the work.

Ivory towers?

If this is starting to sound familiar, wait until you hear how the teams used to work:

Every lesser mason followed the directions set by the master and all decisions with regard to major structural, or aesthetic, problems were his domain.

It’s certainly easy to see the parallels here in the way that many software teams have been run traditionally, and it’s not surprising that many agile software development teams aspire to adopt a different approach. Instead of a single dedicated technical leader that stays away from the detail, many modern software development teams attempt to share the role between a number of people. Of course, one of the key reasons that many architects stay away from the detail is because they simply don’t have the time. This typically leads to a situation where the architect becomes removed from the real-world day-to-day reality of the team and slowly becomes detached from them. It turns out that the master masons suffered from this problem too:

If, as seems likely, this multiplicity of tasks was normal it is hardly surprising that master masons took little part in the physical work (even had their status permitted it). Testimony of this supposition is supplied by a sermon given in 1261 by Nicholas de Biard railing against the apparent sloth of the master mason “who ordains by word alone”.

This quote from Agile Coaching (by Rachel Davies and Liz Sedley) highlights a common consequence of this in the software industry:

To cap this off, many people see the software architecture role as an elevated position/rank within their organisation, which further exaggerates the disconnect between developer and architect. It appears that the same is true of master masons too:

In order to avoid the sort of struggle late Renaissance artists had to be recognised as more than mere artisans it would seem that master masons perpetuated a myth (as I see it) of being the descendants of noblemen. Further to this, by shrouding their knowledge with secrecy they created a mystique that separated them from other less ‘arcane’ or ‘noble’ professions.

Divergence of the master builder role

Much of this points to the idea that master builders didn’t have much time for building, even though they possessed the skills to do so. To bring this back to the software industry; should software architects write code? My short answer is “ideally, yes” and the longer answer can be found here. Why? Because technology isn’t an implementation detail and you need to understand the trade-offs of the decisions you are making.

So why don’t modern building architects help with the actual process of hands-on building? To answer this, we need to look how the role has evolved over the years:

Throughout ancient and medieval history, most architectural design and construction was carried out by artisans—such as stone masons and carpenters, rising to the role of master builder. Until modern times there was no clear distinction between architect and engineer. In Europe, the titles architect and engineer were primarily geographical variations that referred to the same person, often used interchangeably.

The Wikipedia page for structural engineering provides further information:

Structural engineering has existed since humans first started to construct their own structures. It became a more defined and formalised profession with the emergence of the architecture profession as distinct from the engineering profession during the industrial revolution in the late 19th century. Until then, the architect and the structural engineer were usually one and the same - the master builder. Only with the development of specialised knowledge of structural theories that emerged during the 19th and early 20th centuries did the professional structural engineer come into existence.

In essence, the traditional architect role has diverged into two roles. One is the structural engineer, who ensures that the building doesn’t fall over. And the other is the architect, who interacts with the client to gather their requirements and design the building from an aesthetic perspective.Martin Fowler’s bliki has a page that talks about the purpose of and difference between the roles.

A software architect is seen as a chief designer, someone who pulls together everything on the project. But this is not what a building architect does. A building architect concentrates on the interaction with client who wants the building. He focuses his mind on issues that matter to the client, such as the building layout and appearance. But there’s more to a building than that.

Building is now seen as an engineering discipline because of the huge body of knowledge behind it, which includes the laws of physics and being able to model/predict how materials will behave when they are used to construct buildings. By comparison, the software development industry is still relatively young and moves at an alarmingly fast pace. Buildings today are mostly built using the same materials as they were hundreds of years ago, but it seems like we’re inventing a new technology every twenty minutes. We live in the era of “Internet time”. Until our industry reaches the point where software can be built in the same way as a predictive engineering project, it’s crucial that somebody on the team keeps up to date with technology and is able to make the right decisions about how to design software. In other words, software architects still need to play the role of structural engineer and architect.

Achieving the role

The final thing to briefly look at is how people achieved the role of master mason. From the Wikipedia page about stonemasonry:

Medieval stonemasons’ skills were in high demand, and members of the guild, gave rise to three classes of stonemasons: apprentices, journeymen, and master masons. Apprentices were indentured to their masters as the price for their training, journeymen had a higher level of skill and could go on journeys to assist their masters, and master masons were considered freemen who could travel as they wished to work on the projects of the patrons.

This mirrors my own personal experience of moving into a software architecture role. It was an evolutionary process. Like many people, I started my career writing code under the supervision of somebody else and gradually, as I gained more experience, started to take on larger and larger design tasks. Unlike the medieval building industry though, the software development industry lacks an explicit way for people to progress from being junior developers through to software architects. We don’t have a common apprenticeship model.

Architects need to work with the teams

Herein lies the big problem for many organisations though - there aren’t enough architects to go around. Although the master masons may not have had much time to work with stone themselves, they did work with the teams. I often get asked questions from software architects who, as a part of their role, are expected to provide assistance to a number of different teams. Clearly it’s unrealistic to contribute to the hands-on elements of the software delivery if you are working with a number of different teams. You’re just not going to have the time to write any code.

Performing a software architecture role across a number of teams is not an effective way to work though. Typically this situation occurs when there is a centralised group of architects (e.g. in an “Enterprise Architecture Group”) who are treated as shared resources. From what I’ve read, the master masons were dedicated to a single building site at any one point in time and this is exactly the approach that we should adopt within our software development teams. If you think that this isn’t possible, just take a look at how the medieval building industry solved the problem:

A mason would have an apprentice working for him. When the mason moved on to a new job, the apprentice would move with him. When a mason felt that his apprentice had learned enough about the trade, he would be examined at a Mason’s Lodge.

Again, it comes back to the strong apprenticeship model in place and this is exactly why coaching and mentoring should be a part of the modern software architecture role. We need to grow the software architects of tomorrow and every software development team needs their own master builder.

11 From developer to architect

The line between software development and software architecture is a tricky one. Some people will tell you that it doesn’t exist and that architecture is simply an extension of the design process undertaken by developers. Others will make out it’s a massive gaping chasm that can only be crossed by lofty developers who believe you must always abstract your abstractions and not get bogged down by those pesky implementation details. As always, there’s a pragmatic balance somewhere in the middle, but it does raise the interesting question of how you move from one to the other.

Some of the key factors that are often used to differentiate software architecture from software design include an increase in scale, an increase in the level of abstraction and an increase in the significance of making the right design decisions. Software architecture is all about having a holistic view and seeing the “big picture” to understand how the software system works as a whole.

While this may help to differentiate software design and architecture, it doesn’t necessarily help in understanding how a software developer moves into a software architecture role. Furthermore, it also doesn’t help in identifying who will make a good software architect and how you go about finding them if you’re hiring.

Experience is a good gauge but you need to look deeper

There are a number of different qualities that you need to look for in a software architect and their past experience is often a good gauge of their ability to undertake the role. Since the role of a software architect is varied though, you need to look deeper to understand the level of involvement, influence, leadership and responsibility that has been demonstrated across a number of different areas. In conjunction with my definition of the software architecture role, each of the parts can and should be evaluated independently. After all, the software design process seems fairly straightforward. All you have to do is figure out what the requirements are and design a system that satisfies them. But in reality it’s not that simple and the software architecture role undertaken by somebody can vary wildly. For example:

1. Architectural drivers: capturing and challenging a set of complex non-functional requirements versus simply assuming their existence.

2. Designing software: designing a software system from scratch versus extending an existing one.

3. Technical risks: proving that your architecture will work versus hoping for the best.

4. Architecture evolution: being continually engaged and evolving your architecture versus choosing to hand it off to an “implementation team”.

5. Coding: being involved in the hands-on elements of the delivery versus watching from the sidelines.

6. Quality assurance: assuring quality and selecting standards versus being reviewed against them or doing nothing.

Much of this comes down to the difference between taking responsibility for a solution versus assuming that it’s not your problem.

The line is blurred

Regardless of whether you view the line between software development and architecture as a mythical one or a gaping chasm, people’s level of experience across the software architecture role varies considerably. Furthermore, the line between software development and software architecture is blurred somewhat. Most developers don’t wake up on a Monday morning and declare themselves to be a software architect. I certainly didn’t and my route into software architecture was very much an evolutionary process. Having said that, there’s a high probability that many software developers are already undertaking parts of the software architecture role, irrespective of their job title.

Crossing the line is our responsibility

There’s a big difference between contributing to the architecture of a software system and being responsible for it; with a continuum of skills, knowledge and experience needed across the different areas that make up the software architecture role. Crossing the line between software developer and software architect is up to us. As individuals we need to understand the level of our own experience and where we need to focus our efforts to increase it.

12 Broadening the T

Despite what you may hear some people say, software architecture is not a “post-technical” or “non-technical” career. Drawing a handful of boxes, lines and clouds on a whiteboard and handing that off as a “software design” is not what the role is all about.

Deep technology skills

“T” is for technology, and this is exactly what good software architects need to know about. As software developers, we tend to have knowledge about things like programming language syntax, APIs, frameworks, design patterns, automated unit testing and all of the other low-level technical stuff that we use on a daily basis. And this is the same basic knowledge that software architects need too. Why? Because people in the software architecture role need to understand technology, basically so that they are able to honestly answer the following types of questions:

· Is this solution going to work?

· Is that how we are going to build it?

However, given the learning curve associated with being productive in different programming languages, it’s common for software professionals to only know one or two technologies really well. Eventually these people get known for being a “Java developer” or an “Oracle developer”, for example. I’ve been there and done that myself. I’ve also seen it happen in many other organisations. If you’ve ever wondered why there are so many religious battles related to programming languages, you need look no further for how many of these start.

Although we may strive to be open-minded, it’s easy to get siloed into a single technology stack. While there’s nothing particularly wrong with this, you have to be careful that you do keep an open mind. As the saying goes, “if all you have is a hammer, everything will look like a nail”. Gaining experience is an essential part of the learning journey, but that same experience shouldn’t constrain you. As an example, you don’t need a relational database for every software system, but often this is the first thing that gets drawn when a team is sketching out a candidate software architecture.

Breadth of knowledge

And that brings me onto why it’s important for software architects to have a breadth of technology knowledge too. Sure, they may be specialists in Java or Oracle, but the role demands more. For example, the people in the software architecture role should be able to answer the following types of questions too:

· Is the technology that we’ve chosen the most appropriate given the other options available?

· What are the other options for the design and build of this system?

· Is there a common architectural pattern that we should be using?

· Do we understand the trade-offs of the decisions that we’re making?

· Have we catered for the desired quality attributes?

· How can we prove that this architecture will work?

Software architects are generalising specialists

Most of the best software architects I know have come from a software development background. This doesn’t mean that they are the best coders on a team, but they are able to switch between the low-level details and the big picture. They also have a deep technical specialism backed-up with a breadth of knowledge that they’ve gained from years of experience in building software. But they can’t (and don’t) always know everything. Plus it’s rare to find a software system that only uses a single technology stack. Some examples of systems with heterogeneous technology stacks that I’ve seen during my career include:

· A Microsoft .NET desktop client running against a number of Oracle databases.

· A Microsoft ASP.NET website pulling data from an Oracle database via a collection of Java EE web services.

· iOS and Android mobile apps pulling data from RESTful services written in Java.

· A micro-service style architecture, where various services were built using Microsoft .NET or Ruby.

· A Microsoft ASP.NET website pulling data from a Microsoft Dynamics CRM system.

· A Microsoft SharePoint website pulling data from a collection of databases via Microsoft .NET/Windows Communication Foundation services.

· A Java EE web application integrating with SAP.

· etc

Although general design knowledge, techniques, patterns and approaches often apply to a number of different technologies, not understanding how to apply them successfully at a low-level of detail can cause issues. Does this mean that the software architect should be an expert in all of the technologies that are in use on any give software system? No. Instead collaboration is key. Find somebody that does understand the things you don’t and work with them closely. Nothing says that the software architecture role can’t be shared, and often appreciating the gaps in your own knowledge is the first step to creating a more collaborative working environment. Pair programming has benefits, so why not pair architecting?

Software architecture is a technical career

Technology knowledge underpins the software architecture role, requiring a combination of deep technology skills coupled with broader knowledge. If the people designing the software and drawing the architecture diagrams can’t answer the question of whether the architecture will work, they are probably the wrong people to be doing that job. Software architecture is most definitely a technical career but that’s not the end of the story. Good soft skills are vital too.

13 Soft skills

The majority of the discussion about the software architecture role in this book relates back to having technical depth and breadth. But this is really only half the story. Since we’re essentially talking about a leadership role, “soft skills” or “people skills” are vitally important too.

· Leadership: In it’s simplest form, leadership is the ability to create a shared vision and to then take people on a journey to satisfy the common goal.

· Communication: You can have the best ideas and vision in the world, but you’re dead in the water if you’re unable to effectively communicate this to others. This means people inside and outside of the software development team, using the language and level of detail that is appropriate to the audience.

· Influencing: This is a key leadership skill and can be done a number of ways, from overt persuasion through to Neuro-Linguistic Programming or Jedi mind tricks. Influencing people can also be done through compromise and negotiation. Individuals may have their own ideas and agendas, which you need to deal with while keeping everybody “on-side” and motivated to get the result that you need. Good influencing requires good listening and exploring skills too.

· Confidence: Confidence is important, underpinning effective leadership, influence and communication. Confidence doesn’t mean arrogance though.

· Collaboration: The software architecture role shouldn’t be done in isolation, and collaboration (working with others) to come up with a better solution is a skill that is worth practicing. This means listening, being open-minded and responsive to feedback.

· Coaching: Not everybody will have experience in what you’re trying to do and you’ll need to coach people on their role, technologies, etc.

· Mentoring: Mentoring is about facilitating somebody’s learning rather than telling them how to do something. As a leader you may be asked to mentor others on the team.

· Motivation: This is about keeping the team happy, up-beat and positive. The team also needs to feel motivated to follow any vision that you create as a software architect. You will face an uphill battle without the rest of the team’s buy-in.

· Facilitation: There will often be times where you need to step back and facilitate discussions, particularly where there is conflict within the team. This requires exploration, objectivity and helping the team come up with a solution to build consensus.

· Political: There are always politics at play in every organisation. My mantra is to steer clear of getting involved as far as possible, but you should at least understand what’s going on around you so that you can make more informed decisions.

· Responsibility: You can’t necessarily blame the rest of the software development team for failure and it’s important that you have a sense of responsibility. It’s your problem if your software architecture doesn’t satisfy the business goals, deliver the non-functional requirements or the technical quality is poor.

· Delegation: Delegation is an important part of any leadership role and there’s a fine line between delegating everything and doing everything yourself. You should learn to delegate where appropriate but remember that it’s not the responsibility you’re delegating.

Stay positive

As a software architect, which is a leadership role however you look at it, you’re likely to be an important role model for a number of people on the development team. The reason for this? Many of the team are probably aspiring software architects themselves. Although this is a flattering situation to be in, there are some major downsides if you take your eye off the ball.

Whether you’ve recognised it or not, you’re in a very influential position and the eyes of the development team are likely to be watching your every move. For this reason alone, you have the power to change the whole dynamic of the team, whether you like it or not. If you’re motivated, the development team is likely to be motivated. If you’re enthusiastic about the work, the rest of the team is likely to be enthusiastic about the work. If you’re optimistic that everything will pan out, the development team will be too.

You can almost think of this as a self-supporting loop of positive energy where your enthusiasm drives the team, and their enthusiasm drives you. This is all fantastic but it’s not hard to see the damage that can be caused by a slip-up on your behalf. Any degree of lethargy, apathy or pessimism will rub onto your team quicker than you can say “but we’ll be okay” and you’ll start spiralling towards a vicious circle of negativity.

We don’t often talk about the softer side of being a software architect but the soft skills are sometimes more important than being technically strong. A happy team is a team that delivers. As a leader, it’s your responsibility to keep the team positive and your role in the overall team dynamics shouldn’t be underplayed.

14 Software development is not a relay sport

Software teams that are smaller and/or agile tend to be staffed with people who are generalising specialists; people that have a core specialism along with more general knowledge and experience. In an ideal world, these cross-discipline team members would work together to run and deliver a software project, undertaking everything from requirements capture and architecture through to coding and deployment. Although many software teams strive to be self-organising, in the real world they tend to be larger, more chaotic and staffed only with specialists. Therefore, these teams typically need, and often do have, somebody in the technical leadership role.

“Solution Architects”

There are a lot of people out there, particularly in larger organisations, calling themselves “solution architects” or “technical architects”, who design software and document their solutions before throwing them over the wall to a separate development team. With the solution “done”, the architect will then move on to do the same somewhere else, often not even taking a cursory glimpse at how the development team is progressing. When you throw “not invented here” syndrome into the mix, there’s often a tendency for that receiving team to not take ownership of the solution and the “architecture” initially created becomes detached from reality.

I’ve met a number of such architects in the past and one particular interview I held epitomises this approach to software development. After the usual “tell me about your role and recent projects” conversation, it became clear to me that this particular architect (who worked for one of the large “blue chip” consulting firms) would create and document a software architecture for a project before moving on elsewhere to repeat the process. After telling me that he had little or no involvement in the project after he handed over the “solution”, I asked him how he knew that his software architecture would work. Puzzled by this question, he eventually made the statement that this was “an implementation detail”. He confidently viewed his software architecture as correct and it was the development team’s problem if they couldn’t get it to work. In my view, this was an outrageous thing to say and it made him look like an ass during the interview. His approach was also AaaS … “Architecture as a Service”!

Somebody needs to own the big picture

The software architecture role is a generalising specialist role, and different to your typical software developer. It’s certainly about steering the ship at the start of a software project, which includes things like managing the non-functional requirements and putting together a software design that is sensitive to the context and environmental factors. But it’s also about continuously steering the ship because your chosen path might need some adjustment en-route. After all, agile approaches have shown us that we don’t necessarily have (and need) all of the information up front.

A successful software project requires the initial vision to be created, communicated and potentially evolved throughout the entirety of the software development life cycle. For this reason alone, it doesn’t make sense for one person to create that vision and for another team to (try to) deliver it. When this does happen, the set of initial design artefacts is essentially a baton that gets passed between the architect and the development team. This is inefficient, ineffective and exchange of a document means that much of the decision making context associated with creating the vision is also lost. Let’s hope that the development team never needs to ask any questions about the design or its intent!

This problem goes away with truly self-organising teams, but most teams haven’t yet reached this level of maturity. Somebody needs to take ownership of the big picture throughout the delivery and they also need to take responsibility for ensuring that the software is delivered successfully. Software development is not a relay sport and successful delivery is not an “implementation detail”.

15 Software architecture introduces control?

Software architecture introduces structure and vision into software projects but is it also about introducing control? And if so, is control a good thing or a bad thing?

Provide guidance, strive for consistency

Many of the practices associated with software architecture are about the introduction of guidance and consistency into software projects. If you’ve ever seen software systems where a common problem or cross-cutting concern has been implemented in a number of different ways, then you’ll appreciate why this is important. A couple of examples spring to mind; I’ve seen a software system with multiple object-relational mapping (ORM) frameworks in a single codebase and another where components across the stack were configured in a number of different ways, ranging from the use of XML files on disk through to tables in a database. Deployment and maintenance of both systems was challenging to say the least.

Guidance and consistency can only be realised by introducing a degree of control and restraint, for example, to stop team members going off on tangents. You can’t have people writing database access code in your web pages if you’ve specifically designed a distributed software system in order to satisfy some of your key non-functional requirements. Control can also be about simply ensuring a clear and consistent structure for your codebase; appropriately organising your code into packages, namespaces, components, layers, etc.

How much control do you need?

The real question to be answered here relates to the amount of control that needs to be introduced. At one end of the scale you have the dictatorial approach where nobody can make a decision for themselves versus the other end of the scale where nobody is getting any guidance whatsoever. I’ve seen both in software projects and I’ve taken over chaotic projects where everybody on the team was basically left to their own devices. The resulting codebase was, unsurprisingly, a mess. Introducing control on this sort of project is really hard work but it needs to be done if the team is to have any chance of delivering a coherent piece of software that satisfies the original drivers.

Control varies with culture

I’ve also noticed that different countries and cultures place different values on control. Some (e.g. the UK) value control and the restraint that it brings whereas others (e.g. Scandinavia) value empowerment and motivation. As an example of what this means in the real world, it’s the difference between having full control over all of the technologies used on a software project (from the programming language right down to the choice of logging library) through to being happy for anybody in the team make those decisions.

A lever, not a button

I like to think of control as being a control lever rather than something binary that is either on or off. At one extreme you have the full-throttle dictatorial approach and at the other you have something much more lightweight. You also have a range of control in between the extremes allowing you to introduce as much control as is necessary. So how much control do you introduce? It’s a consulting style answer admittedly, but without knowing your context, it depends on a number of things:

· Are the team experienced?

· Has the team worked together before?

· How large is the team?

· How large is the project?

· Are the project requirements complex?

· Are there complex non-functional requirements or constraints that need to be taken into account?

· What sort of discussions are happening on a daily basis?

· Does the team or the resulting codebase seem chaotic already?

· etc

My advice would be to start with some control and listen to the feedback in order to fine-tune it as you progress. If the team are asking lots of “why?” and “how?” questions, then perhaps more guidance is needed. If it feels like the team are fighting against you all of the time, perhaps you’ve pushed that lever too far. There’s no universally correct answer, but some control is a good thing and it’s therefore worth spending a few minutes looking at how much is right for your own team.

16 Mind the gap

Our industry has a love-hate relationship with the software architecture role, with many organisations dismissing it because of their negative experience of architects who dictate from “ivory towers” and aren’t engaged with the actual task of building working software. This reputation is damaging the IT industry and inhibiting project success. Things need to change.

Developers focus on the low-level detail

If you’re working on a software development project at the moment, take a moment to look around at the rest of the team. How is the team structured? Does everybody have a well defined role and responsibilities? Who’s looking after the big picture; things like performance, scalability, availability, security and so on?

We all dream about working on a team where everybody is equally highly experienced and is able to think about the software at all levels, from the code right through to the architectural issues. Unfortunately the real world just isn’t like that. Most of the teams that I’ve worked with are made up of people with different levels of experience, some of who are new to IT and others who have “been around the block a few times”. As software developers, the code is our main focus but what happens if you have a team that only focusses on this low-level detail? Imagine a codebase where all of the latest programming language features are used, the code is nicely decoupled and testing is completely automated. The codebase can be structured and formatted to perfection but that’s no use if the system has scalability issues when deployed into a live environment.

Architects dictate from their ivory towers

The software architecture role is different to a developer role. Some people view it as a step up from being a developer, and some view it as a step sideways. However you view it, the architecture role is about looking after “the big picture”. Many teams do understand the importance of software architecture but will bring in somebody with the prestigious title of “Architect” only to stick them on a pedestal above the rest of the team. If anything, this instantly isolates the architect by creating an exaggerated gap between them and the development team they are supposed to be working with.

Reducing the gap

Unfortunately, many software teams have this unnecessary gap between the development team and the architect, particularly if the architect is seen to be dictating and laying down commandments for the team to follow. This leads to several problems.

· The development team doesn’t respect the architect, regardless of whether the architect’s decisions are right or not.

· The development team becomes demotivated.

· Important decisions fall between the gap because responsibilities aren’t well defined.

· The project eventually suffers because nobody is looking after the big picture.

Fortunately, there are some simple ways to address this problem, from both sides. Software development is a team activity after all.

If you’re a software architect:

· Be inclusive and collaborate: Get the development team involved in the software architecture process to help them understand the big picture and buy-in to the decisions you are making. This can be helped by ensuring that everybody understands the rationale and intent behind the decisions.

· Get hands-on: If possible, get involved with some of the day-to-day development activities on the project to improve your understanding of how the architecture is being delivered. Depending on your role and team size, this might not be possible, so look at other ways of retaining some low-level understanding of what’s going on such as assisting with design and code reviews. Having an understanding of how the software works at a low-level will give you a better insight into how the development team are feeling about the architecture (e.g. whether they are ignoring it!) and it will provide you with valuable information that you can use to better shape/influence your architecture. If the developers are experiencing pain, you need to feel it too.

If you’re a software developer:

· Understand the big picture: Taking some time out to understand the big picture will help you understand the context in which the architectural decisions are being made and enhance your understanding of the system as a whole.

· Challenge architectural decisions: With an understanding of the big picture, you now have the opportunity to challenge the architectural decisions being made. Architecture should be a collaborative process and not dictated by people that aren’t engaged in the project day-to-day. If you see something that you don’t understand or don’t like, challenge it.

· Ask to be involved: Many projects have an architect who is responsible for the architecture and it’s this person who usually undertakes all of the “architecture work”. If you’re a developer and you want to get more involved, just ask. You might be doing the architect a favour!

A collaborative approach to software architecture

What I’ve talked about here is easily applicable to small/medium project teams, but things do start to get complicated with larger teams. By implication, a larger team means a bigger project, and a bigger project means a bigger “big picture”. Whatever the size of project though, ensuring that the big picture isn’t neglected is crucial for success and this typically falls squarely on the architect’s shoulders. However, most software teams can benefit from reducing the unnecessary gap between developers and architects, with the gap itself being reducible from both sides. Developers can increase their architectural awareness, while architects can improve their collaboration with the rest of the team. Make sure that you mind the gap and others may follow.

17 Where are the software architects of tomorrow?

Agile and software craftsmanship are two great examples of how we’re striving to improve and push the software industry forward. We spend a lot of time talking about writing code, automated testing, automated deployment, tools, technologies and all of the associated processes. And that makes a lot of sense because the end-goal here is delivering benefit to people through software, and working software is key. But we shouldn’t forget that there are some other aspects of the software development process that few people genuinely have experience with. Think about how youwould answer the following questions.

1. When did you last code?

o Earlier today, I’m a software developer so it’s part of the job.

2. When did you last refactor?

o I’m always looking to make my code the best I can, and that includes refactoring if necessary. Extract method, rename, pull up, push down … I know all that stuff.

3. When did you last test your code?

o We test continuously by writing automated tests either before, during or after we write any production code. We use a mix of unit, integration and acceptance testing.

4. When did you last design something?

o I do it all the time, it’s a part of my job as a software developer. I need to think about how something will work before coding it, whether that’s by sketching out a diagram or using TDD.

5. When did you last design a software system from scratch? I mean, take a set of vague requirements and genuinely create something from nothing?

o Well, there’s not much opportunity on my current project, but I have an open source project that I work on in my spare time. It’s only for my own use though.

6. When did you last design a software system from scratch that would be implemented by a team of people.

o Umm, that’s not something I get to do.

Let’s face it, most software developers don’t get to take a blank sheet of paper and design software from scratch all that frequently, regardless of whether that design is up front or evolutionary and whether it’s a solo or collaborative exercise.

Coaching, mentoring and apprenticeships

Coaching and mentoring is an overlooked activity on most software development projects, with many team members not getting the support that they need. While technical leadership is about guiding the project as a whole, there are times when individuals need assistance. In addition to this, coaching and mentoring provides a way to enhance people’s skills and to help them improve their own careers. Sometimes this assistance is of a technical nature, and sometimes it’s more about the softer skills. From a technical perspective though, why shouldn’t the people undertaking the software architecture role help out with the coaching and mentoring? Most architects that I know have got to where they are because they have a great deal of experience in one or more technical areas. If this is the case, why shouldn’t those architects share some of their experience to help others out? An apprenticeship model is exactly how the master builders of times past kept their craft alive.

We’re losing our technical mentors

The sad thing about our industry is that many developers are being forced into non-technical management positions in order to progress their careers up the corporate ladder. Ironically, it’s often the best and most senior technical people who are forced away, robbing software teams of their most valued technical leads, architects and mentors. Filling this gap tomorrow are the developers of today.

Software teams need downtime

Many teams have already lost their most senior technical people, adding more work to the remainder of the team who are already struggling to balance all of the usual project constraints along with the pressures introduced by whatever is currently fashionable in the IT industry … agile, craftsmanship, cloud, rich Internet UIs, functional programming, etc. Many teams appreciate that they should be striving for improvement, but lack the time or the incentive to do it.

To improve, software teams need some time away from the daily grind to reflect, but they also need to retain a focus on all aspects of the software development process. It’s really easy to get caught up in the hype of the industry, but it’s worth asking whether this is more important than ensuring you have a good pragmatic grounding.

Experience of coding is easy to pick up and there are plenty of ways to practice this skill. Designing something from scratch that will be implemented by a team isn’t something that you find many teams teaching or practicing though. With many technical mentors disappearing thanks to the typical corporate career ladder, where do developers gain this experience? Where are the software architects of tomorrow going to come from?

18 Everybody is an architect, except when they’re not

Many software teams strive to be agile and self-organising yet it’s not immediately obvious how the software architecture role fits into this description of modern software development teams.

Everybody is an architect

In “Extreme Programming Annealed”, Glenn Vanderburg discusses the level at which the Extreme Programming practices work, where he highlights the link between architecture and collective ownership. When we talk about collective ownership, we’re usually referring to collectively owning the code so that anybody on the team is empowered to make changes. In order for this to work, there’s an implication that everybody on the team has at least some basic understanding of the “big picture”. Think about your current project; could you jump into any part of the codebase and understand what was going on?

Imagine if you did have a team of experienced software developers that were all able to switch in and out of the big picture. A team of genuinely hands-on architects. That team would be amazing and all of the elements you usually associate with software architecture (non-functional requirements, constraints, etc) would all get dealt with and nothing would slip through the gaps. From a technical perspective, this is a self-organising team.

Except when they’re not

My big problem with the self-organising team idea is that we talk about it a lot in industry, yet I rarely see it in practice. This could be a side-effect of working in a consulting environment because my team always changes from project to project plus I don’t tend to spend more than a few months with any particular customer. Or, as I suspect, true self-organising teams are very few and far between. Striving to be self-organising is admirable but, for many software teams, this is like running before you can walk.

In “Notes to a software team leader”, Roy Osherove describes his concept of “Elastic Leadership” where the leadership style needs to vary in relation to the maturity of the team. Roy categorises the maturity of teams using a simple model, with each level requiring a different style of leadership.

1. Survival model (chaos): requires a more direct, command and control leadership style.

2. Learning: requires a coaching leadership style.

3. Self-organising: requires facilitation to ensure the balance remains intact.

As I said, a team where everybody is an experienced software developer and architect would be amazing but this isn’t something I’ve seen happen. Most projects don’t have anybody on the team with experience of the “big picture” stuff and this is evidenced by codebases that don’t make sense (big balls of mud), designs that are unclear, systems that are slow and so on. This type of situation is the one I see the most and, from a technical perspective, I recommend that one person on the team takes responsibility for the software architecture role.

Roy uses the ScrumMaster role as an example. Teams in the initial stages of their maturity will benefit from a single person undertaking the ScrumMaster role to help drive them in the right direction. Self-organising teams, on the other hand, don’t need to be told what to do. The clue is in the name; they are self-organising by definition and can take the role upon themselves. I would say that the same is true of the software architecture, and therefore technical leadership, role.

Does agile need architecture?

Unfortunately, many teams view the “big picture” technical skills as an unnecessary evil rather than an essential complement, probably because they’ve been burnt by big design up front in the past. Some are also so focussed on the desire to be “agile” that other aspects of the software development process get neglected. Chaos rather than self-organisation ensues yet such teams challenge the need for a more direct leadership approach. After all, they’re striving to be agile and having a single point of responsibility for the technical aspects of the project conflicts with their view of what an agile team should look like. This conflict tends to cause people to think that agile and architecture are opposing forces - you can have one or the other but not both. It’s not architecture that’s the opposing force though, it’s big design up front.

Agile software projects still need architecture because all those tricky concerns around complex non-functional requirements and constraints don’t go away. It’s just the execution of the architecture role that differs.

With collective code ownership, everybody needs to be able to work at the architecture level and so everybody is an architect to some degree. Teams that aren’t at the self-organising stage will struggle if they try to run too fast though. Despite people’s aspirations to be agile, collective code ownership and a distribution of the architecture role are likely to hinder chaotic teams rather than help them. Chaotic teams need a more direct leadership approach and they will benefit from a single point of responsibility for the technical aspects of the software project. In other words, they will benefit from a single person looking after the software architecture role. Ideally this person will coach others so that they too can help with this role.

One software architect or many? Single point of responsibility or shared amongst the team? Agile or not, the software architecture role exists. Only the context will tell you the right answer.

19 Software architecture as a consultant

Most of my career has been spent working for IT consulting companies, where I’ve either built software systems for our customers under an outsourcing arrangement or with our customers as a part of a mixed customer-supplier team (this is often called “body-shopping”). Although undertaking the software architecture role within a consulting context is fundamentally the same as undertaking the role in any other context, there are some potential gotchas to be aware of.

Domain knowledge

A good working knowledge of the business domain is essential. If you’re working within the finance industry, you should know something about how your particular part of the finance industry works (e.g. funds management, investment banking, retail banking, etc). Most business domains are more complex than they really should be and even seemingly simple domains can surprise you. I remember the first time that I saw the ferry and hotel domains, which surprisingly aren’t simply about booking seats on boats or rooms in hotels. Having an appreciation of the business domain helps you to better understand the goals and create successful software products.

And this raises an interesting question. A deep knowledge of the business domain only comes from working within that domain for an extended period of time but most consultants move between different customers, teams and business domains on a regular basis. Is it therefore fair to expect consultants to possess deep domain knowledge?

There are a couple of approaches that I’ve seen people take. The first is to restrict yourself to working within a single business domain as a consultant so that you do gain a deep working knowledge of the business domain. As an example, a number of the IT consulting organisations that I’ve worked for have specialised in the investment banking industry, with consultants moving from bank to bank within that industry. This is certainly an effective way to ensure that consultants do understand the business domain, but it’s not an approach that I particularly like. Some of the consultants who I’ve worked with in the past have actually taken offence when offered a consulting role outside of investment banking. These people usually saw their deep business domain knowledge as a key differentiator or unique selling point when compared to other consultants.

A look at my bookshelf will reveal that my interests lie far more with technology than any business domain. If I wanted to work for a bank, I’d work for a bank rather than a consulting organisation. As a result, I’m happy to regularly switch between business domains and this provides a degree of variety that you can’t necessarily get from working in a single domain. I also find it interesting to see how other industries solve similar problems, and this itself leads to a number of opportunities for the cross-pollination of ideas. The downside, of course, is that my domain knowledge of any particular domain isn’t as deep as somebody who works full-time in that business domain.

To prevent this being an issue, I believe that there’s a skill in being able to understand enough about a new business domain to become proficient quickly. And that’s really my approach. If you’re a undertaking the software architecture role on a consulting basis, you need razor sharp analysis skills to understand the key parts of the business domain without getting trapped in a cycle of analysis paralysis.

Authority

The degree of control that the software architecture role needs to introduce depends on the type of software development team that you work with. Often the team can present another set of challenges though, especially if you’re working as a consultant software architect with a team of your customer’s in-house developers.

If you’re responsible for the software architecture and technical delivery of a software system, you must have the authority to make decisions. If you have the responsibility but not the authority, and are therefore continually seeking permission to make decisions, you could be in for a bumpy ride.

The software architecture role is about technical leadership and part of this means that you need to get the whole team heading in the same direction. Dictating instructions to a team of software developers isn’t likely to be very effective if you’re not their immediate line manager, which is often the case if you’re supplementing a customer team. This is where the soft skills come into play, particularly those related to building relationships, creating trust and motivating the team. I’ve found that being a hands-on, coding architect goes a long way to getting a successful outcome too.

20 Questions

1. What’s the difference between the software architecture and software developer roles?

2. What does the software architecture role entail? Is this definition based upon your current or ideal team? If it’s the latter, what can be done to change your team?

3. Why is it important for anybody undertaking the software architecture role to understand the technologies that they are using? Would you hire a software architect who didn’t understand technology?

4. If you’re the software architect on your project, how much coding are you doing? Is this too much or too little?

5. If, as a software architect, you’re unable to code, how else can you stay engaged in the low-level aspects of the project. And how else can you keep your skills up to date?

6. Why is having a breadth and depth of technical knowledge as important?

7. Do you think you have all of the required soft skills to undertake the software architecture role? If not, which would you improve, why and how?

8. Does your current software project have enough guidance and control from a software architecture perspective? Does it have too much?

9. Why is collaboration an important part of the software architecture role? Does your team do enough? If not, why?

10.Is there enough coaching and mentoring happening on your team? Are you providing or receiving it?

11.How does the software architecture role fit into agile projects and self-organising teams?

12.What pitfalls have you fallen into as somebody new to the software architecture role?

13.Is there a well-defined “terms of reference” for the software architecture in your team or organisation? If so, does everybody understand it? If not, is there value in creating one to make an architect’s role and responsibilities explicit?