Tough crowd: architecting in a shadow of a challenged project

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.

Potential solution

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.

Constantin K.
Firebrand Architect™
www.SoftwareArchitectures.com

The cost of politics on software development

My gut feeling is that organizational politics introduce a 25% overhead on all software development projects. I strongly feel that a formula can be devised to determine the cost of politics on software development. As a matter of fact when I pondered pursuing a Ph.D. in software engineering I thought this may be a worthwhile topic to explore.

The reason this subject matter is brought up in this blog is because politics are unspoken constraints on a project.

The software architecture practitioners are finally maturing to a point where system’s quality attributes are measured in a meaningful way. For example, to express performance requirements of a certain aspect of a system an architect would create a scenario that may sound something like this: “8500 users stochastically add one item per minute to their shopping cart while the system operates in the ‘holiday shopping mode’ and the requests are processed with an average latency of 3 seconds.” A series of such scenarios provide a working reference for an architect to aid him in design a system to meet these quantifiable requirements. But how to measure the politics quality attribute?

Finding a way to measure politics in some useful and meaningful way is important, because politics present design related constraints and risks that must be mitigated. In my recent architecture analysis task I noticed that a cluster of database servers had to be two thousand miles apart from the web and application servers. When I inquired about the reasoning I was tacitly told that the two different bosses from two different datacenters wanted a stake in a high visibility project. I was assured, however, that a “very fast backbone” will provide sufficient latency between the locations.

The first step to tackling this problem is to define what one means by politics and in what units can this property be measured. Because politics are unspoken in most organizations the architect would have to decide how to represent this constraint and mitigation strategies on paper. Or can this be done on paper? Or is this something that an architect should document privately? If so, who else should be aware of this information?

Your thoughts are welcome.

- Firebrand Architect on duty: CK