The human feelings is a decision making variable that software architects must consider when architecting or more importantly – when strategizing a software system. This is especially important in environments where users have technology based scars.
Situation: Users had (or still have) a bad experience with implementation, deployment, and support of an enterprise grade solution. The system was adopted by a large (7000 people) organization through a mandate – people use it on a daily basis because they are forced. This brute force approach has done a tremendous damage to users’ trust and any new IT investment will be severely challenged.
1. Recognize the pain your future users are feeling right now. Study the situation and learn their existing environment. Understand the challenges of that system – you may face them as well.
2. Clearly understand the business problem you will solve with a software solution. You must, absolutely must, get different perspectives on the problem from a full range of stakeholders – from executive owners to the solution end users. You must be convinced that this solution will solve a business problem.
3. Go an extra mile when documenting the quality attributes of the system to demonstrate through scenarios how your system will not have the frustrating elements of the existing system that scarred the users’ experience. Consider paying an extended attention to the usability quality attributes.
4. Architect your solution so that initial implementation steps can demonstrate progress early. Create a special view of the architecture (an abstract component connector view will work well) targeting your non-technical user base.
5. When possible consider using software you can configure (e.g. COTS packages) to show progress early and often.
6. Conduct demos to the right audiences: the user base influencers. Demonstrate through actions how your approach to architecting and implementing is different than the experience your users had. Especially pay attention to the pain points your users have suffered with another solution. Ask for feedback. No. Demand feedback.
7. Remember that even if you get the architecture “right” it may be implemented wrong. On project you must stay fully engaged in the implementation and monitor conformance with the architecture as if your reputation was on the line. Actually, your reputation is on the line.
In this type of a situation it may be appropriate for an architect to pay a lot of attention to the user touchable interfaces (i.e. UI) before immersing one’s attention on creating a solid skeleton of a system that captures conceptual integrity of the system.
Do you have an experience to share where human perception played a role in your architecture related thinking? Leave a comment.