There are times when your gut instinct tells you that a solution is wrong. The architecture or design is not clean, functionality seems to be in the wrong place, interfaces feel like they should be different, data is duplicated or tramped all over the landscape, the solution seems too complex, it appears inflexible, it seems to be storing up problems for the future.
However, convincing people that there is a problem and that an alternative approach is better can be difficult. The project or program has a momentum that is carrying it towards the creation of an expensive and avoidable legacy.
Before we consider what you should do let us quickly clarify what not to do! DON’T…
- Get angry– it may be frustrating but you must be seen to be calmly working in the interests of the business.
- Get negative – you must be seen to be passionately behind the business goals.
- Don’t waste your ammunition by putting forward weak unsubstantiated arguments.
- Appeal to abstract architectural principles – while they may make perfect sense to architects, generally no-one really cares! (This may appear to be heresy – but I will return to this)
- Lose credibility.
Now let us look at how to move forward…
The first point is that within a project you don’t normally have much time. You must be focused, effective and efficient in substantiating your gut instinct, preparing and delivering your argument to the right people, and getting a project to reconsider its course.
Step 1: Determine your goal
Find out when key decisions are taken, when the project becomes committed to a course of action (e.g. contracts get signed, resources are assigned, work starts, announcement are made, egos are on the line). This determines what you can achieve:
- You don’t have time to understand the issues fully – your aim here is to make sure that decision makers have “wiggle room” and can change their mind at a later date rather than force through a bad solution.
- You have time to frame the problem and present it to the right people – your goal is to persuade them to create time and make resources available to find the right way forward.
- You have time and access to the resources you need to prepare a solution and get backing for it. This is rare ideal where you can be the leader.
Step 2: Understand the business drivers
Its all about benefits… what are they? Are they increased revenue, reduced costs, keeping up with the market, reputation protection, risk reduction, regulatory or statutory changes? When are they due to be delivered? What has been promised to investors? Are there any regulatory or statutory deadlines? Whose ego is on the line?
The business case for a project is the obvious place to look. However, business cases should paint a prudent picture and are written to overcome a hurdle in the investment process. Expectation could be significantly different, there may be other hidden or implicit or intangible benefits that are much more compelling to the key stakeholders. Understanding the business sector and the stakeholders is key to getting a full and accurate understanding of business drivers.
Timing of benefits delivery is often a major driver for compromise. If your proposals are perceived to reduce the level of benefits or put the timing at risk, then you will probably lose credibility.
Step 3: Understand which business drivers are threatened
I was lead architect for a project where we were introducing a new channel for a client. I felt very uncomfortable in taking the current architecture forward but I couldn’t pin point why.
The simplest solution to introduce the new channel was to extend the current solution. However, it felt like functionality was incorrectly distributed between applications and we would be making things worse.
What I needed to do was to identify the impact on the business drivers. I knew that the client was growing this part of the business but there was no clarity over how it would do so.
I knew how the application should have been built, I new how I wanted to take it forward. I could only make a vague case about enabling future business flexibility which would add cost and risk to the current project.
I managed to find a stakeholder, after much enquiry, who was prepared to very forcefully articulate the future direction of the business. He wasn’t particularly senior, he was not a key decision maker, but he was respected and influential. He was very interested in the threats to this future and was prepared to sponsor a rethink.
I struck lucky which enabled me to challenge (via a proxy) the accepted thinking and get rational compromise to be made and a longer term roadmap to be developed.
If you can’t make the case, then you have to accept the solution as is and move forward.
A word on architecture principles…
Each principle should have a rationale that is clearly based on business needs. If a solution violates a principle then look to the rationale to identify the business imperative that the principle is designed to support. While the principle may not interest many stakeholders, the underlying rationale should do.
Step 4: Understand the stakeholders
Architects often raise concerns where the longer term flexibility of solution has not been thought through or where a solution appears to cause problems in another area of the organisation.
As a solution architect, your responsibility is to ensure that the right solution for the organization is defined. “Right” is defined by the “business” – however, the “business” is an ambiguous concept. The justification for all architectural decisions must be “to meet business requirements”.
The key to resolving the architectural concerns is to involve all affected stakeholders in the project and ensure they express their requirements for the longer and shorter term. If you have all the key stakeholders who will be affected by a project in both the short and long term then you will be able get requirements, constraints and directives that provide the business rationale for architectural arguments.
Obviously, to get requirements from stakeholders you need to know who they are. If you already have a network of contacts then this will be easy. If you don’t then you will need to find some allies to help you identify key stakeholders.
With business requirements to back your arguments, you can give the program or project manager the “wiggle room” they need to start to change the project remit to take into account architectural concerns.
If you can’t get the business backing, then you have to accept the solution as is and move forward.
Step 5: Address objections
Sometimes there is push back that states “this is scope creep” or “this project is for XYZ business unit” or “we haven’t got time”.
Scope is best dealt with by specifically de-scoping requirements with knowledge of all requirements and an understanding of the implications of de-scoping. The de-scoped requirements allow others to take appropriate action with the knowledge of the project. It enables a roadmap to be developed to address de-scoped items. Refusing to collect requirements is not a reasonable approach.
Limiting stakeholder involvement based on who the sponsor is or which business unit has get the major benefits is also not reasonable or wise. Proper stakeholder analysis is essential and all affected stakeholders should be invited to contribute requirements.
Time is a legitimate concern but the reality is that only a small amount of time is required. Architectural decision making normally requires high level direction across a broad area and perhaps more detailed requirements for small but critical areas. Key people can be seen on their own at time to suit them. You don;t always need workshops, it is amazing what can be achieved in 15 minutes if you try!
Step 6: Drill down on the business impacts
The initial "gut instinct” about the solution that caused your concern should now be expressed as requirements that are at risk. They may be:
- non-functional requirements about performance, scalability, security, reliability, etc
- business requirements relating to future proofing, broader business areas affected by the project, downstream project dependencies, etc
You will need to understand the benefits of achieving and the impact of not achieving these requirements.
Step 7: Frame your initial solution options
Your solution options should include:
- The original baseline option that you were initially uncomfortable with. In addition, you will need to develop an outline roadmap that delivers the additional needs.
- The ideal option, this will be perfect design that you would produce if you were starting again. You may have to rule this out immediately if the distance from reality to perfection is too great. But it does give you a benchmark.
- A small number of options (realistic maximum is around 3) with outline roadmaps that provide different routes to meeting the business needs or different levels of compromise to those benefits.
There should be significant differences between the options. They may have different:
- benefit levels
- timing of benefits
- business processes
- levels of automation
- business or IT risk levels
- business or IT resource requirements
- needs for business involvement
- costs and cost profiles
- data distributions
- non-functional characteristics
- approaches to re-engineering
- refactoring plans
For each option a high level delivery plan with an initial assessment of business benefits and impacts with timing should be developed.
You now have the evidence to persuade key stakeholders that the program or project needs to take a step back and identify the best way forward.
Step 8: Carry out a feasibility study
All the previous steps typically have to be carried out rapidly and sometimes superficially because you may not have fully contained the momentum of the project or program.
If you have managed stakeholders and framed the options adequately then you should be in a position to investigate the identified options, identify the trade-offs, make a recommendation and develop the new solution architecture and roadmap.
Finally, Expect the unexpected
This will not go as planned. Despite logic, decisions you don’t understand will be made. You will never get the full story. You will never fully understand the stakeholders and their motivations.
If you don’t get what you want then accept defeat gracefully.