Tuesday, October 05, 2010

Should Architects aspire to be Product Managers?

One of the interesting trends I am observing is that Architectures aspiring to be Product Managers. Have recently come across multiple PM who were architects and have also been approached my a few who are interested in becoming one.

Following are my thoughts on when Architects should consider PM as their career path.
  1. A true Business Architect with the ability to map the technology strategy to align with the Business Strategy
  2. Good understanding and hopefully first hand experience interacting with the real customer (not the business units)
  3. Good understanding of revenue and business model
  4. Passionate and believe about the role of the products in the customers life (whatever they are using the product for)
  5. Ability to influence cross-functional team and get everyone passionate and focused on the product
  6. Willing to change course mid-stream based on customer/market feedback
  7. Ability to ride up and down the market roller coaster
  8. Ability to keep singularly focused on an single product/portfolio

Do not take on the role:
  1. by assuming that PM get to define the product and every one else will follow without any questions (the PM is responsible for bringing every one on board)
  2. consider whether one would be a great Architect vs. a good Product Manager (focus on what one is better at doing - a great advise given to me by my manager)
  3. do not want to deal with constant communication with customers / leadership teams
  4. assume that the grass is greener there - doing what one does best shall reap the right rewards

Just my point of view and this could also apply for taking on a role of a Business Liaison in an IT organizations.

- Yogish

Monday, June 14, 2010

Enterprise Architecture (EA) team's role in Solution Delivery

Hello Fellow Architects - I am writing this blog in response to Todd Biske's blog entry on the fact that Enterprise Architecture Must Assist in Delivery.  I am in complete agreement with Todd on this aspect of EA's role in the enterprise.  Participating in delivery of business solutions is a value add that cannot be discounted. Not only does it add to the credibility to EA but it allows EA to be viewed as an ally which makes it easy for it to stay in touch with the "goings-on" in the enterprise.  This partnership and visibility is key to start identifying cross-domain synergies and cross-business process impacts across all the granular projects.

As the leader of EA I have tried to instill this behavior in my team.  My team is now seen as a much more "useful" partner by delivery and not just as a "watch-dog".  Some of this perception change was a result of EA working with delivery in coming up with practical multi-step solutions/ alternatives to EA standards compliance. We reached out to the delivery teams that were under a severe time crunch to come up with Remedial Action plans that incorporated tolerable architecture compromises that would not jeopardize the stability and flexibility of the solution while still delivering business value (on-time!!).  Putting such intermediate architecture solutions in place with hooks for building upon these architecture constructs increased buy-in from both application delivery teams and their business partners.  The result the business partners got to test a more robust solution and were willing to give the project team adequate time in the next phase.  In addition, we were "invited" to review plans for the next phase where we could inspect the program plans that included time to work on the agreed upon architecture compliance roadmap. I have to admit that EA did go down to a much more technical design level for helping with the integration and infrastructure to be able to communicate our architecture roadmap and recommendations. 

EA achieved not just inclusion in the process but also this forced our architects to stay in touch with reality.  This education for our Enterprise Architects allowed us to understand both limitations and constraints of the enterprise and also the technology.  Learnings from this experience were then taken into consideration in refining the technical reference implementation for the EA strategy. Finally, this education has enabled EA to be a more formidable team that was able to bring this knowledge to evaluate vendor "marketecture" thus keeping irrelevant products out of the enterprise.

Your feedback is invaluable.



Thursday, February 18, 2010

I have been busy developing globalized SaaS products

It has been a while since I last blogged, especially after joining Intuit in 08-2008. For those not familiar with Intuit engineering culture, Intuit is one of the most admired companies above the other famous companies and can attest to that (feel free to drop me line if you want more details).

OK! enough about where I work and just a quick reminder to the readers of this blog - the comments on the blog represent my own personal view and not that of my employer or any third party (with disclaimer in place can now continue :) ).

For over a year now I have been working on a personal finance tool product called Intuit Money Manager which was launched last month in India through our partner Money Control - click here to learn more about the product and click here to get started with a 90 day free trial.

So what had this got to do with Strategic Use of Information Technology? Well! for those interested in managing your own money (like me) - we have been using tools like Quicken, Money (Microsoft withdrew the product from the market last year) and Mint.com which has been very useful in helping plan our finances.

Intuit Money Manager takes only few minutes for the consumers in India to get started and with capabilities like account aggregation, auto categorization, setting goals, reviewing trends (income & spending) and tracking investments provides a comprehensive PFM tool that is configured for the Indian market. For the folks in the US - I would direct them to Mint.com which provides similar capabilities and have personally been using this product since they launched.

In the subsequent blogs I shall try and provide some additional insights on developing globalized SaaS product and how adopting Services Oriented Architecture has helped us achieve this at a much faster pace than traditional development methodology. This approach is not just adopted by our product teams inside the company. Intuit does also provide 3rd party developers to access services at the Intuit Partner Platform and would recommend you check it out, especially if you want to develop and launch a SaaS based consumer or small business product(s) rapidly.

More to follow later and as usual feel free to drop me a line with your comments/feedback.

- Yogish

Key Learnings - Using EDA to implement the core SOA principle of "loose-coupling"!!!

A lot has been said about how SOA and EDA are unique "architecture styles". It seems like only one or the other architectural prin...