Software Architects are Irrelevant



Software architect: A computer manager or expert who makes high-level design choices and dictates technical standards, including software coding standards, tools, and platforms.

Based on that definition alone, I render software architects irrelevant for building software solutions. At least they are for business. If a software company is in the business of building frameworks, than I completely embrace an architect’s role. Hence, the .NET framework would be a maintenance nightmare and so would WinRT for that matter if there were no visionary in place to coordinate the architecture, DLL dependencies, namespaces, etc. But what if a business is not building a framework? What if a business is just building a solution for a client? How relevant is an architect’s role? The answer is their role isn’t relevant at all.

Uninformed Decisions

Architects will never know everything about custom software. Each project is unique. As much as they love drawing UML diagrams in an attempt to model the business, few of them are mature enough to realize that software isn’t built to model the business. Software is built to model the rules that the business relies on. I do agree that someone needs to make decisions on the tools or platforms to be used for a project. But why make these expensive decisions upfront? Software is called software for a reason. It’s supposed to be soft and malleable. Thus, we should be able to make modifications with minimal impact to external dependencies. Again, it’s “software” not hardware. With that said, I am almost confident that if you are a Microsoft shop, you will be using a CLR dependent language like C# or F#. Thus, if you are a Java shop, you’ll be using some JVM dependent language such as Java. Now with that said, is an architect really necessary to make a decision about which programming language to use if the software company is already invested in Microsoft? What about the tools for rendering the UI or persisting data? Is an architect really required to make that decision or can an IT Manager or CTO make that call? Thus, when should that decision be made for leveraging a UI tool like HTML5 for presenting data or SQL Server to persist it? Are these decisions really required upfront just to code the business rules? Hence, software is built for business rules and not for software tools. With that said, what if these decisions could be deferred to a later time when more information is available? Then we could make a more informed decision. So why not stub-out the external dependencies (i.e. HTML, SQL Server, etc.) so that we could establish the business logic required to build the software first and then implement the external details later?


In conclusion, Software Architects are irrelevant for building software for business. Although decisions regarding external dependencies are important for a final solution to be delivered, these decisions can be deferred to a later time. WPF, HTML, SQL Server, Oracle, and every other external dependency are nothing but details that our business rules can connect to. Thus, the implementation of these details can be postponed until the business rules are coded and thoroughly tested. It is then that we will have more information to support our decisions regarding the implementation of these details that will ultimately solidify the system.


Scott Nimrod is fascinated with Software Craftsmanship.

He loves responding to feedback and encourages people to share his articles.

He can be reached at scott.nimrod @

4 Replies to “Software Architects are Irrelevant”

  1. I agree that in software development architecture should emerge and continuous refactoring should be done even after the high-level architecture has been defined. But don’t you think at least a high level architecture up to DB Schema and Class level should at least be defined so that everyone involved know the high-level picture of the system?

    1. Hi Joshua. Thank you for your feedback.

      It may sound like crazy-talk but no.
      I don’t care about the database details.
      As a developer I only care about building my module in isolation of everything else.
      After I can prove that my code works via having a unit test per requirement and code analysis (including code coverage), I can then entertain external dependencies (i.e. SQL Server) with more information about the business and streaming requirement updates that the business never considered until a demo was put in front of them early in the development stage instead of later.

      1. If it is a single team building the application I guess it makes sense to not define the DB Schema, but what if you are working with multiple teams? How would each team know how to integrate their work if high-level architecture is not defined. If you are focused with your module in isolation, how do you know that what you’re doing is not redundant with other teams?

    2. Hi Joshua.
      You raise valid points.

      I don’t think teams should be as concerned with integration. Instead, I think they should put more focus on isolating their respective modules from external dependencies. I think architectures are more flexible when modules are completely ignorant about other systems. Hence, a message bus supports this type of flexibility. In this case, external messages come into the module for processing and a module can publish messages for the outside world to respond to.

      In regards to duplication of work, I think Scrum or some type of status reporting system could be useful for identifying duplicated tasks across teams. I can see where an “architect” could have value for that particular scenario. I’m not sure what else though. Is that all an architect is useful for?

      One architect responded to me via email with the following:

      “Your post was pretty interesting and I definitely buy into some of what you said. The role of architect as played out in the previous couple decades, where everything is designed up front, is definitely irrelevant now. However, for complex projects an architect that can work effectively as part of an agile development process is definitely relevant today. Complex projects can involve various technologies, several teams and even multiple companies. Depending on the context, the IT Manager or CTO may not know enough about all the technologies involved to make the important decisions and design the structures that make up the architecture.

      If one developer does everything for a complex project in a startup or small company environment, chances are that developer is spending a lot of time making architectural decisions – I’ve been there. If that project is successful then that developer is probably very talented as a developer and an architect, among other roles. If you have this type of project and you have a multi-talented developer who can also play architect, then you don’t need another architect. In this context, you could say an architect is irrelevant or unnecessary. Most developers aren’t at that top level as developers, much less as architects, hence the need for someone to fill the architect role, either part-time or full-time, depending on the project and the context. At a small company, if you don’t have a top level developer who can also play architect, then the CTO should step into the role of architect as you mentioned or things will not turn out well.

      For development of a complex project at a large, established company, doing so without one or more architects isn’t a consideration. One person can’t possibly understand all the technologies involved, the various areas of the business and all the dependencies between all those business areas. In this type of environment you will likely have several architects involved in a project.

      So, I think that architects are still relevant today, but just in a very different way from the past couple decades.”

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: