BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Articles Software Architecture: It Might Not Be What You Think It Is

Software Architecture: It Might Not Be What You Think It Is

Bookmarks

Key Takeaways

  • Software architecture needs to be wrested from committees of people disconnected from developing, and to put it in the hands of the people who can actually make it real and executable, the developers. Only then will we achieve the resilience and sustainability that we need from today’s applications 
  • Software architecture is about capturing decisions, not describing structure
  • Architecting is a skill that agile teams embody, which means that Architect should not be a role
  • Architecting means continuously exploring new approaches and different alternatives to best meet quality attributes
  • The key activity of architecting is forming hypotheses about how the system will meet quality attribute goals, and then using empiricism to test whether the system meets them, and then repeating this loop until the system meets its quality goals

Software architecture has a contentious reputation in the agile community. In the experiences of many, it is the cause of valueless meetings and irrelevant documentation that is aptly summarized by the expression “the map is not the territory.” And yet, applications with poor architecture can quickly become like vehicles abandoned by the roadside, broken and unrepairable. So is there a useful middle ground between these poles of pointlessness?

Part of the problem is that architecture is an inapt metaphor for the result of the work of architecting software systems. Inspired by the work of building architects, the word conjures images of beautiful designs that hint at utopian futures. But the work of architecting software systems is far more dynamic than the building architecture metaphor supports. Buildings are static, and the work of building architects is done just once. Software, by its nature, is ever-shifting and dynamic; when it stops changing, it starts to die.

To arrive at a better understanding of software architecture, we have to go back to the origins of the word architect: It comes from the ancient Greek word arkitekton, ἀρχι- (arkhi-, “chief”) +‎ τέκτων (téktōn, “builder”). Architecture is created by people building things. That sense has become lost in the work of building architects, many of whom have never poured a foundation, framed a building, or run plumbing or heating pipes. Design and building have become separated. Not so in software, where how something is built influences what is built, and vice versa.

Software architecture is about decisions, not structure

The building analogy has led some software architects to focus too much on structure and behaviors, and not the decisions that produce those structures and behaviors. It’s not that structure and behavior are unimportant, but they are the results of a thought process that is important to preserve if the system is to sustainably evolve over time. Knowing why someone did something is just as important as knowing what they did. What they did should be easy to see in the code, if it is well-organized and commented on, but the why is often lost.

The reason for this is that architectural decisions in software are rarely clear-cut; nearly every architectural decision is a compromise between competing alternatives, and the merit of alternatives is hard to see until you try a few and see how they work. Knowing what was tried and rejected is often more useful than knowing what worked. As an old saying goes, good judgment comes from experience, most of which comes from bad judgment.

This is also one reason why software architects must still be developers; they can’t understand or predict the forces at work in a system without developing and testing something. Software Architect is not some sort of honorarium for people who have retired from active development but still have knowledge the organization finds useful; it has to be more. The act of architecting requires sufficient knowledge of a system to frame useful hypotheses about quality attributes, and the expertise to write code and devise tests (or work closely with team members who can) that can evaluate those hypotheses.

Architecting is a skill; Architect is not a role

In truth, using a title like Software Architect sends the wrong message about the nature of the work. The reality is that lots of software developers do architectural work, they just don’t recognize it as such. Anytime they make decisions about how to handle quality attributes, they are affecting the architecture of the system. Being more aware of how implicit decisions affect the ability of the system to achieve quality goals is the first step in improving the architecture of the system.

So what kind of skills do people need to develop to improve the quality of their architectural work? There are a few:

  • An increased focus on quality attributes, which are the key cross-cutting requirements that good architecture should address. It’s easy for teams to focus on functional requirements, as they tend to be tangible, even visible things the system does for its users. But it’s the quality attributes of a system that shape whether it will remain viable over the long term: things like scalability, performance, security, supportability, and maintainability, to name a few.
  • An ability to conceptualize and address system-wide concerns. Quality attributes are most often determined by forces that affect the whole system, not just one part. While modularized design and separation of concerns are important to building good systems, they also make it harder for team members to have a holistic view of the system.
  • An understanding of the complete lifecycle of a system. This requires having experience not just developing a system, but also testing it, deploying it, running it in production, maintaining it over time, and making substantial modernization to it when it needs to do significantly new things. Understanding the lifecycle of a system and how it responds to change is essential to making good decisions that limit technical debt that, over time, can threaten the viability of a system.
  • An ability to balance concerns and compromise. There is rarely one right answer in architecture work. Architecture often involves making trade-offs between conflicting Quality Attribute Requirements (QARs) and constraints.
  • An ability to learn from experience and synthesize new approaches. This involves the ability to take the results from trying things in a directed way (running experiments) and to generalize that learning in the form of principles that can guide further experiments. Some of these principles take the form of “standards,” which is a somewhat misleading term because standards need to be constantly tested using experiments to determine when they are no longer useful. We’ve seen many developers justifiably frustrated with organizational “standards” that made sense at one time but which now keep teams stuck in the past.
  • An ability to demonstrate leadership. The ability to raise concerns, foster discussion of different perspectives, and facilitate consensus helps a team confront and overcome complex architectural problems. Anyone on a team could do this, and anyone who is architecting must do this. 

Architecting means continuously exploring

Architecting modern software applications is a fundamentally explorative activity. Teams building today’s applications encounter new challenges every day: unprecedented technical challenges as well as providing customers with new ways of solving new and different problems. This continuous exploration means that the architecture can’t be determined up-front, based on past experiences; teams have to find new ways of satisfying quality requirements.

As an example of how exploration is essential to discovering the architecture, consider the following: Assume that you are part of a team working on a software system originally designed to handle structured, tabular data stored in a SQL database. This system now needs to be enhanced to handle unstructured data, including images and videos, and the volumes are expected to significantly increase over what the system currently handles. You consider adding a NoSQL database to your technology stack to handle the new data types, but since your team does not have significant experience with this technology, experimentation is essential to select the right database product and configure it to meet the new data volume requirements. 

As the team works through these technical issues, they form hypotheses about which approaches will best meet their desired QARs, which are assumptions as well and will change over time. They build a part of the solution to test these hypotheses, and they make decisions based on the results. The cumulative result of these decisions about how to meet QARs is the architecture of the system. The team may communicate these decisions in different ways, including using documentation and diagrams, but the docs and diagrams are not the architecture, it’s the decisions, and their why, that matter.

Important information about these decisions includes things like:

  • The cost of reversing a decision, should that become necessary. If you have to replace a service, a DBMS, or even a framework, it would help to know how expensive you think this might be. In some cases, it may mean rewriting the application.
  • Clearly articulating any constraints or assumptions. Understanding the working constraints and assumptions that you’ve made may help the team who has to renovate your work in the future. For example, knowing that you’ve assumed that you will have no more than X concurrent users, and this has caused you to make certain decisions about concurrent threads or processes will help your future colleagues understand where they might need to change something if that constraint is exceeded.
  • How you’ve met specific quality attribute requirements (QAR). For each QAR, you should describe what you’ve done to ensure that it will be met, and not just in theory, but what tests you’ve run to prove it. Link to specific test cases and their associated automated tests, so that when the QARs change you will be able to easily reevaluate the architectural quality of the system.
  • What options you’ve considered as your rationale for decisions. Knowing what things you considered and rejected is often even more useful than knowing what you decided; it shows your thought process and provides insights into constraints you may have been under when you made the decision. If these constraints are removed in the future, knowing why you made certain decisions will help future developers make better decisions.

Figure 1: Relationships between QAR, Decision, and Technical Debt

  • What technical debt you’ve knowingly incurred. Some decisions will, inevitably and unavoidably, create technical debt; for example, the decision to meet reliability goals by using a SQL database has some side effects on technical debt (see Figure 1). The now long-past “Y2K problem” was a conscious decision that developers made at the time that reduced data storage, memory use, and processing time needs by not storing century data as part of standard date representations. The problem was that they didn’t expect the applications to last so long, long after those constraints became irrelevant. Had they communicated their decisions and described the potential impact more precisely, there may not have been such a scramble to respond at the end of the last century.

Conclusion

Software architecture, as a discipline, needs a makeover. Its image suffers from a lot of old ideas about what problems it needs to solve and how it should go about solving those problems. Viewing software architecture as a continuous activity focused on forming hypotheses about how the system will meet quality attributes, and then using empiricism to prove that the system meets them, is the essence of a continuous approach to software architecting. What also needs to change is to wrest software architecture from committees of people disconnected from developing, and to put it in the hands of the people who can actually make it real and executable, the developers. Only then will we achieve the resilience and sustainability that we need from today’s applications.

About the Authors

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Could be a role too...

    by Sam Siddiqi,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Architecture is certainly a skill, but if there is sufficient effort required in matters related to archcitecture, it may well be a distinct role. With respect to metaphor, Sam Newman in his book on Microservices had described an Architect as akin to a city planner...that one resonated with me.

  • Software Architecture is More Than Just Decisions

    by Kelvin Meeks,

    Your message is awaiting moderation. Thank you for participating in the discussion.

  • architect in the role of facilitator or mentor

    by Glenn Engstrand,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Thanks for your article documenting how software architecture has changed in a modern, agile world. Other articles that capture this important trend include Scaling the Practice of Architecture, Conversationally and Establishing an Architecture Council. I suspect that you are emphasizing how architecture should not be a role as a response to the old days of top-down, ivory tower style architecture. I agree with you in that the old school role of architect is not productive in today's world.

    May I humbly suggest that there is still a need for a role of architect that serves a different function? The devs doing architecture on a product focused team may not be all that focused on the big picture. Cross team interoperability and refactoring for platform services that span products are big opportunities to reduce wasteful duplicity or rework. There is logistical value in advising an organization wide technology landscape. It is harder to move engineers from one team to another if each team has completely disparate technology stacks. Someone with a larger scope than a single product could be more helpful with these issues but they should not dictate. Instead those kind of portfolio architects should still advise. It's all about soft leverage.

  • Re: Could be a role too...

    by Eirik Mangseth,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    @Sam Siddiqi

    He (Newman) also derides "non-coding architects" in his book.

  • Re: architect in the role of facilitator or mentor

    by Eirik Mangseth,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Glenn Engstrand, is that why Spotify lets each team decide which tech stack to use focusing on rapid delivery of services instead of standardising the tech stack throughout the company? Perhaps the "common tech stack benefit" is more of a fallacy that anything else? If you have skilled people who understands software engineering concepts and how to apply them across stacks, then surely you don't need an architect (or architects) to mandate a particular stack, do you?

    Also, do platform services really require an architect role? Not so sure about that either.

  • Re: Could be a role too...

    by Sam Siddiqi,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    @Eirik Mangseth,

    Architects should, and IMHO must, keep their coding skills sharp. And I do agree that's where the building Architect analogy falls short...I suppose the "real" architects don't really need any level of competence in the trades their essentially guiding.

    It does not, I feel, negate what I wrote. If there is sufficient work, that is to say if the system is non-trivial enough and the problem domain rich enough, then perhaps a distinct role if not outright team might be merited.

    Your millage will vary based on the kind of system you write, the nature and structure of your organization, the impacts and risks that need to be mitigated (financial, loss of life, etc), and so on.

    All architects should code, but the idea that all architecture could emerge from 'skilled enough' coders is a very shallow take.

  • Re: architect in the role of facilitator or mentor

    by Sam Siddiqi,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    @Glenn Engstrand,

    Agreed, these trade-offs might seem obvious for some, but need serious consideration for others.

    It seems that too many in the field want to copy the F/MAANGs, but when you put into practice what they do with a tight budget, and 20 devs tops...with a large enterprise-y feature set that has thousands of distinct feature points...reality hits quite hard.

    A simple decision to use a particular language may seem trivial to one organization, but a major investment to others.

    Individual development teams, driven by a PO, will be well aware of their functional need, but architectural decisions will more or less come from a global context. An Architect, among other things, will need to derive architecturally significant requirements directly from organizational objectives. They almost never come from the POs. In this sense an Architect is an important stakeholder along side a PO, and for platform like features may double as the PO. Making such decisions at a team level is just architecture by committee.

    Again, I stress, individual organizations will have differing needs.

  • Re: Software Architecture is More Than Just Decisions

    by Pierre Pureur,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    The main point about focusing on decisions is to treat all architectural and design ideas, including quality attribute requirements as unproven assumptions until they are evaluated empirically. As long as architects only deal with "key abstractions" at a purely conceptual level, they are fooling themselves about what they really know. If you can't test it, it's not real.
    Structures and other architecture deliverables result from decisions. If portraying structure communicates the decision most effectively, then convey structure, but structure alone may not convey the rationale for that structure.
    In the "Continuous Architecture In Practice" book, we stated that "decisions are the primary unit of work of architectural activities" (continuousarchitecture.com/2021/06/01/essential...) and I would still choose architectural decisions and their implications if I had to pick one single concern for architectural activities.

  • Re: Could be a role too...

    by Pierre Pureur,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I believe that architecture has become a skill, not a role, and is now a continual flow of decisions that are revisited continuously. Architecture activities have become a team responsibility in the Agile, Cloud, and DevOps era. Making this a "role" implies that one (or perhaps several) IT professionals will end up driving most architectural decisions. In my experience, things work much better when the whole team is responsible for the decisions. When things do not go as planned (and unfortunately it happens), there is no finger pointing and everyone ends up pulling together to find a solution.

  • Re: architect in the role of facilitator or mentor

    by Pierre Pureur,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I honestly don't believe that putting someone in an "architect role" automatically ensures that facilitation or mentoring will happen. Those are critical skills that need to happen in any well-functioning team. and I would expect senior team members to mentor and facilitate regardless of their "role". One of the best ways I know of in order to mentor people is to involve them in the architectural decision-making process, that more often than not involves writing code to settle architectural debates. In addition, one of the skills critical to architectural work is the ability to conceptualize, and to look beyond the scope of a project in order to make a good decision.

  • Re: architect in the role of facilitator or mentor

    by Glenn Engstrand,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Perhaps Greghor Hohpe's take on this would make more sense in his The Architect Elevator — Visiting the upper floors article. Here is an excerpt.

    Traditionally, architects were considered to be those folks who make major design decisions on a project, draw architecture diagrams, and direct developers. Those tasks are in fact better handled by the development team and modern tooling than by a single person. Many modern companies therefore eschew software architect as a separate job title, even though they highly value software architecture. The good news is that many new tasks await architects in large organizations. And they are far more interesting and impactful than drawing class diagrams. However, they require architects to engage at the upper floors of their organization.

  • Re: Could be a role too...

    by Saheem Siddiqi,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    @Pierre Pureur,

    tl;dr; It's a distinct practice, (not just a set of checklist todos), and any practice with sufficient work merits a corresponding job role.

    Architecture can’t just be the decisions. I say this if the decisions are static or continuously evolving. There’s a whole rich practice that produces those decisions, and I think you did a good job in capturing this fact in the article.

    To elaborate on my personal expierence, there is a context that determines what is architecturally significant, and what is not. Who mines that? What are the possible ways to address the requirements? There is then a subsequent trade-off analysis that any diligent practice should consider. What are the trade-offs? What are the criteria we use to evaluate? Who are the important stakeholders that have inputs, and who is the target audience for this analysis? If the proposal requires funding, who is going to make the business case? That’s work.

    Like it or not, once a decision is going to be made, you’re going to have to explain it to key stakeholders. What are the cost implications? How are developers to realize what is proposed? A POC-quality experiment might answer some of the questions, for the developers. Won’t help much with executives that need to know why you’re proposing an increase in operational costs by 100K a year because of a decision by a particular agile team. So you’re going to have to explain the same thing multiple times, in different ways. That’s work.

    Now, a particular design might span multiple teams. Each team will be responsible for the delivery of their part of the solution. How to coordinate? How do such designs get produced? By committee? Now, during the course of development, there will be further trade-offs. Some will be immaterial. Others will negate capabilities promised to stakeholders. What’s the process by which we consider these? Who’s going to keep track, across teams? That’s work.

    I really am scratching the surface, but I’ll stop short there.

    Now, let’s look at the agile teams. They’re paired with a PO that is charged with delivering, continuously, value to the clients. If an agile team is to work on something, it must be backlogged. You can’t monetize architectural work like you can feature work backed by paying clients, possibly sponsoring the specific work item. How does the agile team negotiate time? How do you justify exploratory tasks, or testing a hypothesis which may, more often than not, have a negative result? Has your organization budgeted for this work? How does the agile teams, which ideally work on specific business value streams, handle the context switching and (most importantly) the cognitive load that may result in performing all of what I just mentioned above, plus much more?

    Again, I’m scratching the surface.

    I'm not suggesting that any of the above questions absolutely require an Architect role to address. Ultimately, I’m simply saying that for a myriad of reasons, some organizations look at the concerns above and opt to have a distinct stream of work, and a distinct architecture practice led by the Architect role, because there is a sufficient amount of ‘architecture’ work that must be done, and it’s desirable to track and prioritize it independently than development work. And there are ways to do that without having Architects as ivory tower gurus (e.g. consider Architects as peers to POs), who can definitely contribute (e.g. working POC hand-offs, possibly have architects embedded in agile teams to lead the charge and be prime for enabler tasks) to the agile effort.

    I fully understand the desire to have autonomous, self-sufficient agile teams. I just don’t see Architects as a distinct role as contrary to that goal, unless we force ourselves to adopt a particular caricature of the ivory tower architect…even if we don’t fit the profile ourselves. I also don't see diluting the practice of Architecture as a 'everyone does it' kind of activity as having real value, unless you're blessed with a project/product/organization that just doesn't require that much effort.

    Cheers!

  • Re: Could be a role too...

    by Saheem Siddiqi,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    @Pierre Pureaur, in my previous comment the "not just a set of checklist todos" is a silly statement, and I recognize it's not at all what you and Kurt suggest in the article.

    Cheers!

  • Re: architect in the role of facilitator or mentor

    by John Broderick,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I really like this article and it's great to see so much discussion about it in the comments.

    On "refactoring for platform services that span products are big opportunities to reduce wasteful duplicity or rework", I've seen this firsthand.

    Product team A built their solution and some time after product team b built their solution. Both teams focused on their product alone, so neither knew that there was a common sub domain between the products. There was no-one responsible for the big picture here, and this resulted in duplicated effort. To make it more difficult, each teams implementation was specific to their own product, so extracting the sub-domain after the fact is a much more costly job.

    Being able to identify this before it happens would be something that falls under the architect umbrella, and it looks like a responsibility that you could call "describing the structure". The thing is, unless that someone is actively doing this in a role, it's unlikely to happen.

  • Architecture Is Certainly Not What You Think It Is

    by Dick Dowdell,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    There is an old saying: "A camel is a horse designed by a committee." Being an architect is a role, and architecture is more than recording decisions. Architecture is mostly about defining component models and how pieces are connected to each other. It is also a discipline built upon years of acquired knowledge and technique. It is an exercise in rational compromise and it is an integral part of software development--- never be trusted to non-developers.

    A foundational Agile principle is that the best architectures, requirements, and designs emerge from self-organizing teams. That means that the knowledge and expertise of the whole team should be utilized. Not that the Web developer should write the Java code or the Java coder should style the Web pages. Effective teams apply the skills of their members to the most appropriate tasks (and listen to the ideas of all their members).

    Many of the problems of agile development come from oversimplifying the complexities of software systems. Many of the practices recommended by the amateurs, who teach things like Scrum without real development experience, are counter-productive.

    medium.com/nerd-for-tech/leading-agile-developm...

  • The Architect by Spiro Kostof

    by Marc Donner,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Some years ago I was given the title of architect in the context of a software engineering role. While I have a PhD in computer science, I had never been accused of being an architect, so I figured I should learn something about the word.

    I read various books recommended to me by colleagues. One that was very helpful is "The Architect" by Spiro Kostof. It is a history of the building architect role going back to Egyptian times. How they were trained, their role in society, what techniques they used, how they worked, and so on.

    One of the important concepts that I learned from this book is the relationship of the architect to three key roles involved in building something: the sponsor, the builder, and the occupant.

    The Sponsor - provides the money to fund the construction.

    The Builder - actually executes the construction of the building.

    The Occupant - will use the building once it is built.

    The key insight is that the architect negotiates a consensus among the three. It is easy to satisfy any pair ... a building that is easy to build and wonderful to occupy but is so expensive that the sponsor balks ... a building that is easy to build and inexpensive to construct but miserable to occupy ... a building that is cheap to build and wonderful to occupy but impossible to construct.

    Without the architect navigating the divergent needs and desires of the three players, there will NOT be a building.

    In software engineering the roles are present, but often confused. In many high-tech organizations the sponsor and the builder are one and there is sometimes no meaningful discussion of choices affecting cost and schedule. In other contexts, typically old-school enterprise software the sponsor and the occupant are one ... lacking serious engineering skills they often present the builder with ill-specified or even unstable requirements, making the builder's life chaotic and challenging.

    A participant whose role is not really discussed in Kostof's writing is one that is very important for software, namely the maintainer.

    Because software systems are rarely delivered complete and in their final form, there is an ongoing role for software engineers adding major new features, reimplementing subsystems and components. Looked at across the life cycle of the software system the investment in maintenance is often an order of magnitude or more larger than the initial system construction.

    To the point of the authors and several commenters, care invested in decisions made in the initial design and construction of the core or kernel will translate to vast savings in maintenance and evolution over subsequent time.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT