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

Control Your Engine!

Imagine you’re building a car. You get car parts, including an engine, from various vendors [think COTS software] and different people help you put it together along the way [think contractors & subject matter experts across divisions]. You’re making progress – you have attached the wheels and can push the car through the product line [dev / test]. Now you’re reached the end of the product line. It’s time to start the engine and drive [pilot stage]. The engine turns but doesn’t start. After troubleshooting and double checking your work you find out that the engine [think messaging infrastructure] doesn’t work. The fuel tank is full [messages are sent from originator], the fuel line to the engine is full [message path is traceable], but the engine won’t process the fuel. When you ask for help from the engine integrators they blame the fuel line.

The engine is the mechanism that makes a car move in a similar way that a messaging platform makes software components work together.

The point of the analogy is to remind architects that in the environments where they are constrained by organization’s enterprise architecture the communication patterns and related infrastructure that glues their application may already be predefined. No matter how good the infrastructure products may be, blindly assuming that the people operating the infrastructure are able to configure it for your needs is a recipe for disaster. This is especially true for quality attributes of a system that require high volume of transactions.

In environments where you cannot control the communication infrastructure always design with a backup in mind.

Firebrand Architect on duty: CK

EA pillars - a view

Enterprise Architecture is probably one of the most overloaded technical terms. There are many groups wrestling for control of the definition and its associated taxonomy. This of course causes architectural mismatch between systems, concepts, departments, and organizations.

The following post by Paul T. Preiss, President of IASA, calls for examination of the essence of certain architecture specialties (software, infrastructure, and business) to derive an objective list of knowledge foundation blocks. This post is a great start to future collaborative work on building bridges between different frameworks and methodologies.