|
Diagram
|
|
|
|
|
Title
|
|
|
Openness
|
|
Building Architecture
|
|
|
While pluralism or a state of many values makes consensus difficult, this can be overcome through an attitude of openness.
|
|
Architecture Intensive Disciplines
|
|
|
The "open source" movement or the principle of "shared ownership" of source code is a postmodern reaction to proprietory and closed systems. Source code ownership and exposure is a key issue for debate. On the one hand, security is paramount. Auditors will seek a separation of domains, roles and ensuring compliance to change management systems. On the other hand, shared ownership can be a team value. One perspective is based on "mistrust" and the other on "trust". Openness involves value systems which place great emphasis on human interaction. It is a statement that says the value is in the people rather than the source code. The internet was based on a simple and open HTML standard. File sources could be viewed through the browser. But openness, while ideal is not always practical. With increasing security issues and complexity, there is an increasing trend in web based development to use binary and compiled components that hide the source code logic.
|
|
Case Study A: Large Corporate IT
|
|
|
|
|
|
The "separation of domains" involved restrictions on who had access to development, integration and production domains. The majority of programmers were not comfortable with the notion that someone else could change their code before being put into production. Not everyone subscribed to a shared value that all source code should appear to be written as one. Coding was considered by many as an individual craft. Most architects seek conformity and apply automation or forward engineering of code where possible to avoid inconsistencies. The lack of consistency was a problem. There were those that felt this issue could be addressed through interchange standards and XML. But while interchange standards does resolve some of the issues, it does not address problems inherent in design. In a large organisation, consensus can't always be reached and implementation of some designs are forced by creating closed and restricted domains.
|
|
Case Study B: Small Commercial Team
|
|
|
|
|
|
The configuration controller manages the source code changes, builds and releases of the product. This is a role any technical person can fulfill. It is usually done through pair programming. The person who has developed a module and passed unit testing, will seek a partner to integrate it into the master copy. This was the "practice". It was stated as a "principle" up front that everyone has access to the code and can make changes. This was possible because of the team had decided on the "value" of shared ownership of code and adherence to oneness of code (that the source code look as if it were written by one person). Refactoring was a process to improve code and when the team decided on a refactoring exercise, either everyone would be involved or at least everyone agreed on what was being done - no closed doors or sneaking around to "fix" code.
|
|
|
