Originally published March 3, 2018

Republished September 10, 2024

“If you think good architecture is expensive, try bad architecture” – Brian Foote – and Joseph Yoder

In a blog post I read recently, they referred to product market fit. Then in a podcast that I don’t remember they mentioned the idea of marketecture. The problem that struck me, was their definition of Marketecture did not fit what I remembered.

That post about the bookshelf, remember? Well I have the original book on the shelf where Luke Hohmann coined the term. In the book, Beyond Software Architecture he defines the new words, markitecture, and tarchitecture. He combines the term market and technology with architecture.

The way others were using the words just did not match the way I remembered the book. I know I loaned the book to a manager at a company I left about 11 years ago. So it has been a while since I read it. After two moves it is still on the shelf, so I grabbed it and read the relevant sections. Yep, they had it a little wrong. I also remembered it a little wrong, so we can call that even. The Wikipedia page on Markitecture says:

Marchitecture (or Marketecture) is a portmanteau of the words marketing and architecture. The term is applied to any form of electronic architecture perceived to have been produced purely for marketing reasons. It may be used by a vendor to place itself in such a way as to promote all their strongest abilities whilst simultaneously masking their weaknesses.

Sounds negative doesn’t it? Building things or making changed purely for marketing. Not just for marketing, but to mask weaknesses.

Wait, all the product development and software you, me, and everyone writes is for a market. You always have a customer, even if that is the teaching assistant grading your assignments, or for yourself (maybe then we could call it mastertecture? Ewww.) So changes made for marketing reasons are good and proper. If you fix an error that looses the customers data, making the customer happier and getting more customers is not a bad thing. Yo u and I, as mature developers who know that the market is the reason we are not out digging a ditch as it snows outside my window can reject the Wikipedia version.

In Beyond Software Architecture (paraphrased from page 51) he defines the terms as:

Marketecture: is the business perspective of the system. It embodies the complete business model including the licensing and selling, value poropsitions, technical details relevant to the customer,  data sheets, compettivtive differentiation, brand, and the mental model marketing is attempting to create for the customer, and the system’s specific business objectives.

Tarchitecture is the way developers think of a system’s architecture. For software systems it encompasses sybsystems, interfaces, … threading models, and so forth.

Marketecture is the marketing, now and going forward. Tarchitecture is the technical details of how the product works. To make it concrete and easy to understand, marketecture is the roadmap, tarcitecture is the code. Very different than the Wikipedia definition.

And Product Market Fit?

Will the customer buy the product? If they will we have product market fit. The company has designed features into a product that have value to a customer. Not just one customer, but a marketplace with enough paying customers to make a business an ongoing concern.

All the Lean Startup and blog posts from Steve Blank are talking about is testing the marketecture. Do we have a market now and going forward?

The basic idea of the Lean methodology is use a minimum viable product to explore the market.

Your Minimum Viable Product is not your target architecture

Sounds obvious, but it is not. The MVP can be you working like mad in the background to simulate the automated process. If people will buy it, then you can build it. It can be a simple static landing page, and Sumo email templates. Not the way you are going to scale, but it gets the job done.

This is a place I get hung up. The technical architecture is my favorite mental playground. All my ideas will be beautifully architected applications with no need for maintenance or support. New features practically write themselves. This is really had to do on the first go, so the ideas remain in my head.

Keep it simple, test the market, then dream big dreams of marketing roadmaps, scalable web apps, and cash in the bank.

1. MVP
2. Product market fit
3. Marketecture
4. Tarchitecture .

One architecture to rule them all

The two architectures are really the heads and tails of one coin. Why do we care?

When surveyed one of the top reasons for startup failure is listed as “premature scaling”.  The technical architecture was ahead of the marketing. A simple mismatch of the two architectures. How about this one, no market need? Again a technology looking for a market.

Anyone remember the Twitter fail whale? The technology did not keep pace with the market. The concept of technical debt is really a tarchitecture failure.

A failure of ether is a failure of the company. How do we keep them balanced? A very hard question.

As a technologist, I can only speak to the technical details.

First, know the customer, and know the market. Sometimes a technical background lets you see market trends sooner. You should definitely know the road-map for your product. You have one, right?

Second, use the principles of DRY, and SOLID in your code. If you know the road-map, you know the features (approximately) you will need. At the very least you should have some idea of the number of customers or units needed. Can you scale? Keep the technical debt in check.

Third, be flexible. Maybe you won’t have to scale. Maybe it will be fire drills every single day. You can not be in love with the technological Taj Mahal you have built. When the market changes, it will have to change.

One last thing. Read the book. It is a good one.