Stakeholders Defined

This post regarding stakeholders is again inspired by and contains excerpts from the book Software Systems Architecture: Working with Stakeholders using Viewpoints and Perspectives.

Software systems are not just used, they have to be built and tested, operated, repaired and of course paid for. Each of these activities involves a number of people, each with their own requirements and interests. The people are collectively referred to as stakeholders. Understanding the role of each stakeholder is fundamental to understanding the role of the architect in the development process.

The IEEE Standard 1471 on architecture description defines a stakeholder as a person, group, or entity with an interest of concern about the realization of a system's architecture.

I personally have a checklist I like to run through when a new project involving my development team is initiated. I like to make sure that all the necessary teams, such as support or infrastructure, are correctly engaged prior to implementation. From the perspective of a software architect, Nick Rozanski and Eoin Woods succinctly classify these stakeholders according to their roles and concerns as below.

 

Stakeholder	Role
Acquirers	Oversee the procurement of the system or product. In my experience, these stakeholders are often referred to as 'the business' and are usually the most important stakeholders, providing or authorizing funding. Their goals are usually value for money and efficient expenditure of resources during delivery and operation.
Assessors	Oversee the system's conformance to standards and legal regulation.
Communicators	Explain the system to other stakeholders via documentation and training materials. Analysts communicate the requirements to the developers whilst technical authors create manuals for the users and administrators.
Developers	Construct and deploy the system from specifications or lead the teams that do this.
Maintainers	Manage the evolution of the system once it is operational Their main concerns focus on documentation, instrumentation or change control. In my experience this is often the responsibility of the development team.
Suppliers	Build and supply the hardware and infrastructure on which the system will run.
Support	Provide support to users for the product or system when it is running.
System Administrators	Run the system once it is deployed. They focus on concerns such as monitoring, business continuity and disaster recovery and scalability.
Testers	Test the system to ensure that is suitable for use. Testers act as the conscience of the development team, systematically testing the system in order to establish whether it it is suitable for deployment and use. Unlike developers, testers do not have a sense of ownership of the implementation and with their specialist knowledge and experience means they can perform a more thorough and objective job of evaluating the system than other stakeholders.
Users	Define the system's functionality and ultimately make use of it.

Most development projects should include representatives from most if not all of these stakeholder groups though their importance varies from project to project. I totally agree with authors when they state that not considering a view from each class of stakeholder will lead to problems in the future.

Software Architecture Concepts

I'm currently reading Software Systems Architecture: Working with Stakeholders using Viewpoints and Perspectives. I already think this is a book I should have read years ago! In chapter 2, the authors, Nick Rozanski and Eoin Woods break down the widely accepted definition of software architecture by the Software Engineering Institute (SEI) at Carnegie-Mellon University in Pittsburg:

The architecture of a software intensive system is the
structure or structures of the system, which compromise software elements, the externally visible properties of those elements, and the the relationships
amongst them.

I have seen this definition quoted many times but rarely examined in closer detail. Rozanski and Woods do however analyse structures and externally visible properties.

They state that there are two types of system structure, static and dynamic. Static structures of a software system define its internal design-time elements and their arrangement whilst dynamic structures of software system define it's runtime elements and their interactions.

Externally visible properties also manifest themselves in two ways, the externally visible behavior (what the system does) and quality properties (how the system does it). The externally visible behavior of a software system defines the functional interactions between the system and it's environment. A quality property is a nonfunctional property of a system such as performance, security, or scalability. These are commonly referred to as the "ilities".

So the key take away is that it's the role of the architect to derive the static and dynamic structures for each candidate architecture and understand the extent to which they exhibit the required behaviors and quality properties.

 

Leadership Qualities

This excellent list of leadership qualities is taken from the 'Aspiring Architects' webcast series by Mohammad Akif.

• Ask thought-provoking questions that result in actionable technological patterns or solutions
• Actively mentor others
• Provide thought leadership by enabling others to see things from a different of better perspective
• Influence decision makers
• Champion structure, process, best practices and standards
• Promote the capture and reuse of intellectual property
• Effectively build individual partnerships and organizational networks

The valuable qualities below were also mentioned during the series. 

• Practice diplomacy, negotiating and compromising
• Manage and clarify expectations

Favourite Archipedia Entries

Another Useless Acronym (AUA)
Another Useless Acronym (AUA) or what can happen when partially formed new architectural ideas emerge.

Automagically
When something has the capability to perform an indispensable task that no one thought was even possible.

Bottom Up Design
Bottom up design, as with its counterpart Top down design, are strategies of information processing.
In the Bottom up design approach, individual parts of a system are designed in detail and the design parts are then linked together to form larger components, which are then in turn linked until a complete system is formed. Often the bottom up approach assumes that all facts are known up front as the detailed parts are designed.

In the Top down design approach to modeling an overview of the system is made, without going into detail and each part of the system is then refined by designing it in more detail. Each new part may then can be refined again until the entire specification is detailed enough. Often the top down approach is used when not all facts or constraints are known about a design.

Choreography
Formally a choreography can be defined as a declaration of the activities within collaboration and the sequencing rules and dependencies between these activities.

Often these days, when people talk about the architecture of business services there are 2 related concepts which often come up - choreography and orchestration.

The difference between the two is easy to remember depending on your design perspective. Seen from a publicly observable view of a service, choreography is the description of how to interact with the service to consume its functionality. Seen from the same publicly observable viewpoint, orchestration is how service functionality is achieved ("within" a service) by aggregating some service logic and very possibly other Web services.

Cycles
Time, resource and effort that ought not to be wasted. "Let's not waste any cycles on something that doesn't matter."

A portion of one's capacity to perform work. "Do you have any cycles to burn on the ...".

Drinking from the Fire Hose
Having an overwhelming amount of information thrown at you, commonly at the start of a new job or project.

Ivory Tower Architecture
An architecture developed in isolation from the developers, or teams of developers, responsible for following it.

KISS
Keep It Simple Stupid is a design philosophy that states simplicity lasts and simplicty is needed to properly convey any ideas. Simplicity is the absence of unnecessary elements. Simplicity isn't a design style, but a perspective on design and an approach which often creates the most usable and beautiful results.

Low Hanging Fruit
Management expression for the most available and easy to accomplish objectives.

Operational Requirements
A category of requirements that describe the operational expectations for a system, such as availability, security, performance, scalability, manageability, interoperability, and reliability.

These requirements are distinct from the functional requirements that detail the business functions that the system performs (e.g., calculating the total bill for a shopping basket).

Also called "non-functional requirements"; also called "non-behavioral requirements". Closely related to the concepts "aspects" and "qualities".

Portfolio Management
Portfolio management is a function of IT Governance (which makes it fair game for enterprise architecture). The portfolios in question typically include both the application portfolio and the service portfolio. The focuses of portfolio management typically include:

• Redundancy analysis -- avoiding having (and paying for and maintaining) multiple artifacts that perform essentially the same function;
• Gap analysis -- identifying opportunities to improve processes through better automation;
  Manageability -- standardization of management interfaces, including vendor selection based on adherence to standard metaphors for management;
• Cost rationalization -- analysis of the true ROI of automation and elimination of non-cost-effective systems;
• Server consolidation -- reduction of the number of systems being supported, often by standardizing to a small set of server operating systems.
  

Project Stakeholder
Project stakeholders are any of the interested parties in a given development project. Typical examples of stakeholders include:

• Business process owner -- the person responsible for the profit-and-loss of the business process being supported;
• End user -- the people who will actually use the system under development;
• Operations -- the people with the pagers whose sleep is at risk;
• Executive sponsor -- the person who can light a fire under non-responsive stakeholders;

As well as architect, project management, developers, and testers, naturally.

Quality
The term "quality" is used in two distinct ways in systems architecture. The first usage is to define a class of common properties that must be addressd by any system. These "qualities" include:

• Security
• Manageability
• Availability
• Reliability
• Scalability

These system qualities may be cross-cutting concerns for the system, and hence may be best addressed using some form of aspect-oriented programming.

The second usage is closer to the typical English-language usage: how well the system meets the requirements that were defined for it. For a more complete look at this meaning, please see quality management.

Rat Holing
A slang term for a discussion that spirals away from the topic of the meeting.

Return on Investment (ROI)
A calculation of the economic value being derived from a system as compared to its costs.
When embarking on a new initiative, it is common to predict an ROI for the system under consideration. This calculation needs to look at both development and ongoing operational costs for the system. The calculation is used as a justification for moving ahead with the project.
Once a system is in operation, ROI calculations ignore the "sunk costs" of development, and only compares the value being realized with the ongoing costs (which are more fully understood once the system is in operation than it was when the project was being envisioned). This calculation may, however, consider depreciation of assets that support the system, such as computers and storage devices.

Taxonomy
A taxonomy is a system of classification and with context, such as enterprise or folks or something else, a taxonomy is a description of the context.

Time-to-Value
Time-to-value is the elapsed time between the commitment to a project and the perceived realization of value from the investment. Project planners who stress short time-to-value seek to maintain excitement and emotional engagement around the project. Long lags between project inception and perceived first value can cause business process owners to disengage from and deprioritize the project.

Waterfall
Waterfall processes proceed through a unidirectional sequence of discreet steps.

The term is principally applied to a software development methodology that promotes a sequence along theses lines:

• Conceptualization -- business process owners identify a business need and develop a conceptual model for a solution;
• Requirements definition -- solutions architects work with business process owners to produce a detailed functional specification;
• Project definition -- the functional specification is used to generate a set of work items for development;
• Development -- Developers and test engineers produce and validate a set of deliverables in accordance with the project plan;
• Acceptance testing -- the resulting system is tested for compliance with the functional requirements;
• Deployment -- the system is put into production.

Critics of waterfall methodologies question how effectively the requirements for a software system can be understood "up front". They promote more agile approaches to software development.