Presented by Peter Eeles of IBM UK.
The idea of the talk came from the book “How to measure anything”. The short version of the talk is that
- successful architects share common personal traits;
- successful architects have repeatable practices;
- these traits and practices can be applied to anything!
You exhibit these personal traits:
- You are a technical leader
- You understand the delivery process
- You have knowledge of the business domain
- You have technology knowledge
- You ahve design skills
- You have programming skills
- You are a good communicator (both oral and in writing!)
- You are a mentor
- You are aware of organizational politics
- You are a negotiator
You apply these practices when you architect….
- You focus on the architecturally-significant elements
- You consider multiple viewpoints and perspectives
- You meet the needs of stakeholders
- You focus on a particular scope (“There is always a bigger fish”)
- You make decisions based on rationale and tradeoffs
- Your solutions conform to an architectural style
- You use and create reusable assets and knowledge
- You recognise the influence of the environment
- Your emphasis changes over time
- You are involved in all delivery disciplines
At the same time you work with many different assets as an architect. Also, your emphasis should change over time: risks are one of the main drivers for architecture. You should explore risk, and try to mitigate or better remove these.
Okay, we have seen all these practices and traits. How do we architect? We can apply it on anything! A nice example is the deployment environment. It should support the applications used by experts. How does the environment look like? Let’s architect it! So, consider multiple viewpoints and perspectives for it!
Next, identify the significant elements of the deployment environment for each of the elements, and set the scope. Make sure you know your stakeholders, and the environment, the context, in which your system is going to exist.
For academia, it is important that theory is not only taught, but also experienced in practice. By giving the students a framework and case studies on how people have applied it, will help teaching. But there is no substitute for doing it yourself. Even from failing you learn: make mistakes early on, and learn from it!
An important aspect that is hidden is the role of the architect in the organisation.
Bottom line: find you a mentor, and architect anything, it will make you a better person!
Some last pointer by the presenter to read: “Mommy, where do software architectures come from?” by Philippe Kruchten