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).
- 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.
- 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."
- Include developers in the feedback loop
- Direct access to customers improves their ability to create
a product the customer really wants.
- 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.
