P&P Summit Day Four: Architecture Evaluation in Practice

The closing Keynote was given by Dragos Manolescu from the Patterns and Practices team.

Dragos started with a slide for all the contact addresses for the people at P&P.

He states that we spend a lot of money dealing with architectural problems. In order to evaluate architectures that can then be used as models to deal with our problems we can use three models:

• Simulation - useful for manufacturing.
• Checklist-based - used for product based development.
• Scenario-based - use scenarios to see if the architecture meets the goals. Most widely used.
  • Software Architecutre Analysis Method (SAAM), etc.
  • Back of the envelope results, not precise
  • To do this:
    • Articulate arch goals in scenarios.
    • Prioritize arch goals.
    • Analyze arch strategies.
    • Assemble risk themes.
    • Feed back into business drivers and architecture.

The book “Software Architecture in Practice” is a good resource about this subject. Architecture evaluation is harder than it seems, so don’t completely rely on the book.

What Dragos has learned in his own evaluations:

• Most projects don’t meet the pre-requisites for evaluation. This means that not enough of the architecture has been decided upon when the evaluation starts. Make sure you know what prerequisites are before an evaluation before requesting one. Sometimes people requesting the evaluation don’t understand the evaluation goes beyond the technology choices. It also includes how the architecture meets the goals of the software by the stakeholders.
• You need to ensure that the stakeholders know what they are getting and what is realistic. For example, make sure that the stakeholders understand the tradeoffs for features and requirements vs time, money, complexity, etc.
• People underestimate the amount of time stakeholders need to spend in this process.
• There is great variance in architecture work. Be ready to spend a lot of time looking through the artifacts of the architecture.
• You sometimes find there is significant misunderstanding of the problem. That has to be communicated to ensure the architecture will actually solve the problem.
• Projects sometimes fixate on quality goals or reuse via frameworks and thus get disconnected from the stakeholder’s goals. Find what they are missing.
• You need to go beyond the IT department to ensure that there is not a weak connection with the business so that the architecture will meet the needs of the stakeholders.
• Be sure that a driver behind the architecture is not so that the IT group wants to play with new toys.
• Understand that stakeholders are disconnected from the architecture. You need to figure out who the stakeholders are and get access to them for the evaluation period. Also be sure the architect knows who the stakeholders are. Also try to pick up if stakeholders have different agendas than others.
• Sense whether if the evaluation has been commissioned just for show. This happens sometimes is done to justify a decision that has already been made. This can be difficult to explain if the results aren’t good.
• Sometimes the evaluation has been commissioned to win an internal battle within the company around multiple solutions. This can also be difficult.
• You are not always welcomed when doing an evaluation. You have to deal with protective architects in some cases.
• Tools can place constraints on architecture evaluation. To mitigate this don’t let the tools change the evaluation process. Some tools may be mandated to justify their purchase.
• Define a set of architecture goals (Functionality, Automation, Flexibility, etc.), then break those down to scenarios that can be used for the evaluation.

Dragos speaks VERY fast, so I didn’t catch all of what he said. This is a topic that is interesting, but probably something I’m not going to be involved in any time soon.

Well, that’s it. I’ll be doing a wrap up post and overall impression of the conference in a few days. Time to get something to eat and then get ready for my red-eye flight home.