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 thesoftware architecture rolewithin 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
Software architecture as a consultant 53 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
Thedegree of controlthat 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.
Thesoftware architecture roleis 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 skillscome into play, particularly those related to building relationships, creating trust and motivating the team. I’ve found that being ahands-on, coding architectgoes a long way to getting a successful outcome too.
19. 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?
III Designing software
This part of the book is about the overall process of designing software, specifically looking at the things that you should really think about before coding.