Product Architecture from a software perspective

I recently worked with an Enterprise Architecture team to develop a "holistic product architecture" to unify the design of the company's products.

When we began the effort, we quite frankly were not sure what "product architecture" meant, so with the help of Google I did some research and found the following:

An architecture has a two-part definition:

• The first part of an architecture is a decomposition of the overall functionality of a product into a set of defined functions and the component parts of the product that are going to provide those functions.

• The second part of the definition is the specification of the interface between the components, in other words, how components are going to interact together in the product as a system.

The specification of the interface is critical to the design of flexible architectures that allow you to substitute component variations within a product without having to make adjustments in other components."

- Ron Sanchez : Professor of Strategy and Technology Management at IMD

Ron also points out that product architecture is about more than creating a single product, it is about creating a product platform on which an entire product family can be based.

I like this definition for product architecture, but we need to clarify what we mean by "decomposition of the overall functionality".

A product's architecture straddles the boundaries between business and technical concerns, but it belongs to the business owner (typically a Product Manager). The functional components that the business is concerned with are components that can be assembled to provide new business functionality (new products).

With this business focus in mind, consider the popular Model-View-Controller (MVC) software architecture: Is MVC the basis for a product architecture?

MVC is a modular architecture that separates an application's data model, user interface, and control logic into distinct components so that modifications to one component will have minimal impact on the others. MVC is a very successful architecture, and one which every software architect should master... but it is not a meaningful basis for a product architecture for one simple reason: The component breakdown in MVC is not focused on business functionality.

In contrast to MVC; the component breakdown in Service Oriented Architecture (SOA) is focused on business functionality. SOA is a modular architecture in which applications are composed from distinct business-relevant services (hence the term composite application).

Let me hasten to explain myself... SOA is not by itself a product architecture any more than MVC is, but SOA is a useful tool for considering how an architectural model for a product family should be described.

Most software products automate business processes. The architecture of the product provides the framework for implementing the business processes. If the mapping from the process steps to the architectural components that implement those steps is clean, then the business owners will probably understand (and appreciate) the architecture.

So back to the phrase: "decomposition of the overall functionality"...
We can expand this to: decomposition of the overall functionality into distinct, business-relevant functions...

If you start with the right set of business-relevant functions, the resultant products will likely be easier to maintain and to adapt in the future.

I know, business-relevant is not exactly a precise term either... but the only way to pin that one down is for you to talk with your business owner. Start talking ;-)

---

(Cross posted at my java.net blog)