The Patterns: Patron as Sponsor and User. Defining the patron as customer.

Diagram
Title
	Patron as Sponsor and User
Building Architecture
	The patron may or may not represent both sponsor and user. In the case of the St Louis Pruitt-Igoe Projects which were demolished in 1972, the sponsor was the local housing authorities and the users were the workers who rejected. The demolishing of the buildings at the request of the workers for whom it was intended, illustrates the importance of considering the people for whom our designs are intended.
Architecture Intensive Disciplines
	A patron in software or systems architecture can represent the business sponsor and the user community. The sponsor seeks adherence to a vision whereas the primary concern of users is functionality or enablement. To a business, integrity of information for reporting purposes is paramount. This is why the integrity of business rules is essential in data architecture and data programming. Users also play a critical role in defining acceptance and the success of software development projects.
Case Study A: Large Corporate IT
	In previous years, each business unit was given autonomy to outsource end user computing requirements. Some core systems were outsourced. The application development manager had set an objective to bring back some of the work that was outsourced and service these in-house. The re-development of one of the core systems from the mainframe to a web application was seen as a platform for this drive. The aim was to satisfy both the business management as sponsor and the business users. This pattern was applicable and represents one of the key drivers in the case study. While there were challenges to overcome, the success of the first phases of the project allowed us to "tender" for the job of bringing other systems in-house. It was proven that better integration and compliance to standards could be achieved through "building" than "buying" but the policy had traditionally been that development was only an alternative if an application could not be integrated into SAP or "bought". The cost of upgrading SAP because of building custom "bolt-ons" and the growing capabilities of internet based technologies made the "build" option increasingly appealing. In this organisation it is thus difficult to simply define the patron as a customer. In many ways there were a number of people who were patron to the architecture. Those managers who saw themselves as architects and those who championed specific solutions were the visionaries. It is their visions that architecture serves. It is also the designers of the business process, the funders of the project and the business sponsors who are patrons. The project managers who control the project also have a stake in the patronage. Finally, there are the user experts and user representatives who can accept or reject the product of design or construction. Business sponsors as patrons had specific requirements for the architecture. They required data and information integrity. The accuracy of the data was paramount. This required a good data architecture and in turn good business analysis. Business analysts are sometimes too focused on the details of the problem domain to architect a technical solution. The role of the business architect was established to ensure architectural integrity between business requirements and data architecture - entities, business data objects, databases and information flow. The Business Architect could best serve the needs of architecting a system with business analysts in the business units. In this case the business analyst represented the business sponsor as patron. The Business Architect/s was mentored on class diagrams, entity relationship diagrams, use case diagrams and activity diagrams. The role of the Application Architect/s was to design modular applications specific to user requirements. This was done through prototyping and modeling. The Application Architect was mentored on use case diagrams, class diagrams and sequence diagrams. It was felt that by identifying architectural roles and by addressing different aspects of the "patron", that we could resolve some of the disparities in design thinking. In many ways this is also the approach taken by Enterprise Architects using the Zachmann Frameworks. It also reflects the diverse set of Architects in the Rational Unified Process.
Case Study B: Small Commercial Team
	Only part of the customer base was made up of corporate institutions. In many cases, the software was operated as a standalone and the patron or customer was both sponsor and user. As indicated in previous patterns the lack of an on-site customer or a customer as a member of the team - was a major shortcoming. The business analyst and user support (help desk) conveyed the customer view.

Page 38