Software Architecture

What is software architecture?

It depends. Everyone in IT asks this question at some point and the answer they get is a mixed bag depending on who tries to answer it. So to deepen the general state of confusion I thought I would add yet another definition.

What IS a Software Architect?

It depends. I think of Software architects as “Master builders”. They may not have the title “Architect” but they are doing most of the following:

• They provide technical leadership.
• They use their influence to guide their organization towards the best outcome.
• They think about the “big picture”.
• They understand the high-level business strategy. (Business acumen and market awareness)
• They consider how it can be put into action, (Ideation and rational thinking)
• They work with others to design a feasible solution to realize the strategy, - taking into account cost, technology, resources, environment etc. (Collaboration, Creativity, Awareness of limitations)
• They can convey the merits/challenges of that solution, in an efficient manner, to widely varied groups with different perspectives (Confidence, Communication, people skills, awareness of audience)
• They have developed a level of trust within their group/area/organization such that people will follow their lead. (Confidence, Leadership, “good to work with”)
• They are comfortable saying “I don’t know” and not feel it is a weakness. (Confidence)
• They LOVE solving problems, working with others and have a track record of doing so effectively (Internal motivation and competency)

Now when I say “Business Acumen” for example, I don’t mean that the architect has an MBA, but they must have a good awareness of how their company operates and what influences its success. Similarly when I mention Creativity, I don’t mean they are artists or anything like that but they have some capacity to create something new and enjoy doing so.

OK, but what does an Architect DO?

It depends. At a really high level they focus on how the theoretical practices of software engineering can be practically applied.

• They are familiar with the theory, but theory for theory sake should be kept to research papers.
• They use their experience to decide what is important or architecturally significant in each situation.
• They act as a regulator and mediator between the Product Owners, Development teams and the longer term goals of the organization. Providing guidance or firm direction as needed.
• They understand how their prior experience (or lack thereof) can bias the solution and seek to overcome this with collaboration and review with experts.
• They take guidance from industry best practices and are constantly increasing their knowledge.
• While they may not be involved in the coding they must remain involved in the daily development, testing, deployment, tools and processes used by teams they work with.
  • Time invested periodically to assist directly with the development work can help retain those skills and perspective.
  • They must retain the trust of teams who they are seeking to lead, without that trust they will have reduced influence.

Do you NEED an Architect?

It depends. There are TONS of applications being built where an architect is not involved and is not required. Those applications still have an architecture (even if it is accidental or unplanned) of some kind. The trouble starts when things start to scale up, either in volume (business, users, traffic) or in the number of systems involved. If this has not been considered beforehand then things can quickly start sliding toward “big ball of mud” territory and development progress reduces. So the architecture of things, their design absolutely matters and is something we should always consider. The person doing this (senior developer for example) may not always be titled an Architect but they are filling that role.

You say “it depends” a lot, is that a joke?

Well it depends, do you find it funny?