Notes for Ch. 3 of "Beyond Software Architecture"

Both marketecture and tarchitecture represent part of the whole picture of a system and they must work together to achieve business objectives. Sometimes what is built from a technical point of view may look quite naïve but it can be a very successful architecture from a business point of view. Just like the example "Boolean flags" in the book, it is a potentially problematic way but it is good for business people to understand.

Normally in the start of a development cycle, everything begins with the problem domain, the technology, and the –bilities that wanted from the business side. The problem domain is where you find the actually requirements, the technology is where you look for proper technical foundations to implement the solution, and the –bilities is where people discuss non-functional requirements and give priorities. Here the priority is very important. People must set it up and agree upon it in the beginning. It is OK to change it later (but not so frequently) but every change will force the team to look back at what they have done and do certain adjustment.

In the software vendors' world, a successful marketecture normally means that you have to look into what the customers will need in the next 18 or 24 months rather than the current. And you always have to maintain this marketecture up-to-a-future-date continuously. Another important thing to do is to make sure that the tarchitecture agrees with the marketecture. Otherwise, there will be a major dis-continuity in the product life-cycles.

In a product development lifecycle, you always have to talk to people and get feedbacks. Sometimes the marketecture is used to talk to business people and the tarchitecture is used for talking with technology-related people or information source. One important thing is that, if there are changes or disagreements on the pictures, there must be a way to maintain the two pictures and let people agree on it.

One important usage of having the marketecture and tarchitecture is that they are the best models to talk to the project team and all the stakeholders. The project team should always unify these two "architectures" if there is any change to any of them. It is important to put the latest of these two models publicly available to the relevant parties of the project.

Normally it makes a good sense to start making the marketecture and tarchitecture using context diagrams. What is a context diagram? As I get from Wiki, "System Context Diagram (SCD) is the highest level view of a system, similar to Block Diagram, showing a (normally software-based) system as a whole and its inputs and outputs from/to external factors. SCDs are a type of Data Flow Diagram, and they should always be produced as DFDs. Context Diagrams show the interactions between a system and other actors with which the system is designed to face." SCD is very helpful in understanding the context of a system.