Architecture on the Product Side

In an previous post, I wrote about the difference between the application of technology to the building of products, vs the application of technology in running the business. They are pretty different animals, if nothing else because of the way they are deployed.

So, I get to wonder what the head of architecture for the product side of one of these companies does. I can take one of the Architecture frameworks and apply it – but to what? Individual products (each with own P&L, development teams, practices, degrees of product maturity)? Across the whole product organization itself, so that we can begin to standardize/use same services across the product suites. When the products can be deployed in several ways (in house operated and sold as ASP), on-premise at the customer, on=premise hosted by one customer and used by another,…So as the products are deployed we have to think about the how the platform affinities work.

The customers want to customize the way the work is performed using the products/services that they have bought. So somehow we have to think of ripping the process logic out of fixed applications.

There are cross product dependencies as well. So sometimes we have to rip code out of one product and insert it into another.

Oh and the up time for these products must be in the 99.999 range – the products handle very time/life critical activities.

And finally a legacy that dates back a long way – pretty much bulletproof, but definitely has its own way of presenting itself to the world.

This Architect's world feels very different to me than the "traditional" EA world where the need to build for wide deployment and customization is less important.

Any thoughts anyone?

C