beyond the tools of the trade
Architects like to discuss the type of framework they use, their preferred patterns or the pros and cons of a new technology. We, as many other professionals, have a fascination with the tools in our tool bag. But the success of our projects often rests on other, less tangible skills. Here’s five that I’ve found particularly useful.
- Know your stakeholders: Although fairly obvious, it can be a very challenging activity, but without, it possess a real risk to your project. And knowing your stakeholder is fundamentally a question of knowing the social network of your client – a daunting task if you are new to the organisation or if the organisation is large. We all know the traditional approach of asking our project sponsor, organising planning workshops, and compare our list with other stakeholder lists. A very interesting new take on this challenge came as part of Soo Ling Lim’s Ph.D. research. Her basic idea was to apply crowdsourcing to stakeholder identification creating a snowball like process. You can try her very clever tool at Stakesource.
- Keep it simple: A universal design principle, but it is spelled KIS, not KISS. Why? Probably for the sake of correct spelling, people have included ‘stupid’, ‘short’ or ‘straightforward’ as part of the acronym. But there is nothing stupid, short or straightforward about creating simple software that is truly useful – otherwise using software would probably be as easy as driving a car. Whether software is ‘simple’ and ‘useful’ comes down to a question of perception, so we are back to the first point.
- Know how to deal with uncertainty: Developing software is a complex undertaking with at least some degree of uncertainty, and you or your team cannot know everything. Uncertainty can be a lack of knowledge about requirements, the utilised technologies, or the environment. This can typically be addressed either through specific analysis activities or through sourcing of additional expertise. Uncertainty also creates risks for which you’ll need a risk mitigation plan.
- Evaluate your architecture: Unlike code, you cannot test your architecture the same way you can test code, but there are a number of good ways to continuously evaluate your architecture:
- Present your architecture to your stakeholders while being mindful of their individual concerns – you need to know about ‘architectural views’. If they don’t understand it then it is not going to work. And when they do understand, they’ll have the opportunity to provide feedback enabling you to explain and test your design rationale.
- Use general peer and specialist reviews.
- You might want to conduct a proof of concept or pilot phase, although far from mandatory. A PoC can be a good way to evaluate specific and important parts of the architecture using prototypes, but be mindful of the PoC anti-patterns: The mini-project, fuzzy questions or success factors, and a loose scope. If you are going to re-use prototype artifacts then be sure you know what quality trade-offs were made in order to meet the (short) PoC time frame. And even well developed code can be useless, if the architecture of the prototype is inappropriate. In other words, know your ‘technical debt‘.
- You: The role of an architect is a leadership role with its own KIT:
- Kompetence: Be competent by showing your stakeholders a well referenced, well argumented, and traceable rationale for your architecture.
- Integrity: Be the best advocate for the concerns of your stakeholders – if you believe they are wrong then its your job to convince them otherwise.
- Trustworthy: Backup your words with action, and always be available to answer questions and provide guidance.
I’m sure there are other critical and useful skills – feel free to list yours