I'm curious how you guys would approach an EA program for a corporation that predominately buys software, rather than builds it.

Most of the "frameworks" out there, FEA, TOGAF, even Zachman tend to focus far more on the software development lifecycle and a degree of detail and customization that isn't always possible when you buy rather than build your software environment.

How do you guys do it? How does it work? Have you had luck integrating frameworks, taxonomies, artifact development processes, etc.. into that world?

Tia,

Josh

I know this post is old, but in the interests of getting a discussion going, here is one approach:

I have found that there must be a compelling reason to build instead of buy - namely the capability you are building is a core competence and/or market differentiator.

But buying should start with an architecture framework - you should ONLY consider products that fit in with your enterprise architecture: How do they separate concerns? How is monitoring managed? Are there components that can be used in multiple vertical businesses? etc. When you go through the exercise of mapping a product candidate to your enterprise architecture, you will uncover many of the implementation issues you would face. Generally, the better the fit, the fewer "surprises".

So yes, your enterprise architecture (and the Framework you have chosen to base it upon) is just as relevant to buy as build.

Regards,
Fred