Showing posts from 2011

Possible Use Cases For Platform as a Service?

I am wondering if the following use cases qualify for being a first foray into Application Infrastructure Virtualization or more loosely Platform as a Service (PaaS)?

For instance, would I be able to deploy a shared global service that has a wide variety of consumers with different usage peaks?  These peaks could coincide with global marketing events where  by the compute cycles available for the service that is hosted in the different regions could be varied by just changing the provisioning policies.

In addition, I am looking for the platform to be able to insure that the commerce site has the ability to honor the QoS needs of its' key subscribers/ top rated customers even during times of unpredictable bursts.  So the question is does anyone know of PaaS or Application Infrastructure Virtualization platforms that are able to provide such an elasticity in the platform to scale up or to throttle the compute resources specifically based on consumer calls.  Is there a possibility for…

Attributes of a Product Manager...

My fellow blogger wrote about "Should Architects aspire to be Product Managers?" in which he recounts talents like being able to interact with customers, understanding the revenue model, being able to understand and articulate how the technology maps/ aligns with the business strategy, being able to work with a cross-functional teams and so on (8 attributes in total).   Strikingly, softer skills of "passion" and "focus" were called out on at least a couple of occasions, two key characteristics , in my opinion shared with the consummate  architect!!

Not only do I completely agree with the list my colleague outlines but from experience I can also testify these as key qualities of an good Product Manager.  In addition, I have found the following two attribute in a couple of "great" Product Managers with whom I have had the pleasure of interaction.  I wish to highlight these qualities as well.  

Hence, at nine and ten I propose these abilities.   P…

Innovation - Incubator for "rogue" applications (continued)

Welcome to the "Architect 2 Architect” blog, Mahi!Awesome first post as well!I am using an unconventional mechanism to reply to your intriguing blog post “”.
I am in complete agreement with you on both your dilemma about introduction of “out of compliance’ business solutions into the main stream enterprise technology stack and with your observation that the architect community is in fact at odds with the business in terms ofthe value prop assigned to these so called "rogue" solutions.
First of, a quick comment on why architects approach these “rouge or disruptive technologies” with skepticism!Architects fear lack of interoperability standards in the new technology, the solutions’ inability to scale, or that there are security loop holes.Architects are also right in verbalizing the business concerns in the pre-production phase which are the very QoS concerns that would plague the business us…

Innovation - Incubator for "rogue" applications

We, Architects, always have heartburns whenever we talk/think of a system that does not exactly fit into Enterprise Architect and it’s standards. I always struggled with such systems mostly because every time we talk about integration and information/data consistency across the systems this so called “rogue” application becomes yet another system to deal with. And that potentially makes it very difficult because it is not built based on the same Enterprise Architecture Standards rest of the Enterprise subscribes. What’s interesting is, often, business loves such systems. Few months ago I read a paper (I will try and find the bookmark again) on Gartner that talked about the same topic but had a different spin on it. That got me thinking whether the cause of “heard burn” is simply a matter of being on the same page with business in terms of their expectations from such “rogue” systems. I think these “rogues” are probably an area where Enterprise Architecture should start sho…

What is the definition of a strategic partnership with a vendor?

In this post I try to outline a few features of what I would consider a strategic partnership with a service provider or a technology vendor.  These are thoughts that I have distilled from years of experience (good and bad) with my vendor partners. 
Hence this aspect of doing business cannot be overlook and not the least of these is the "cost" of doing business.
Here are a few key attributes, not necessarily in any particular order of preference.
1) the strategic partner relationship has to go beyond a transactional one to that of a more long term one 2) the strategic partner has to have skin in the game - they have to be measured with your success criteria - they can succeed only if you do 3) the strategic partner has to be willing to "share" their technology roadmap with you 4) the strategic partner has to allow you to re-shape their technology roadmap to meet your needs 5) the strategic partner relationship has to include making their test labs, test gear, professiona…