On this page:

Critical Success Factors

Pitfalls

Your List of CSFs and Pitfalls

"Lessons Learned" by Clayton Sprung

The top critical success factors for the architecting effort that we have identified are:

The architecting effort must:

• address a strategic business objective of your key sponsor
• have a good lead architect with well-defined role and style
• have a lead architect and architecture team who are able to "sell" (lead); conversely, the organization must be willing to "buy into" (follow)
• contribute immediate value to developers (utilizers of the architecture)

The architecture is more likely to be successful if:

• there are architecture advocates at all levels of the organization
• architecture is woven into the culture
• there is customer involvement/pressure/demand

The following critical success factors and pitfalls for architecting projects were identified by participants at the start of our software architecture workshops.

Critical Success Factors

• Interpersonal and team communication and ownership
• Leadership
• Vision
• Teamwork
• Availability of talent/resources
• Must have strong management sponsorship
• Market/business understanding
• Good match between technology and business strategy
• Customer focus
• Clear specifications including dependencies
• Simple architecture
• Deployed in phases/incrementally
• Architecture is understandable by all
• Solve at least the current problem
• Validation of requirements during each step of the process
• Project management

The architect must have the following skills:

• good domain knowledge
• good communicator/listener
• good persuader
• good project management skills

The architect must

• have a clear and compelling vision
• champion the cause
• provide constructive feedback

Pitfalls

• Poor leadership
• Thinking at too low a level
• Poor communication inside/outside the architecture team
• Not enough "selling"
• Lack of resources/talent
• Poorly designed roles and responsibilities
• Bad design/idea
• Lack of extensibility
• Doesn't solve the project team's problems
• Lack of control/authority
• Requirements unclear, not well-defined, not signed off, changing
• Architecture team loses touch with the product team's problems
• Product team believes "we can solve it better ourselves"
• Development management not penalized for "stalling"
• Politics

Success Factors and Pitfalls Identified by Visitors

If you are a practicing software architect, we would like to post your list of success factors and pitfalls in software architecting here.

Roger Ball, Alkire Ventures LLC, Lakewood CO <October 23, 2009>

• Find a way to get an architectural mechanism up and running in at least an integration environment early in the process.

Seb Chakraborty, Telefónica O2 UK Limited, UK <October 15, 2009>

• Delivering 'incremental' business capability 'fast' (confidence and trust in IT needs to be earned)

Anandasubramania Codangudipranatharthy, Ness Global Services Pte Ltd <November 15, 2005>

• Commitment from management
• Divorcing Project Mgmt from architecting, management needs to understand that architecting is not something that "needs to be done with ASAP", and instead understand that it is an essential part.
• Allotting enough time for architecture (1/3 of total time for a project, rather than 1/5 or 1/6 as of now)

Shashank Tiwari, Saven Technologies Incorporated <October 13, 2005>

• Keep it Simple
• Focus on the first principles
• Breadth and depth of knowledge
• Use multiple perspectives to analyze an architecture
• Illustrate with examples and explanations for better understanding

Gyan Jadal <October 13, 2005>

• The architect explains the architecture to the implementation team.
• The architect has knowledge of the language/technology in which the architecture is going to be implemented.

Haseeb Toor, Vistakon <August 06, 2005>

• Well-rounded personality
• Vision based on of Business need\
• Effective Leadership
• Ability to visualize abstractions
• Well-grounded and sound architecting principles, and architectural patterns

Ajay Gandhi, SIRC

• Be a team player. Be flexible with the rest of the team members. Mingle with all sorts of team members and understand their frustrations, show stoppers and their requirements and get their feedback.
• Base the architecture on the functionality of the Language, OS etc. not on the Development Tools. (e.g if JAVA is the language then the Architecture should not mandate a IDE tool, rather he/she should work on  concepts like Servlets, JSPs, EJB etc.)

Parag Patel, HBI

• Be a "Jack of All Trades and a Master of ONE". Each Architect must have a good overall skill set and at lease one specialized area of knowledge. 
• Firm business and technology requirements: Know the purpose and scope of the effort before you begin to design the system. Work from the requirements, not from the "end" state; reverse engineering is NOT Architecture. 
• Project Management (PM) Disciplines. The role of an Architect is very similar to that of a specialized PM; thus, all the same disciplines apply: be diplomatic; be articulate; be a team player; be a leader; etc. The architecture team/group should be involved with the project from conception to post implementation (closure). This allows for the checks and balances of what goes into production is what was designed. Also, any changes made to the design during the build phase can be fed back to the Architecture process for improvement.

John Betancourt, Intelleges

• For most people, when they first learn to play chess, they focus on learning the rules. The next step is learning how to play well. Technology, with the advent of OO and fully integrated enterprise-wide component based systems, has likewise shifted from a domain where people are just learning the rules, to one in which strategy, experience, and focus have become the most important factors. It is a given that architects must know the rules, i.e. the technology; it is also a given that their success will depend on more than just technology.

Roger Ball, Alkire Ventures LLC, Lakewood CO <October 23, 2009>

• Difficulty in establishing clear short term and longer term goals

Seb Chakraborty, Telefónica O2 UK Limited, UK <October 15, 2009>

• Architectural Elegance by itself is not enough (check and check again that the change is delivering a strategic capability)

Anandasubramania Codangudipranatharthy, Ness Global Services Pte Ltd <November 15, 2005>

• Dual roles as Project Manager and Architect will fail in both: PM is task driven and time driven. She is bound to make compromises on architecture to make sure product is delivered. An Architect allows no compromises that challenges basic assumptions. If the same person is doing both, neither will the architect be perfect, nor the project be delivered on time.
   

Shashank Tiwari, Saven Technologies Incorporated <October 13, 2005>

• Force fit to popular frameworks
• Be pedantic or be bound by definitons
• Fail to question perspectives from famous architects Be arrogant and closed to feedback and alternative opinions
• Use too much jargon

Haseeb Toor, Vistakon <August 06, 2005>

• Design by committee
• Analysis paralysis
• Abstracting architecture from implemented code
• Bleeding edge mania

Ajay Gandhi, SIRC

• Complicated Architecture
• Dictating the Development Tools to the Development Community
• Managing Day to Day operations for the Implementation
  

Parag Patel, HBI

• Lack of knowledge of Technology's "Bleeding Edge": Knowing where the market is headed is as important as knowing where it has been. Not knowing what is reality vs. "blue sky": You cannot build on future technologies that do not have a deliverable date ("PowerPoint Systems").

John Betancourt, Intelleges

• lack of clarity
• lack of agility
• lack of flexibility
• lack of integrity
• lack of vision

• Complicated design (e.g.,  includes large number of moving objects created just to show that you are using the latest technologies)
• Decisions taken to avoid some technologies (e.g.,  we will not use stored procedures, we will not use Javascript, we will not use even a bit of Java in JSP. Some factors like these put a big constraint in the architecture. When things can be made simple--Keep It Simple! :)
• Poor understanding of the client business domain/improper communication with the clients.
• Forgetting to do an initial check of the code implementation. This is necessary to check whether the architecture/design is implemented as stated. This is very important because most developers will do a copy and paste of code which is already developed.

References

Dikel, Dave, et al. "Software Architecture Case Study", presented at Reuse'96.  See slides 22-29 for organizational success factors for software architecture in a reuse (product family) context.