BA372 — Tarchitecture — Marketecture
- "Marketing and technical
aspects of the system work together to achieve business objectives." (p. 51)
traditional software architect or chief technologist —> developer, software engineer frame-of-mind (aka TMitTB)
manager responsible for the system's role in the business/organization —> business frame-of-mind.
- Hohmann's point: these two sets of objectives often conflict with each other (at least in the short run)
- Example: "$50,000 boolean flag" (p. 52):
- Example: free vs. nonfree (enterprise) version.
- Spend time reengineering an application to use less memory or buy more memory?
- Build components in house or outsource them?
- Technical and market 'forces' in solution development (p. 53):
- Core technologies, competitive landscapes and target markets are all 'forces' which are in permanent flux;
e.g., Industry 4.0:
- super lean / just-in-time,
- individualized manufacturing; e.g., Harley-Davidson's paint street can change paint colors in < 30 seconds.
Different motorcycle models are interspersed on the assembly line,
- same-day delivery,
- Problem domain; e.g., credit card processing, water resources simulation,
airline routing, airport passenger routing, on-line book selling, inventory management, etc.:
- Have established one or just a few architectural patterns.
- Both tarchitects and marketects MUST have a thorough understanding of the problem domain:
- Requirements gathering / needs analysis.
- Business process modeling.
- Hohmann's requirements for a tarchitect:
- Deep understanding of the problem domain.
- Must have gone through several full release cycles of (the) product(s).
- Problem: Why is
the (domain) consulting/software development model so successful?
quality and product attributes ascribed to the architecture:
- Manifest 'at run time;' i.e., when using; e.g., usability, scalability, stability/reliability.
- Not manifest at run time; e.g., portability, modifiability, extensibility, etc.
- Technical and market requirements for ilities do not
always track: —> compromises are often needed:
- Technology base:
base must support the tarchitecture as motivated by the problem domain."
- RSS-Lisp vs. Riverware
- HTTP / XML / SOAP / JSON —> Web services —> Service-Oriented
- Leading vs. bleeding edge. (Sullivan/Beach (working paper): HRO workers; e.g., military / power / aviation industry: "not
infatuated with new technology...")
- Beware of resumé-driven design.
- Where tarchitecture & marketecture meet:
- "Create results now while working in the long run" (The market wants (or can support) it now, but architecture is
- "World-class marketects approach their task from a perspective of time that easily
distinguishes them from those less skilled. Instead of listening to what
customers want now (easy), they extrapolate multiple streams of data, including
current requests, to envision what customers will want 18 to 24 months into the
future (hard)." (p.57/58)
- Example: support of tabular data and mathematical
- "Envisioning the future on behalf of customers, even when they can't
articulate what they want, is the world-class marketect's key distinguishing feature." (p.58)
- Cummings in 'Jack of Two Trades' (Computerworld, Apr. 2013): "We need IT to be the kind of organization that,
if you're on the business side, we know the (business) problem before you know it."
- "Like their marketect counterparts, world-class tarchitects also extrapolate multiple
streams of data and envision a technological future that provides superior value to their
- Example: If my marketect expects steep increases in system use in a year or two, should I use Access as my database?
If so, I better write my database creation scripts in standard SQL.
- In other words: !!! Consider specific needs as instances of a (more general) class of extrapolated needs !!!
- In yet other words: !!! Every time you recognize a specific problem as an instance of a class of problems, you create
the opportunity to not only solve the specific problem (kluge), but also similar future problems) !!!
- In still other words: !!! Generalize !!!
- However; be careful not to overdue this. Taken to the extreme, any particular case is a case of 'something,'
yet designing a system which can handle 'anything' is doomed for both failure to finish and extreme complexity.
- Harness feedback:
- Have people know their roles:
- Some things tarchitects and marketects should never do (p. 60):
- Make promises ($$, delivery schedules, etc.) to (potential) customers without first checking back.
- Preclude/exclude opportunities without first checking back.
- Lie or gamble; being considered uncertain is less harmful than being considered a liar.
- 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.