BA372 - Tarchitecture - Marketecture

• "Marketing & technical aspects of the system work together to achieve business objectives." (p. 51).
• Tarchitect: traditional software architect or chief technologist --> developer frame of mind.
  
• Marketect: manager responsible for the system --> business frame of mind.
• Example: $50,000 Boolean Flag (p. 52).

• Example: free vs. nonfree (enterprise) version.
  

• Technical and market forces in solution development (p. 53):
• Problem domain:
• Central force.
• Suggests patterns.
• Tarchitect & marketect MUST have a thorough understanding of the problem domain.
• Requirements gathering / needs analysis.
• Business process modeling.
• Hohmann's requirements for a tarchitect:
• Key member in system development.
• Key member of architecture change team.
• Deep understanding of the problem domain.

• Problem: Why is the consulting/software development model (e.g., WASY, Stockamp) so successful?
  

• 'Illities': quality and product attributes ascribed to the architecture:
• Manifest at runtime; e.g., usability, scalability, stability.
  
• Not manifest at runtime; e.g., testability, portability, modularity.
• Technical & market requirements for illities do not always track: --> compromises are often needed:
• "compromises have their most negative effect in the next release" (p. 55).

• Technology base: "technology base must support the tarchitecture as motivated by the problem domain."  (p. 57).
• RSS-Lisp vs. Riverware C++.

• HTTP / XML / SOAP --> Web services --> Service-Oriented Architectures (SOA).

• Leading vs. bleeding edge.
  

• Beware of resumé-driven design.

• Where tarchitecture & marketecture meet:
• "Create results now while working in the long run":
• Don't develop if you do not have the resources for maintenance.
• Consider specific needs as instances of a class of needs.

• Example: Support of tabular data and mathematical expressions in TeachEngineering.

• Harness feedback:
• User conferences/groups.
• Advisory groups.
• Customer feedback and feature requests.

• Eric Raymond (Cathedral & the Bazaar): "Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging."

• Have people know their roles:
• Some things developers should never do (p. 60).

• Working in clarity:
• Tarchitects and marketects both understand problem domain.
• A marketect not understanding the problem domain is worse than a tarchitect not understanding it.

• Agree on common means of documentation and representation; e.g. language; set of terms.
• Mutual respect for each other's responsibilities and accountabilities.
• Make the data available; transparency.