Hitchhiker's Guide to Software Architecture and Everything Else - by Michael Stal

Monday, March 27, 2006

Software Architect Part II

I got some feedback from people asking me whether there ever can be a software architect with all the qualities and experiences I have introduced in a previous posting. Nonetheless, my opinion still remains the same :-) In some of my last projects we came up with interviews that checked for exactly the experiences and expertise described. And there were several software architects that passed the test. The problem these days is that no world-wide accepted qualification for software architects is available. Nor is there any role description. When and how will you know whether you can call yourself a software architect? I've provided all these little clues to help you here. All those experiences and expertise are particularly important to be recognized as a good software architect.
I'd like to introduce another perspective to shed more light on my points. What exactly are the typical activities of a software architect? Note: no guarantee for completeness given here.

From my viewpoint being an architect implies a really big workload. Architects need to:
  • help clarifying the business case and support SWOT analysis if required
  • help estimating required costs, resources, persons
  • help providing a domain language and a DSL (optional)
  • clarify all use cases and requirements as well as other open issues
  • build an interface between developers, testers, and other stakeholders
  • estimate iterations and increments
  • assess at least the most critical technology options
  • make sure the right tooling and technology portfolio is used within the project
  • communicate with system architects to gurantee proper interaction between infrastructure and software architecture
  • commit Commonality/Variability analysis when a Product Line Engineering approach is taken
  • develop and document an architecture vision that already contains strategic decisions. Note: this also implies that architects must decide whenever there are different options! Software architecture is not an automated, deterministic process without any degrees of freedom
  • help defining architectural guidelines for central issues such as error management
  • empower other developers and architects with respect to all architecture aspects and architecture concepts
  • take responsibility for all decisions and support partitioning and distributing tasks
  • design all structures and behaviors so that they meet requirements
  • supervise refinement and implementation of the architecture
  • support quality assurance for all parts implemented by distributed teams and integrated into the product. Note: outsourcing and offshoring can be considered just special cases here. I am not considering any cultural, or legal issues in this context
  • prove the feasability of a whole software architecture, of its parts, or aspects being leveraged by prototyping
  • review software architectures and re-engineer them if necessary
  • take test results and feedback as input for refactoring activities
  • communicate with key developers to make sure the tactical design does not violate the strategic architecture
  • simplify and refactor for injecting properties such as readability, extensibility
  • implement (but not on critical paths)
  • make sure re-usable assets are integrated
  • meet with customers to obtain feedback also during the project

All these points may be uncritical for small projects that use proven technology. This might imply that architects don't need that kind of high profile. Take a one-person project as the most extreme example. As soon as large projects and high risks are involved it is inevitable to make sure, architects can really handle all the aforementioned issues and cope with them. Hope, you can now see from this activity list, how all these required experiences and expertise were derived in my former posting.

And I definitely appreciate additional feedback and comments

posted by Michael at 12:47 PM

5 Comments:

  • When I read your last posting about the role of a software architect I was very sceptic if someone could be capable of handling all these tasks and having all these skills at all. And to be honest, I still doubt that there are many persons who are. At least I think there are more high-risk projects than such high-quality software architects ;)

    But I thought a lot about your point of view and I have to admit that your arguments convinced me. A software architect plays a key role in a software project. One wrong decision in an early project phase can have catastrophic consequences in later phases or can even make the project fail completely. And making the right decisions is more likely with a bunch of experience in the background. On the other side, having a good architecture with all decision done right is nothing if you cannot communicate it to the stakeholders and to the developers. So it is the right mixture of experience and soft skills that makes you win the game.

    So, I am convinced but that doesn't make me very happy, because software architect is the job I want to do in the future. With all these topics in mind it turns out to be a hard task to get there.
    The most disappointing about all this you already mentioned in your posting: there is no qualification and no standard. For me it is a difficult task to decide if/when I have the skills or if I do not. Reading books about software architecture, patterns, etc. is good starting point but cannot give the necessary experience. From my point of view it must be some kind of 'training on the job'. I.e. joining a large scale software project as a junior software architect where you can take over all of the tasks, but you are coached by a senior architect with all the necessary experience.

    Is this coaching model kind of realistic or do most stakeholders only accept 'full blown' software architects?

    By Anonymous Anonymous, at 12:40 AM  

  • Yes, you are right. It is really difficult to become a software architect. There are qualifications such as the CMU SEI is providing. However, all of these courses only follow their special view of the architect's role. I'd really like to help defining such as qualification. I've been involved in efforts defining this role for a business unit of Siemens and for a Swiss railway company. I personally believe that learning from books, attendingh conferences and seminars, as well as getting an experienced software engineer (learning by doing) is a reasonable way if you are ready to continuously reflect on your own capabilities and to decide what else is missing in your portfolio. But as mentioned a concrete qualification would be really important.

    By Blogger Michael, at 8:41 AM  

  • I'd also look into http://www.opengroup.org/itac/cert/.
    Being an aspiring Architect I have consulted with a well established software Architect and he recommended that cert as a guideline to follow.

    I plan on using that cert as a sort of measuring stick to evaluate myself by. I also believe receiving a cert from such a well defined program would give any potential employers a solid understanding of my competencies.

    By Anonymous Anonymous, at 12:14 AM  

  • Yes, the main problem is that no world-wide accepted qualification for software architects is available. By the way thanks for sharing this wonderful article.

    By Anonymous Outsourced Software Testing, at 9:48 AM  

  • Great share! Thanks for the information. Keep posting!

    By Anonymous Fleek IT Solutions, at 8:30 AM  

Post a Comment

<< Home