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

Technical and Business Architecture

If architecting was only about solving a technical problem, then this discipline would be strictly under the computer science domain. What makes software architecture a child of the software engineering domain is the fact that an effective solution needs to solve business problem or achieve a mission.

It’s clear that an architect has to work works very closely with all stakeholders in order to understand the root of the problem for which a solution has been envisioned. There are two core qualities that an architect must exhibit. First, an architect must have an implementable vision of the whole concept from start to finish (if you don’t who will?). Second, an architect must intelligently question the business problem that a customer is trying to solve. This is very important, because this will minimize the risk of the solution not fitting into the existing (or future) technical and business infrastructure.

In mature organizations both software architects and business analysts speak a common language and work jointly to make sure a solution supports a business problem. In other organizations the burden often falls on the software architect to make sure that a solution design exhibits conceptual integrity from the business point of view. It’s not uncommon to have a group of business stakeholders individually represent what they want to see come out of the solution. But someone (business architect role) has to take ownership of the discrete needs and integrate them together into a comprehensive plan. Not every software architect is capable of deriving the root cause of a problem, and that’s OK. But a mature software architect would know when to bring in help to enable him to design the right solution.

Due to constraints thorough analysis is not always possible. This is where an architect must make a judgment call and make progress based on the known factors. In such situations it’s imperative to document risks and limitations of the solution so that the final result is judged against this segment of time.

Constantin K.
Firebrand Architect™
www.SoftwareArchitectures.com

Selecting COTS software under pressure (Forrester and Gartner)

This happens on many projects: everyone agrees that the core of a solution (e.g. workflow engine) will be purchased instead of built from scratch. This is an absolutely rational decision for most enterprise applications. The next question is which vendor to select.

The rational approach is to identify the core functional requirements and key quality attributes that the solution must exhibit. This is an absolute must; because without understanding what you need you will not be able to objectively judge your options. The criteria on which you should evaluate you COTS software candidates must be granular and quantifiable to the degree that makes sense. Each criteria element needs to be weighed against all other chosen consideration elements so that all weights add to a whole. E.g. In case of workflow COTS software the number of concurrent workflow processes that the solution must support has to be at least 400 and this criterion has a 15% importance in relation to other selection elements.

The next step is to conduct evaluation of the market space for available vendor solutions. A number of solutions will not meet the top selected criteria based on the marketing information from the vendor, but few will emerge as potential candidates. Since COTS software will be an integral part of the solution a targeted proof of concept should be implemented and results judged against the established criteria. The outcome of the test along with other evaluation criteria is used to make an objective and rational decision.

If a decision on the COTS software absolutely has to be made in a period of time that doesn’t allow a proof of concept, then you should buy the intelligence from a third party that has done COTS software evaluation for you. Both Gartner (Magic Quadrant) and Forrester (The Forrester Wave) provide analysis of various COTS products that fulfill a particular segment of business applications (e.g. BPM tools). Each vendor solution is evaluated against a wide range of criteria. These reports provide very valuable insight, but without objectively understanding the needs of the solution you’re architecting it’s not possible to fully utilize the insight provided by a third party.

In general a Gartner, Forrester, or another 3^rd party report should be used in any COTS software evaluation whether you’re pressed for time or not.

Constantin K.
Firebrand Architect™
www.SoftwareArchitectures.com

Responsible Software Architecture

SoftwareArchitectures.com is propelling the concept of responsible software architecture. This concept is based on philosophy that every decision made by a software architect must be conscious and must be supported by a judicious decision making process that clearly demonstrates why the chosen design alternative was selected out of a range of other possibilities.

Every decision made by a software architect is made in some context at some snapshot of time. The context is defined through architect’s understanding of personal capabilities, requirements, constraints, financial resources, time, capability of the team, etc. The context changes over time, so it’s imperative to document the background against which a decision was made. When someone questions a design decision or suggests a better solution an architect must provide a scientific justification of his or her decision – without it architect’s credibility and the credibility of the solution may be compromised.

The concept of responsible software architecture is very powerful, but few architects live by it. Think about two or three most recent software architecture design documents that you reviewed. How many documents clearly explain the way key architectural decisions meet business drivers and why selected architectural approach is better than listed alternatives? Not every decision needs to be documented with an elaborative set of alternatives, but all key decisions need to be explained. Key decisions are architecturally significant choices that if changed have a profound impact on multiple quality attributes of a system.

A responsible software architect must sincerely believe that a business problem, and not technology, drives the solution. Technology may be the core vehicle for delivering the solution, but it’s not the driver – this is a paramount concept. Because technology is not the driver a responsible architect must be able to initially reason about a solution without technology specific terminology. The point here is that selection of a technology (platform, development tools, COTS software, etc.) is an architecturally significant decision that constraints the solution. An architect must be able to provide a judicious explanation as to why selected technology was chosen. Once that decision was made it’s only natural to think within the context of selected technology.

Some software architects have too much vested interest in a given technology so they only design solutions with that framework in mind. This clearly limits the range of solution alternatives, but it’s not as limiting as reusing the same architectural approach from project to project without justifying the reason for doing so. For example an architect who designed web based applications using MVC architectural style for the past four years may be inclined to use it on the next project even if a Front Controller style or an AJAX based pattern may be more appropriate. Similarly if an architect is used to a working with a process intense SDLC he or she may push for it without realizing that a new project requires agile JAD/RAD approach due to its research and development nature. The latter examples demonstrate the proverb: “When all you have is a hammer, then everything looks like a nail.” For an architect to be responsible he or she must question their decisions and make sure that appropriate audience is able to understand the reasoning behind the decisions.

SoftwareArchitectures.com is currently establishing a Center for Responsible Software Architecture. Join the discussion on responsible software architecture in a specially created forum. Each post will earn you a chance to win Evaluating Software Architectures: Methods and Case Studies book (through October 15 2007). Registration required to view and post.

Firebrand on duty: Constantin K.
www.SoftwareArchitectures.com