Software Creation Mystery - https://softwarecreation.org
«
»

Do We Need Software Architects? 10 Reasons Why Not

Aug 29th, 2007 | Architecture, Design, Process, System, Teams

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):

  1. Has outdated programming knowledge and experience, loss of touch with modern development approaches and practices.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. Secures job and justifies high salary – becomes authoritative center for solving business problems without much input from the team.
  8. Causes loss of sense of ownership, motivation and accountability in developers by detaching them from the key architecture decisions.
  9. Concentrates project knowledge and the big picture in one head, limiting (and sometimes preventing) complete understanding for others.
  10. 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.

Effective architecture:

  1. Provides stable foundation and integrity for the growing software system, enabling desired system qualities for the business solutions.
  2. Ensures seamless and consistent integration, well defined interfaces and interaction between subsystems, external systems and operational environment.
  3. Supports emerging abstractions, key system elements and frameworks for conceptual integrity, efficiency and reuse.

Effective architect:

  1. Guards a system against failure, sensing worrying changes in the project dynamic, system code and business requests.
  2. 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
  3. Encourages constant improving of the code design, enhancing system abstractions and structure, removing duplication, defining boundaries and interfaces of the subsystems.
  4. Keeps solutions as simple as possible, maintains intellectual control over system and avoids over-engineering.
  5. 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?

Useful resources:

Microsoft Architect Certification

Is Design Dead?, Martin Fowler

Big Ball of Mud, Brian Foote and Joseph Yoder

Posted by Andriy Solovey | Permalink | Trackback

AddThis Social Bookmark Button AddThis Feed Button


Comments

I think you are half right about your observations.
Sure, ivory tower architects are useless and ideally you have enough architects to have at least one per development team (who acts as part of the team). Also Microsoft’s definition (as per the link you provided) are less than stellar.

However
An architect does need to have an holistic view of the system – which developers often don’t have. Especially when we are taking about big projects and/or complete enterprises.
A developer can (sometimes) perform the architect role – but the role is still there even if there is no specific person with that title

Another problem that contributes to the phenomena of detachment is that architects are usually scarce so an architect needs to divide his/her time between several project and thus get detached from the development team

Comment by Arnon Rotem-Gal-Oz | August 30, 2007 2:16 am

It’s really time you (programmers in general) come to grips with the fact that programmers are a dime a dozen. As a group you are no more intrinsically artistic than say janitors.

Your function is to program as their function is to clean. You accomplish your goals in much the same way a janitor does. There may be a million and one ways to clean a floor but invariably the most straightforward method is used requiring no special insight, or artistic knowhow, simply using the skills you each as a group were taught.

Just as the rare individual programmer may discover a new method of accomplishing a desired end, so to a an individual janitor may do the same.

The problem with programmers is that not only do they see themselves as better, more artistic than others, but they see themselves in ways they’re clearly not.

Get used to the fact you’re very likely always going to have supervisors, and managers for a reason. To corral the effort that with so many prima donas (every damned programmer on the job) is sure to get sidelined faster in your field than practically any other endeavor.

PS. I wish your profession would stop trying to co-opt titles from more legitimate professions.

It’s not software architect It’s a programming manager/supervisor.
It’s not software engineer It’s a programmer.

As a profession you need to get your own damned titles through merit, not stealing them from other vetted professions with a long track record of legitimate accomplishments.

Programmers are the most whiney group of people It’s ever been my displeasure to meet. They’re right up there with Help Desk folks. Both have a notion of themselves that clearly has no basis in personal accomplishment.

Comment by tom bar | August 30, 2007 3:50 pm

Tom: thanks for your honest opinion. As you probably suspect, I don’t agree with you:

1. There is no intention in this article to whine, promote inflated ambitions and claim that programmers are elite group of the modern society and should rule the world. No, I’m just concerned about writing good software.

2. I’m very sorry that you didn’t have opportunity to meet strong professional team of programmers, who delivers excellent results, solves complex business and technical problems and makes users of their software happy. I’m sure that you would change your opinion and will not consider them as janitors and substantially increase your price of dime for dozen.

3. I don’t care much about specific job titles (even stolen from more legitimate professions), but more care about people and what they do. My personal experience shows that many motivated, capable and experienced programmers don’t need supervision and management shepherds. They have enough intelligence and drive to understand business problems, work directly with customers, come up with effective architecture and implementation. Certainly, they do need help from experts and specialists from other disciplines who join the team as peers.

Thanks again for your time and patience to read the article. I’ll be happy if you can share your specific experience with programmers that made you think so harsh about them.

Comment by Andriy Solovey | August 30, 2007 5:20 pm

[…] should not exist […]

Pingback by Random Syntax » The Role of the Software Architect | August 31, 2007 7:38 am

It is a pity, since you clearly have not had the opportunity to work with good architects. A good architect is responsible for the overall systems design, especially from a functional perspective. The architects goal is to determine what the business needs, and how to get there as efficiently and effectively as possible. The architect will have the overall, holistic view, and will understand what drives the management, business, end-user, infrastructure and development folks, and it is the architects’ job to juggle the various needs, wants, and priorities of these people. A good architect will not be too concerned with how a particular function works, but will be more concerned with the input, output, and flow between functions (or larger objects, depending on the required system). This same good architect will do this less through the imposition of will, and more through the use of collaborative methods, allowing each professional in the team plenty of scope and creativity within their own area of expertise. The vast majority of successful architects I have worked with play along this formula.

“Agile Development” while sounding very cool, comes across mainly as an excuse to rid teams of ultimate, detailed accountability, and the urge to not do any of the boring work, such as documentation (pfft, who needs that, when you can just read the code)

Your post raises some interesting points, but also sounds dangerously close to a whinge and the urge to rid yourself from corporate accountability and management. Your proposed solution does not address several key points:

– how do you determine requirements?
– who is responsible for aligning these requirements to the business needs?
– what is your process for actually doing that?
– how do you objectively match the compromises that you need to make with infrastructure compromises? requirements compromises? budgetting issues?
– if you have no plan, when will you be done? (and no “when its ready” doesn’t usually go down well in a boardroom)
– how do you ensure large teams all remain aligned with the plan?
– when you make a decision full of agility, how do you ensure the infrastructure team is all cool with that?
– what about oversight? what if you found a really cool way of implementing some function, but it totally breaks high availability for example? who safeguards against this, and can take corrective measures before 85% of your system depends on this now unchangeable and critical function?

The answer to all of the above is communication, and taking an objective, impartial view, and “owning” the solution. I know plenty of devs that can deal with this (its not a “I’m better or worst” scenario) and plenty of projects where dev teams actually owned the solution end-to-end. In larger projects however, you will find that all this planning, designing and communicating will take away from your actual development time. Moreover, this stuff pops up all across the day, breaking your flow and concentration.

While your proposal is not impossible, or even improbable, it is highly inefficient, and you have not demonstrated to me how it makes the overall process *better* – i.e. where is the win for the enterprise that would implement your solution (reminding you that this is a solution to an emotional problem for you, the developer, not a defined business problem).

I can counter your “10 reasons” one by one if needed, with clear examples. They do not list problems with the role, or the function, but problems with individual practitioners. I can easily create a list: “10 reasons why all developers are Prima Donna’s” but then I would be doing a great disservice to the many bright, talented, and professional developers I have had the privilege of working with in my career. The same applies to your top 10.

I am sure that you can guess by now that I come from an Enterprise Architecture background 😉 I have had this discussion many times, and for the vast majority of teams I have worked with, any such issues have been resolved painlessly. The funny thing is though, that every time more dramatic actions were needed, the organisation was in serious trouble, from a staffing, political, technical or financial perspective. Projects would have been two years overdue (my latest problem project was running exactly the scenario you describe, where managers and architects had been ditched, but the software was a year and a half late, and did everything, except meet the spec.) dev’s would be directionless and usually disillusioned, ivory towers sacred horses everywhere, etc. etc.

Try working with some quality, dedicated, professional architects. I guarantee you will love the experience!

Comment by Me | August 31, 2007 4:26 pm

I don’t deny role of the architect and need in architecture. I could even agree that on some large projects you need dedicated person who understands the whole system, internal and outside relations and how the system maps to the business solution.

My 10 points are against a popular role of the architect, which

1. Creates premature up-front architecture impeding evolution of the system
2. Makes key technical decisions, instead of helping development team to make these decisions
3. Prevents effective idea flow between business and programmers

Thank you for very interesting and thoughtful comments!

Comment by Andriy Solovey | September 1, 2007 7:57 am

Well, there are things that should be decided by developers and there are decisions that should be decided by architects. I have spent few years as an enterprise architect. And honestly, I cannot imagine that developers should decide e.g. technological platforms, frameworks, integration patterns etc. You have to have in mind that an enterprise have hundreds of systems and also hundreds of developers that were created over tens of years.
Last, but not least. There is always internal politics and company strategy. I just cannot imagine that developers should be informed about all business secrets… sorry, cannot imagine software development without architects.

Comment by Roman Mackovcak | September 1, 2007 1:37 pm

The problem is that in many organizations (like the ones you’re describing) the architects don’t write code, but that isn’t the case the world over. I myself and many other architects have to understand all of the technologies our development teams use, we actually build the prototype along with the development team to learn about any other issues with a particular technology that might require us to change the architecture. So in the general large company case what you’re saying may be entirely true – but in the case of architects who aren’t willing to just abandon their technical side – its actually incorrect.

Comment by Gregory Pierce | September 1, 2007 11:29 pm

Andriy, the point I was trying to make is that what you describe are *bad* architects, not so much popular role definition, or plain architects in general. It sounds like you are in danger of throwing out the baby with the bathwater. If I were in your shoes, I would try to approach the issue of having to deal with bad architects in a constructive manner – i.e. “lets see how we can make this team work more effectively for everyone. I recognise that architects are important to the overall process, but these are 10 red flags. Lets fix that” instead you are saying “This guy sucks, lets fire him, we can do his job” This first approach is more likely to get you support and backing then the last.

Comment by Me | September 2, 2007 10:16 am

You guys make me think really hard to defend my position 🙂 Thank you for constructive critique.

The title of an architect carries connotation (sometimes subconscious) that the person has superior knowledge and skills for making technical decisions comparing to the development team members. Therefore, often it is natural for management to give enough power for this person to make these decisions. Decision making becomes centralized, rigid and depends on limited perspective.

I really believe that emergent, decentralized and evolutionary system development is the best approach to the software creation. As in any complex system/process development in volatile environment, the architect – even very capable and smart – don’t have enough information and feedback mechanism to make correct decisions based on all factors. So, decisions become suboptimal and less effective. It doesn’t mean that developers could do better decisions at the beginning, but they are real creators of the system, closer to it and can better sense situation and necessary changes to keep the system healthy. If they are good developers.

Therefore, I agree – hands on architects and even programming architecture team in the core of large enterprise could be effective and necessary. If they keep options open for the evolution, enhance decisions of other development teams and maintain integrity of all information systems.

Comment by Andriy Solovey | September 2, 2007 11:08 am

I’m a solutions architect so my perspective might be biased. You have some interesting ideas and I’d like to add some comments from my experience –

Saying something is “everyone’s job” means that it is no one’s responsibility. If you don’t have a role responsible for maintaining technical cohesion in the product/environment, especially with a weak central enterprise or a startup anything-goes environment, I’ve seen the situation where every developer tries to conduct R&D in the product and brings their own pet technology into the service.

The metaphor for software architects is the building architect – they understand the requirements and work with the customer (management or customers) and develop a vision of the overall system, then work with builders and technical experts (development) to realize the vision. This doesn’t reduce the role of the developers – they are tool specialists. The architect provides the overall vision and planning for the technical solution, issues where the architect by virtue of experience and training understands that a developer staff might not – regulatory compliance, interoperability concers, security issues, scalability, performance, etc.

I am not trying to start with the line about how developers can’t understand all of these things – of course they can. But that’s not what the company is paying them for. They’re being paid to be tool specialist; quick, efficient, capable of cutting edge delivery. They don’t have the bandwidth as human beings to do all of that -and- stay on top of architectural issues.

You are suggesting that instead of hiring an architect, the carpenters, drywallers, roofers and plumbers would get together and design the building. That would work if everyone could get along and someone would agree to stop doing whatever they were doing and become a draftsman, go to the city council, work with the neighborhood association, etc. Wait, that sounds like an architect….

Comment by calenti | September 3, 2007 1:50 am

This discussion and my arguments are missing clear definition what I mean by evolutionary and emergent architecture. I added a new post related to this topic. I hope it will better clarify my position why a traditional architect role is not needed.

Thank you again for very interesting discussion and counter arguments.

Comment by Andriy Solovey | September 3, 2007 10:08 pm

It is funny that Microsoft offers this MCA certification for software architects, but they do not use architects inside Microsoft.

They actually work as you mention, that is, developers make all the technical decisions and business analysts (called program managers in Microsoft terms) make all the business decisions (which is a tenant of eXtreme Programming too).

This organization of human resources leads very rapidly to repetition (several developers making the same decisions over and over, replicating the same code not just by mere copy and paste, but actually rediscovering the wheel every time), and the same happens with business decisions.

Why don’t developers talk? Because they are rated every 6 months, rated against each other, so reading other developers code and copying it (stealing) is the best way to get recognition. That and also writing several thousand lines of code per day, which means heavy copy and paste!!!

Architects therefore should try to detect and remove copy and paste!!!

Limit the number of lines of executable code to 10 per method. Max 10 methods per class. Max 10 classes per package!!!

This way developers have to THINK! That’s is why they are being paid!!!

If code can’t be repeated and all is unit tested and functionally tested, developers can’t procastinate. Developers are not paid for moving their fingers and heating their chairs, they are paid for thinking, so developers who can’t think should be fired!!!

Comment by Funny Thing | September 6, 2007 10:47 am

1) Finding good programmers is hard because creating efficient and readable/maintainable code is inherently complex. You need years of practice on data structures and algorithms, in order to become a good programmer.

2) Designers are essentials. Object-oriented design and design patterns are not something you can expect from a simple programmer. Moreover programmers might not understand the implications of design choices in terms of scalability or security.

3) Architects need to have good technical competences, but they also are the interface with the customer, they really have an holistic view over the entire system, define the interfaces among the main sub-systems, etc.

However, it is also true that such a clear distinction between these three professional profiles is very clear only in medium or large projects (20 man/years at least), while tends to blur in smaller projects. I think this is the reason why it is so difficult to agree on the role of each profile….

However I’m quite surprised by the fact that in the comments nobody mentioned the “Designer” profile, and somehow merged its responsabilities with Architect’s ones…

Comment by Antonio Leonforte | September 6, 2007 2:08 pm

[…] Do We Need Software Architects? 10 Reasons Why Not […]

Pingback by links for 2007-09-07 « It’s Not Rocket Surgery | September 7, 2007 3:23 pm

Antonio: you raise two interesting problems

1. It is difficult to find a good programmer. I agree that not every project can afford ace programmers. However, it is similar to natural selection – more complex systems require higher qualifications and you can find less programmers capable of working on it. This post discusses the system development level where architecture concerns become important and choice should be made – hire dedicated architect or programmers who can make architecture decisions.

2. Need in the separate role of designer. I argue in this post that we don’t need architects and all the more we don’t need designers 🙂 All the arguments above apply. An architect role has some reasons for existence in the complex multi-system environment, but a designer role just covers lack of core programmer’s knowledge for building a non-trivial system – algorithms, patterns, performance, security, object-oriented and platform idioms. What is left for programmer? Maybe, experienced coach in the team is needed for less experienced programmers, but eventually they should learn all this stuff.

Comment by Andriy Solovey | September 9, 2007 9:14 am

A good post with some good feedback. I think both sides make excellent points.

I have seen the architects who don’t know low level implementation details about the technology being used. So the architecture they create, while logically sound and contains many wonderful design patterns actually is not implementable using the chosen technology. And I have seen smart developers reduced to code monkeys developing something they think is at best wrong and at worst stupid.

In my experience the best approach has been a collaborative one where the development team works together to come up with ideas to create the solution architecture. In terms of accountability, you can have a strong technical lead who is responsible for delivery of the document but that does not mean they have the only input.

If you must have an architect and they are not current with the technology or have in depth knowledge, I think it is important to have a strong technical lead on the project that they trust who can keep the design in harmony with the technology.

Comment by Tuzo | September 9, 2007 11:05 pm

[…] with regard to how it can impact on an agile development project. I recently read (here) a very short list that resonated really powerfully with me and describes key architectural […]

Pingback by John Rayner's Blog : What makes a good (software) architecture | September 11, 2007 5:47 pm

[…] Do We Need Software Architects? 10 Reasons Why Not, Software Creation Mystery […]

Pingback by 303 Insanely Interesting Links From 2007 -- Jarkko Laine - Insanely interested | December 26, 2007 2:37 pm

[…] Software Creation Mystery » Do We Need Software Architects? 10 Reasons Why Not (tags: architecture software architect development engineering humor programming process agile) […]

Pingback by links for 2007-12-28 « .$null@dscape/07 | December 28, 2007 2:21 pm

This is a great post, the words I was searching for years! It is true that a lot of these inflated salaried ‘architects’ screw up products, justify their huge salaries to the top management using jargons and vague functional aspects.
Thanks

Comment by Janitor | January 24, 2008 11:36 am

To be a good architect, you *must* be a good developer–and vice versa. If you fail to hone both skillsets, you’ll eventually discover that either,

a) You’re incompetent; or,
b) Everyone else is incompetent.

Of course, the correct conclusion is “a”. Ironically, those of you who chose “b” don’t realize this yet (and probably never will).

Comment by B. Waite | February 27, 2008 2:37 pm

[…] Soren shared a interesting post Do We Need Software Architects? 10 Reasons Why Not […]

Pingback by Becoming a Java Architect!? -- Dreamz | July 30, 2008 9:12 am

Most of architects know nothing about software creation, they think they are smarter than developers, they choose to be architects because they want bigger salaries and they don’t like to work.
They don’t love programming and they only cares to have a high position in a company.
I don’t want to get rid of architects, just pay them less than a programmer.

Comment by calciu sorin | October 9, 2008 2:13 pm

I think the article has some truth in it but nevertheless it is very biased from a developer’s point of view (which is not something to be surprised in case of Microsoft related development work). Microsoft had to create an Architecture Profession because they are more up-to enterprise class solutions now. Microsoft developer community needs to understand this first.

What is proposed as “The Ultimate Solution” will work only if you practice AGILE project methodology for isolated or smaller sub-projects. Nothing to use in big programs which require thorough strategies.

The author assumes that all Architects are some kind of retired developers (old fur) who are not up to date in technology. This is wrong. In contrary architects are proficient in latest technologies but they also bring a great deal of experience. Today’s business challenges are not to be solved by technology only. Nor each new technology brings really new concepts to the scenery.

If you have a hammer in the hand, you are wrong if you think that everything can be hammered down. Usually developers tend to think that a Visual Studio or Eclipse tool with appropriate libraries can solve anything (I know because I was one of them in the past) without thinking about the “cost” or fit-for-purpose. This is usually because of the self-pride, which is a good thing actually.

I highly respect smart developers. They’ll eventually become next generation architects, anyway 🙂

Comment by Behcet Tolga | July 14, 2009 6:19 am

This blog have little value without you and your comments, thoughts and discussions. Please, leave your comments. You are welcome to debate and criticize any idea, but, please, don't attack other people. Thanks for your contribution!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Subscribe without commenting

Software Creation Mystery - https://softwarecreation.org
This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 License .