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.
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 @ bizmonger.net