Offshore Management Framework: The key to managing outsourced IT projects across time, distance and cultures.

« Offshoring BoP and Tandoori Nights in Texas | Main | Thoughts on Web 2.0 and Enterprise 2.0: What does it mean to you and me? »

Can your offshore vendor’s Marchitecture help you?

During the past couple of weeks, I was in our Plano, Texas office interacting with fellow architects and academics participating in the Infosys CTO “Enterprise Architect” workshop. The myriad topics covered included aspects of technology management, generating animated discussion among participants. However, a self deprecating remark by a fellow Principal generated more than a few chuckles when he responded to the ability of architects to also market some of the solutions and ideas by stating “don’t we dream up marchitecture all the time?” After the guffaws over the remark subsided, I did a quick bit of googling and discovered that the term is used in the industry more than we realize. Peter Abrahams, uses the term in his essay to describe how “a Marchitecture is an architecture produced for marketing reasons, normally by a vendor. It is designed to put the vendor in the best possible light by emphasising the positive as well as hiding the negative.”

Luke Hohmann, in his writeup takes a slightly different view stating “Marketecture is the business perspective of the system's architecture. It embodies the complete business model, including the licensing and selling models, value propositions, technical details relevant to the customer, data sheets, competitive differentiation, brand elements, the mental model marketing is attempting to create for the customer, and the system's specific business objectives. Marketecture includes—as a necessary component for shared collaboration between the marketects, tarchitects, and developers—descriptions of functionality that are commonly included in marketing requirements documents (MRDs), use cases, and so forth."

Whether done to articulate the business purpose or to purely aid in marketing, architects, especially those working for software service vendors invariably get involved in different facets of defining Marchitectures. : Much of such involvement is benign:  during business development (and pre-sales) activities that include making pitch to customers, responding to Request for Proposals (RFPs) etc. Marketectures are also frequently developed for trade events and to showcase the firm’s capabilities in certain technology areas.

The real danger is when the ‘marchitects,’ architects conceptualizing marketectures, start believing that their solutions can really solve all customers’ problems [….If the only tool one has is a hammer, then everything looks like a nail ...].

And to answer the question in the title of my blog: sure your vendor’s Marchitecture can help you. The checks-and-balances to get you – the customers’ – solution architect and stakeholder to ensure that your vendor and service provider moves beyond Marketecture is simple; Ask the right questions:  

  • Ask that the solution being architected fits your need (your specific requirements, and not of requirements ‘like yours’. The caveat is that you should have clearly defined requirements to begin with)
  • Ask for how the specifications of the architecture meet your Non Functional Requirements (of course, if you have overlooked defining the NFRs…it is going to be tougher)
  • And if I must add, caveat emptor.

Posted by Mohan Babu K. on November 13, 2007 2:55 AM |

TrackBack

TrackBack URL for this entry:
http://www.infosysblogs.com/apps/mt-tb.cgi/3059

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)

Please key in the two words you see in the box to validate your identity as an authentic user and reduce spam.