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 (e.g., 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)
- project management triangle:
- Example: free vs. nonfree (enterprise) version; e.g., "$50,000 boolean flag" (p. 52).
- Spend time reengineering an application to use less memory or buy more memory?
- Spend time engineering a 3NF relational schema or accept duplications of data?
- 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).
- Explains why the (domain) consulting/software development model is so successful.
- Technology base: "technology base must support the tarchitecture as motivated by the problem domain." (p. 57).
- RSS-Lisp vs. Riverware C++.
- 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)
- "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 knows the (business) problem before they 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 (kludge), 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 and everything' 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.
- Problem: Why is a marketect not understanding the problem domain 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.