How to Create Product Maps

In some of our articles here you've probably noticed various types of diagrams thrown in as examples. All of these come from real-world project related exercises. When an IT Architect produces a diagram we generally refer to it as an "Artifact." While this may sound like we're talking about relics, it is simply an odd naming convention of our industry. An Artifact can be any sort of deliverable; a Word doc, a spreadsheet or perhaps even a file associated with a specific EA software environment. The common thread across any of these deliverable formats is the notion that the Artifact must be more or focused on one topic (sometimes this isn't the case, but most times it is).

One particularly interesting type of Artifact is the "Product Map." So what exactly is a Product Map? Well, there are two distinct types of Product Map and there are only tangentially related.

Type 1 - A Map showing the relationship between products, comparison of products or elements of a complex product suite.
Type 2 - A Map showing product components and their evolution (past and future roadmap).

So, you might be asking yourself, why is such a thing necessary and what does this have to do with IT Architecture?

Why We Need Product Maps
Believe it or not, the companies that produce these products don't always do a good job at depicting the composition of their products or the relationships between products. And, if we extend our view to a large heterogeneous enterprise environment, there is little incentive for a product company to spend too much time thinking about how their product might relate to their competitors or other products which don't seem to be related to the function their solution performs.

There are a variety of situations where product maps might be needed; they include:

• Representation of "As-Is" architecture. Product maps would be drill-down artifacts that illustrate more of a physical view.
• Product Evaluation and Source Selection efforts.
• Transition Planning exercise (in other words, being able to illustrate migration of one set of tools to another).
• Enterprise Integration Design. Getting different product sets to work with one another or even send messages to other can be challenging. 

The product map differs from other types of architecture artifact in that it depicts some aspect of a larger solution from a specific product perspective or context. The way we might highlight an identity management solution in an agnostic logical view could look far different than a product specific IAM stack (see the diagram below).


IT Architecture & Product Integration 
So how does the IT Architect facilitate Product Integration? Well, at its core this represents a problem solving exercise; in fact one of the more complex ones that the majority of enterprise tend to face on a routine basis. One might think that since so many similar organizations face this type of challenge that there would be a wider set of industry standard approaches to this - but this isn't the case. While many enterprises share the same tools, the exact configuration and inventory will almost certainly vary widely. And as most of you know, even moving from one version of a product to the next can be major hassle in itself.

The IT Architect takes this problem and turns into a design exercise. This begins by documenting all of the pertinent aspects surrounding the product:

• Key features
• Standards support
• Administrative and management considerations
• Customization support (languages, configuration)
• Inter-operability mechanisms (database connectivity, APIs, etc.)
• Version control and version specific variations of the above
• Overlap of features or deprecation of features (either between different versions or options of one product or competing products).

The Architect then defines all of the related design decisions based on a larger set of expectations for how the product might be used. Some products of course merely provide a platform for even more custom development (for example an DBMS like Oracle) - with the larger Oracle stack then there are opportunities for both custom and packaged analytics. The determination as to whether to go one way or the based upon what products are already in the inventory or which ones ought to be included near-term and long-term is a classic example of contextual product mapping.

An example of a product map of a suite of related security products

IT Architecture & Product Design 

Can IT Architecture support product design or development? In a word yes. This represents Type 2 Product Mapping. For example, what if you had an excellent idea for a new mobile app and wanted to manage it in some start-up scenario? There are of course various business considerations for a typical start up, but just as important is management of the product itself and that should start with its architecture.

The architecture will drive many key decisions related to the product's introduction and evolution including:

• Determination of what technologies should be harnessed to actualize the product.
• Development of the product roadmap (including conditional variations based upon contingencies or opportunities).
• Determination of key systems design options and solutions.
• Governance of the product (and all its related infrastructure and code) across its lifecycle.
• Determination of product synergies in the market (the larger ecosystem of related solutions).

We will look at Architecture and Product Design in greater depth in upcoming posts here on the IT Architecture Journal.

Copyright 2014,  Stephen Lahanas

#ITarchitectureJournal
#StephenLahanas
#Semantech-Inc