Recently I was reviewing requirements for Microsoft Architect Certification and had found description for architect roles. After reading I had a question: do we need this kind of architects in a software team? Can they really help with building successful software?
The summary of architect responsibilities (as per Microsoft):
- Enterprise architects: set the overall vision and framework for the IT environment from a strategic business perspective.
- Solutions architects: design the solution to take advantage of the existing assets, integrate them into the existing environment, follow the enterprise architecture, and solve the business problems of the business owner or unit.
- Infrastructure architects: responsible for creating an architecture that meets the business and service level agreement requirements of the business owners and supports the applications and solutions that are required to operate their day-to-day businesses.
The bottom line is that company hires expensive and canny software architects before start of the project. They talk with the business, come up with solutions and make bright key decisions about architecture. But they don’t program. During the course of the project they ensure that developers don’t spoil this great architecture.
Now business owners can hire not so bright programmers, who should just follow directives and implement this great architecture. There is even correspondence with theories of some management consultants that programmers are just house painters.
Completely irrelevant questions: Can you trust advise of your friend about Paris, if he saw the city only on TV? Can you trust battle plans if battle didn’t begin and your commander knows little about enemy? How many chess moves ahead can you predict with high certainty before start of the game?
I don’t reject a need in architecture, but I don’t agree who, when and how should make architecture decisions in a software project.
Top 10 reasons why you don’t need Software Architect
The Architect (dedicated non-programming technical decision maker and problem solver for business):
- Has outdated programming knowledge and experience, loss of touch with modern development approaches and practices.
- Don’t program and don’t know much about evolving system internals, but makes key technical decisions. Often has completely irrelevant and unreal picture what is happening with the system.
- Tends to complex, premature and generic solutions when the system is still in infancy and nothing is clear. Applies latest modern buzzword technologies as SOA, MDA, SaaS, Software Factories, etc. which look so beautiful in technical magazines, conferences and CV, but cause unnecessary headache for developers.
- Plays role of the middleman introducing complexity in coordination and project responsibilities. Represents software team in interactions with business customers reducing communication value for the rest of the team and impacting idea flow.
- Reduces quality of decisions, which become limited to one perspective; decision making starts lacking diversity, independence and decentralization, which are essential attributes of collective intelligence.
- Creates tension with developers who experience mismatch between grand design and reality. Often continues pushing design decisions until the system becomes overly complex, difficult to change and becomes completely unusable.
- Secures job and justifies high salary – becomes authoritative center for solving business problems without much input from the team.
- Causes loss of sense of ownership, motivation and accountability in developers by detaching them from the key architecture decisions.
- Concentrates project knowledge and the big picture in one head, limiting (and sometimes preventing) complete understanding for others.
- Contributes to creation of specialized IT verticals that hurt relations with the business.
I’m sure that some architects bring strong technical leadership, excellent solutions and overall project success. However, the architect role itself, as described by Microsoft and employed by other companies, doesn’t encourage productive development and effective solutions.
What is effective architecture? Who is effective architect?
Emerging and evolutionary architecture is a core for a successful agile (and not only) software system, emerging from the implementation of business needs, learning from working code, problems and interactions with people, other systems and operational environment.
- Provides stable foundation and integrity for the growing software system, enabling desired system qualities for the business solutions.
- Ensures seamless and consistent integration, well defined interfaces and interaction between subsystems, external systems and operational environment.
- Supports emerging abstractions, key system elements and frameworks for conceptual integrity, efficiency and reuse.
- Guards a system against failure, sensing worrying changes in the project dynamic, system code and business requests.
- Keeps the trinity of system qualities(known from time of Roman empire) in a balance and prevent degradation and entropy:
- Firmitas (Strength) – the system is reliable, secure, has good performance and easy to support
- Utilitas (Utility) – the system is usable, meets business business needs and add business value every day instead of drifting into technology trenches
- Venustas (Beauty) – code and system structure are clean, easy to understand, minimal
- Encourages constant improving of the code design, enhancing system abstractions and structure, removing duplication, defining boundaries and interfaces of the subsystems.
- Keeps solutions as simple as possible, maintains intellectual control over system and avoids over-engineering.
- Most important – grows and coaches other developers to become architects
If your company can afford dedicated non-programming technical person, hire an expert for complex technical areas, a coach to share best practices and experience or a technical supporter to coordinate with different external groups and help to resolve problems and make them all part of the team.
But don’t take technical decisions and concern about architecture from the development team.
The ultimate solution – every developer covers these architect responsibilities. Hire few experienced, motivated and capable developers and start project with them. Developers will constantly evolve the system based on real needs and shape effective architecture. You can trust that system will be healthy, meet business needs and bring success. Often only few important architecture decisions should be made before start of the project – trust them to the developers, who will implement the system.
So, here is the answer regarding who, when and how should make architecture decisions:
Who – every developer timely makes architecture decisions and constantly improves evolving architecture
When – mostly after start of implementation, when system becomes more complex and need design improvements to maintain system qualities, intellectual control and conceptual integrity.
How – preventing degradation and entropy by making design changes and refactoring; learning from the project dynamic, working code and business requests and adjusting a way how the development team works.
Do you still think that software projects need The Architect?
Is Design Dead?, Martin Fowler
Big Ball of Mud, Brian Foote and Joseph Yoder