Architects Come in Different Flavors
There are a number of different roles & responsibilities of architects in software development companies and elsewhere. Their positions sound similar and their responsibilities partially overlap as well. But before we look at their differences and values, let’s dig into what architecture is and what architects are.
According to Wikipedia, the origin of the word ‘architect’ is from Greek; specifically, from ‘arkhi’, which means ‘chief’ and ‘tektōn’, which means ‘builder’.
When you need to scale an organization to accommodate double digit growth year over year, “architects” and “architecture” can help – or hurt – that growth process. If we go back to 1992, we already see one of the narrative threads:
[source: What do software architects do? Philippe Kruchten]
A decade later, in 2003, we have Martin Fowler (in “Who needs an architect?”) similarly perplexed, and quoting Ralph Johnson:
“Tell us what is important. Architecture is about the important stuff. Whatever that is.”
How we approach architecture defines what architecture is. Intentions influence behavior. When you run a project with just one agile team on a single product, that team should (but sometimes can’t) own the architecture and there is probably no need for a dedicated architect in this setting. However, things are a bit different at our scale, where we operate with lots of teams in a fast-paced environment. These teams are not working on their own but are contributing to a bigger system that needs to have a clear purpose and evolve in the right direction.
“Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change.” – Grady Booch
Architectural design is system design. System design is contextual design. Architecture reshapes what is outside and shapes what is inside.
The trouble is, there have been lots of efforts to work such things out. From the Zachmann framework to more recent ‘Enterprise Architecture’ definitions such as the Open Group Architecture Framework (TOGAF), plenty has been done but so far there hasn’t been any real agreement on one approach, set of approaches, or set of skills that should define an architect.
Common types of Software Architects
Enterprise architecture (EA) is the practice of analyzing, designing, planning and implementing enterprise analysis to successfully execute on business strategies. It came as a response to the increase of technology in business. EA began in the 1960s, born from “various architectural manuscripts on Business Systems Planning (BSP) by Professor Dewey Walker,” according to the Enterprise Architecture Book of Knowledge (EABOK). There is a growing demand to reduce costs, increase flexibility, and regulate technology environments. EA is regarded as one of the key ways of achieving competitive advantage through information technology.
It can be conceptually divided into different architectural layers, that involve Business Architecture and IT Architecture (Data, Application and Technology).
Note that the Application is about the choice of and relationships between applications in the enterprise’s application portfolio, not about the internal architecture of a single application.
Enterprise Architects are responsible for the company’s business strategy. Their responsibility involves defining business goals, creation and execution of strategic roadmaps, and determining operational gaps and developing methods for improvement.
Enterprise Architects set the direction and establish the approach of an organization’s operations, improve the IT infrastructure, and optimize their business operations. They serve as the “glue” that integrates the project and program strategies across multiple programs and projects.
They are engaged in enterprise activities like analyzing business properties, entities, external environment, etc. They deal with such questions as apps lifecycle, technology, company’s consistency and integrity.
Often EAs are responsible for strategic planning for IT. They tend to answer questions like, “What is the benefit of unifying our ERP solution?” and “What is the implication of adopting a Hybrid Cloud solution?” and “Should we adopt micro-services?”.
Solutions Architects specialize in evaluating business requirements and turning them into solutions, products and/or services. They spend most of their time by coordinating ongoing activities and engaging with all aspects of the initiative, from concept definition to analysis.
Solutions Architects ensure product consistency. They are responsible for the activities related to the requirements capture, concept design, implementation and maintenance. They are engaged in designing high level solutions to a specific set of business requirements, within the framework laid down by the enterprise architecture (team.) This solution may span multiple applications.
Domain Architects are specialists with in-depth knowledge within a particular domain, a set of skills required for a ‘niche’ area of knowledge:
Domain Architects use hands-on approaches to provide technical leadership within the project lifecycle. Usually, they are named in accordance to the technology they are qualified in, such us: ‘Software’, ‘Security’, ‘Front-end’, ‘Cloud’, ‘Infrastructure’, etc. They are responsible for design patterns, standards, and strategies within the domain.
According to the Enterprise Architecture, Software Architects are Technology Domain Architects specialized for software development.
Software Architects work alongside other engineering teams to ensure all solutions are based on solid foundation, right and proven technology and good design principles.
In addition, the Software Architect supports the development teams to ensure that non-functional requirements such as performance, availability, maintainability, reliability and security are being addressed. They maintain an open communication channel with the others, by spreading knowledge involving best practices, design patterns, technologies, identified pitfalls and on-going projects.
They participate on workshops and brainstorming sessions with the rest of the architecture team and other parties. Software Architects will be regularly liaising with Product and Business at various stages of a project to provide high level estimations, participate in discussions, do feasibility assessments and address strategic concerns.
Software Architects are the guardians – and not the owners – of program/solution-level technical and exploration work in enablers and, as such, guide teams’ progress on their execution.
They support the continuous flow of value in an agile organization by making sure:
- The architecture evolves over time while supporting needs of current users
- There are no overhead and delays associated with phase-gate and BDUF methods
- Emergent design and intentionality are balanced
- The system always runs
- The system supports the full value stream
Software Architects drive technical innovation and ensure that the architecture is supporting growth, stability and availability initiatives.
In my definition, being an architect is not an individual contributor role, it’s a service role. They succeed by helping other people succeed on their own projects.
As a summary: “All these flavors and you choose to be salty!”