<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
    <title>EA - Enterprise Architecture or Extreme Aggravation</title>
    <link rel="alternate" type="text/html" href="http://infosysblogs.com/ea/" />
    <link rel="self" type="application/atom+xml" href="http://infosysblogs.com/ea/atom.xml" />
   <id>tag:infosysblogs.com,2009:/ea/1</id>
    <link rel="service.post" type="application/atom+xml" href="http://www.infosysblogs.com/ea-mt/mt-atom.cgi/weblog/blog_id=1" title="EA - Enterprise Architecture or Extreme Aggravation" />
    <updated>2008-12-22T06:09:51Z</updated>
    <subtitle>Using Enterprise Architecture to achieve competitive advantage through IT. Are you successful or aggravated?</subtitle>
    <generator uri="http://www.sixapart.com/movabletype/">Movable Type 3.2ysb5-20051201</generator>
 
<entry>
    <title>Role of an Architect: Lessons from the movies - Part 8</title>
    <link rel="alternate" type="text/html" href="http://infosysblogs.com/ea/2008/12/role_of_an_architect_lessons_f_7.html" />
    <link rel="service.edit" type="application/atom+xml" href="http://www.infosysblogs.com/ea-mt/mt-atom.cgi/weblog/blog_id=1/entry_id=34" title="Role of an Architect: Lessons from the movies - Part 8" />
    <id>tag:infosysblogs.com,2008:/ea//1.34</id>
    
    <published>2008-12-15T06:14:22Z</published>
    <updated>2008-12-22T06:09:51Z</updated>
    
    <summary>One lesson that we architects can pick up from this movie is to dream – dream big and pursue them. The end goal of an architect’s career, or any other career for that matter, is to pursue a dream – something that makes you happy, something that sets you free.</summary>
    <author>
        <name>Guest Author</name>
        
    </author>
            <category term="Best Practices" />
    
    <content type="html" xml:lang="en" xml:base="http://infosysblogs.com/ea/">
        <![CDATA[- <a href="http://www.infosys.com/IT-services/information-management/default.asp" title="Information Management">Amit Jnagal</a>, Senior Technical Architect, Infosys <br /><br />In my last <a href="http://infosysblogs.com/ea/http:/infosysblogs.com/ea/2008/08/role_of_an_architect_lessons_f_6.html" title="Role of an Architect">post</a>, I talked about the movie <a href="http://www.imdb.com/title/tt0104952/" target="_blank" title="My Cousin Vinny">My Cousin Vinny</a> and the lessons it held for Architects about sticking to the basics, understanding your customers and understanding yourself.<br />In this post, I am going to look at <a href="http://www.imdb.com/title/tt0454921/" target="_blank" title="The Pursuit of Happyness">The Pursuit of Happyness</a> (Year of Release: .2006; Director: Gabriele Muccino; Our Architect: Chris Gardner played by Will Smith; Architect's Character: Sales Man turned stock broker who know how to dream big and keep it going).<br /><br />&lsquo;The pursuit of happyness&rsquo; tells the story of the trials and tribulations of semi-successful sales man for whom every day is a struggle. The essence of this movie is how to dream big and manage it along with the daily struggle. We usually get too involved in the tasks that are assigned to us and find very little or no time for stuff that matters outside assignments. Very few other industries, other than ours, have employees who are up to speed with the usage of the term &lsquo;work life balance&rsquo; and how it affects them.<br />]]>
        <![CDATA[One lesson that we architects can pick up from this movie is to dream &ndash; dream big and pursue them. I have been asked this question a few times by different mentees &ndash; &ldquo;What is the end goal for an architect&rsquo;s career? Or If I pursue the career path of an architect, where will I be 10 years from now?&rdquo; Let me take a stab at this question in context of this movie. The end goal of an architect&rsquo;s career, or any other career for that matter, is to pursue a dream &ndash; something that makes you happy, something that sets you free.<br /><br />For some people the dream is realized when they become their own boss, head the technology think tank of an organization or make it to the board of directors of a company. Yet, for some others, dreams are realized when they invent something, write a book, or teach something. It doesn&rsquo;t matter what your dream is, as long as have one.<br />I believe in the saying &ndash; &ldquo;Dreams are work in progress&rdquo;. Make it grand, make it big and keep it close to your heart. Don&rsquo;t forget to remind yourself regularly that whatever you are doing today is just a path to realize your dream; it is not the end game! To pursue anything worthwhile, you need to dream it first.<br /><br />The end goal of a career path is when you have realized a few big dreams &hellip; <br />]]>
    </content>
</entry>
<entry>
    <title>Outsourcing of Enterprise Architecture (EA) functions and Infosys&apos; EA survey</title>
    <link rel="alternate" type="text/html" href="http://infosysblogs.com/ea/2008/12/outsourcing_of_enterprise_arch_1.html" />
    <link rel="service.edit" type="application/atom+xml" href="http://www.infosysblogs.com/ea-mt/mt-atom.cgi/weblog/blog_id=1/entry_id=33" title="Outsourcing of Enterprise Architecture (EA) functions and Infosys' EA survey" />
    <id>tag:infosysblogs.com,2008:/ea//1.33</id>
    
    <published>2008-12-05T09:34:23Z</published>
    <updated>2008-12-05T09:48:15Z</updated>
    
    <summary>Enterprise Architecture as a capability that was core to their business and inherently part of their organisation&apos;s crown jewels. However, given the daunting set of activities that most Enterprise Architecture functions have to execute today, the opportunity to work with ESPs and enlist them to execute some of these activities is real.</summary>
    <author>
        <name>Sohel Aziz</name>
        
    </author>
            <category term="Emerging Trends" />
    
    <content type="html" xml:lang="en" xml:base="http://infosysblogs.com/ea/">
        <![CDATA[<p>We just completed our 3rd annual <a href="http://www.infosys.com/ea-survey" target="_blank" title="Infosys' EA survey">survey</a> on <a href="http://www.infosys.com/ea" target="_blank" title="Enterprise Architecture">Enterprise Architecture</a>. The survey brought out some very exciting findings, as well as some which we see as potential gaps or blue ocean.&nbsp; </p><p>One of the key findings is that participants of the survey saw Enterprise Architecture as a capability that was core to their business and inherently part of their organization's crown jewels. However, given the daunting set of activities that most Enterprise Architecture functions have to execute today, the opportunity to work with ESPs and enlist them to execute some of these activities is real. In other words, some activities (the more tactical ones), can be outsourced to a strategic vendor partner.</p>]]>
        <![CDATA[<p><a href="http://www.gartner.com" title="Gartner" target="_blank">Gartner</a> has reiterated this in their <a href="http://www.gartner.com/DisplayDocument?ref=g_search&amp;id=824313&amp;subref=simplesearch" title="Gartner" target="_blank">research note</a> (<em><strong>subscription required</strong> to view the note</em>) this week.&nbsp; It is comforting to see that they see the same conclusions from the data as we have - there are specific activities that one can engage ESPs on, but don't wholesale outsource the capability.&nbsp; </p><p>We have engaged with multiple organizations to <a href="http://www.infosys.com/IT-services/architecture-services/case-studies/enterprise-architecture-IT-governance.pdf" title="Enterprise Architecture">execute</a> select EA activities in a collaborative model,&nbsp; with the objective of ensuring that the EA function focuses on core activities such as business engagement, business alignment and strategic IT planning.<br /><br />We are therefore seeing truly mature EA functions recognizing what is <em>core vs context</em> in their operating models and leveraging partners as necessary, to deliver even more business value cost effectively.</p>]]>
    </content>
</entry>
<entry>
    <title>IT strategy and agile EA in the new economy</title>
    <link rel="alternate" type="text/html" href="http://infosysblogs.com/ea/2008/11/it_strategy_and_agile_ea_in_th.html" />
    <link rel="service.edit" type="application/atom+xml" href="http://www.infosysblogs.com/ea-mt/mt-atom.cgi/weblog/blog_id=1/entry_id=32" title="IT strategy and agile EA in the new economy" />
    <id>tag:infosysblogs.com,2008:/ea//1.32</id>
    
    <published>2008-11-14T09:11:38Z</published>
    <updated>2008-11-14T09:17:32Z</updated>
    
    <summary>Enterprise Architecture has long been seen as time consuming to implement, difficult to get buy in and govern. Do organizations really have the luxury of choice?</summary>
    <author>
        <name>Sohrab Kakalia</name>
        
    </author>
            <category term="Emerging Trends" />
    
    <content type="html" xml:lang="en" xml:base="http://infosysblogs.com/ea/">
        EA has long been seen as time consuming to implement, difficult to get buy in and govern. Do organizations really have the luxury of choice? The cost of not aligning and optimizing is bringing systems to a grinding halt, not because of lack of CPU power, but dwindling funds to manage them. Very similar to the fuel crisis and need for better efficiency or alternative energy thinking, the time is ripe for efficient EA. What EA also needs is a dose of lightning up. EAlite anyone?
        <![CDATA[<p>With so much in the works with B2B, B2C, G2B (government to biz) taking center stage fueled by industry standards like ACORD (Insurance),SID (Telecom), FIXML/FPML (Finance), HL7 (Healthcare), etc, the time is ripe to tie the standards knot and adopt universally acceptable baselines. SaaS and Cloud computing too will get easier to adopt.</p><p>Next month&rsquo;s <a href="http://www.infosys.com/newsroom/events/2008/gartner-enterprise-architecture-summit.asp" target="_blank" title="Gartner EA Summit">Gartner Enterprise Architecture Summit</a> in Las Vegas (Dec 10th-12th) will be one to watch. The real value of EA and its agility will be put to test in the next few quarters and years. How it ties back to this month&rsquo;s Master Data Management Summit in Chicago (again by Gartner) will be even more interesting given that the set of analysts have very little overlap</p>]]>
    </content>
</entry>
<entry>
    <title>Enterprise Architecture Enabling Strategies</title>
    <link rel="alternate" type="text/html" href="http://infosysblogs.com/ea/2008/11/enterprise_architecture_enabli.html" />
    <link rel="service.edit" type="application/atom+xml" href="http://www.infosysblogs.com/ea-mt/mt-atom.cgi/weblog/blog_id=1/entry_id=31" title="Enterprise Architecture Enabling Strategies" />
    <id>tag:infosysblogs.com,2008:/ea//1.31</id>
    
    <published>2008-11-07T18:17:14Z</published>
    <updated>2008-11-21T15:50:38Z</updated>
    
    <summary>EA enabling strategies and principles should be specific to each enterprise; And is governed by its business strategy by a large extent.  In recent times, some common EA enabling strategies, in one way or the other, have influenced EA more than the others. This entry is an attempt to identify some of those more ubiquitous and important ones, that may further be elaborated on case to case basis. </summary>
    <author>
        <name>Santanu Dey</name>
        
    </author>
            <category term="Best Practices" />
    
    <content type="html" xml:lang="en" xml:base="http://infosysblogs.com/ea/">
        <![CDATA[<p>EA enabling&nbsp;strategies and principles&nbsp;should be&nbsp;specific to&nbsp;each enterprise; And is governed by its business strategy by a large extent.<span>&nbsp; </span>In recent times, some common EA&nbsp;enabling&nbsp;strategies, in one way or the other, have influenced EA more than the others. This&nbsp;entry&nbsp;is an attempt to identify some of those more ubiquitous and important ones, that may further be elaborated on case to case basis. </p><p><span><strong>Form an Architecture Governance Team<br /></strong></span><span>&nbsp;</span></p><ul><li><span>A central team constituted with representation from stakeholders across the organization, should govern the planning, evolution and implementation of an Enterprise Architecture framework<br /></span><span>&nbsp;</span></li><li><span>Architecture should be well thought through to meet the common goals of all stakeholders.<br /></span><span>&nbsp;</span></li><li><span>The central team also should play a key role in establishing products, design and technology standards<br /></span></li></ul>]]>
        <![CDATA[<p><span><strong>Information Architecture should be done across systems</strong></span></p><span><ul><li><span>Information is Business Asset. Decision-making requires information that exists beyond the boundaries of individual systems, departments or agencies. Hence information models should not be limited to system boundaries<br /></span><span><span>&nbsp;</span></span></li><li><span>Treating data as a business asset increases the importance of identifying integrity and relevancy of data and improves data quality access<br /></span><span><span>&nbsp;</span></span></li><li><span>Information should be classified. Appropriate security policy, DR policy should mapped<br /></span><span><span>&nbsp;</span></span></li><li><span>Enterprise Security principles and standards must be identified and applied uniformly across all projects</span></li></ul></span><p><span><strong>Identify and implement common services for the enterprise</strong></span></p><span><ul><li><span>Common services provide the basis of a truly service oriented architecture. Common Services will be responsibility of a inter-department &lsquo;shared-services&rsquo; team<br /></span><span>&nbsp;</span></li><li><span>Care should be taken to make the low-level common services independent of each other<br /></span><span>&nbsp;</span></li><li><span>Common Services should respect the common information model as closely as possible</span></li></ul></span><p><span><strong>Factor in scalability</strong></span></p><span><ul><li><span>Key aspects of scalability are volume, concurrency and functionality. Decisions on the underlying technology infrastructure should factor all these dimensions</span></li></ul></span><span><p><span><strong>Plan business continuity orientation early</strong></span></p></span><span><ul><li><span>Assess availability requirements of the systems based on business needs. Overstated availability requirements can cost dearly. On the other hand, not considering business continuity with adequate seriousness can mean disaster for the business. Hence, appropriate reliability and disaster recovery strategies are essential to overall architecture planning</span></li></ul></span><p><span><strong>Reduce TCO</strong></span></p><span><ul><li><span>Cost of compliance (development, implementation, maintenance, training, and infrastructure) should be balanced against technology considerations (scalability, flexibility, ease-of-use) in decision-making<br /></span><span><span>&nbsp;</span></span></li><li><span>System consolidation and rationalization should be aggressively pursued aligning with the Business and IT Strategy<br /></span><span><span>&nbsp;</span></span></li><li><span>Adherence to widely adopted open standards reduces obsolescence risks</span></li></ul></span><p><span><strong>Consider shared vs. owned and virtual vs. physical</strong></span></p><span><ul><li><span>An increasing number of services today can be sourced from outside the organization, including hosted software, data, and maintenance of the same<br /></span><span><span>&nbsp;</span></span></li><li><span>Outsource operation and processes, maintaining strategic architectural decisions<br /></span><span><span>&nbsp;</span></span></li><li><span>Also, consider virtualized hardware platforms those can be scaled up or down on demand</span></li></ul></span>]]>
    </content>
</entry>
<entry>
    <title>Outsourcing of Enterprise Architecture functions.. 2008 Survey findings</title>
    <link rel="alternate" type="text/html" href="http://infosysblogs.com/ea/2008/09/outsourcing_of_enterprise_arch.html" />
    <link rel="service.edit" type="application/atom+xml" href="http://www.infosysblogs.com/ea-mt/mt-atom.cgi/weblog/blog_id=1/entry_id=30" title="Outsourcing of Enterprise Architecture functions.. 2008 Survey findings" />
    <id>tag:infosysblogs.com,2008:/ea//1.30</id>
    
    <published>2008-09-20T03:45:29Z</published>
    <updated>2008-09-20T05:03:52Z</updated>
    
    <summary>During the past few weeks I also got involved in an interesting activity: analysis and review of responses to the 2008 Enterprise Architecture survey that Infosys has been conducting annually for the past few years.
 
This year, we invited technology leaders from our client base and the global IT community to participate. 173 respondents from a cross-section of industry verticals, geographies and organizational sizes completed a web questionnaire of 24 detailed questions.  A preliminary analysis of the results indicates a few trends, including</summary>
    <author>
        <name>Guest Author</name>
        
    </author>
            <category term="Emerging Trends" />
    
    <content type="html" xml:lang="en" xml:base="http://infosysblogs.com/ea/">
        <![CDATA[<p>- <a href="http://infosysblogs.com/managing-offshore-it/bloggers.html">Mohan Babu K</a> (cross posted from the <a title="Managing Offshore IT" href="http://www.infosysblogs.com/managing-offshore-it/">Managing Offshore IT</a> blog)</p><p>During the past few weeks I got involved in an interesting activity: analysis and review of responses to the 2008 Enterprise Architecture survey that Infosys has been conducting annually for the past few years.<br />&nbsp;<br />This year, we invited technology leaders from our client base and the global IT community to participate. 207 respondents from a cross-section of industry verticals, geographies and organizational sizes completed a web questionnaire of 24 detailed questions.&nbsp; A preliminary analysis of the results indicates a few trends, including:</p><ul><li>Enterprise Architecture is enabling business transformation [Does this surprise me?]</li><li>EA practices continue to mature with increasing use of metrics and processes [Again no surprises on this front]</li><li>Outsourcing of activities focused at Enterprise Architecture is an opportunity that most EA teams have not seriously considered [Now, this is interesting] </li></ul>]]>
        <![CDATA[<p>Among the new thread in this year&rsquo;s survey were questions centered on Outsourcing of Enterprise Architecture functions. If you really must know, the reason for this dipstick is obvious: the debate over outsourcing and offshoring of IT functions is moot since organizations across the spectrum are already working with vendors from across the globe. However, niche areas like Enterprise Architecture are perhaps behind the curve &ndash;compared to other areas -- when it comes sourcing. This is an area I had also briefly touched on in <a href="http://www.offshoringmanagement.com/theBook.htm">my Book</a>. </p><p>My colleagues and I brainstormed on the findings. One school of thought was that though the findings were surprising, we shouldn&rsquo;t emphasize the discovery on Outsourcing since it may be perceived as trying to interpret data to fit our business model.&nbsp; I can see an argument here:&nbsp; we are a software service firm and our business model does centre on outsourcing and offshoring. On the other side, people like our practice lead in Europe, <a href="http://infosysblogs.com/ea/bloggers.html">Sohel Aziz</a>&nbsp;were equally vocal on why we should publish the finding. Sohel argued '<em>some of the data does indicate that organizations are not thinking of outsourcing elements of EA.&nbsp; If we go back 5 years, we were not thinking of outsourcing testing&hellip;now it is one of the fastest growing IT segments globally.&nbsp; Back then IT orgs thought they needed to do all this in-house too&hellip;. I see an opportunity to take the tactical elements of EA (such as solution architecture governance) and technology R&amp;D out of the picture and getting that as a pay-as-you-go service.&nbsp; So that the EA&rsquo;s spend more time on the REALLY important stuff such a business engagement.</em>&rdquo; I couldn&rsquo;t have summarized it better. </p><p>For those interested, here&rsquo;s a plug: My colleagues from Europe plan to be at the Gartner Enterprise Architecture Summit next week. Copies of the summary of the survey [&ldquo;Enterprise Architecture Expands its Role in Strategic Transformation&rdquo;] will be available at the summit. The more detailed analysis of the finding will be <a href="http://www.infosys.com/IT-services/architecture-services/enterprise-architecture/default.asp">published online</a> soon</p>]]>
    </content>
</entry>
<entry>
    <title>Role of an Architect: Lessons from the movies - Part 7</title>
    <link rel="alternate" type="text/html" href="http://infosysblogs.com/ea/2008/08/role_of_an_architect_lessons_f_6.html" />
    <link rel="service.edit" type="application/atom+xml" href="http://www.infosysblogs.com/ea-mt/mt-atom.cgi/weblog/blog_id=1/entry_id=28" title="Role of an Architect: Lessons from the movies - Part 7" />
    <id>tag:infosysblogs.com,2008:/ea//1.28</id>
    
    <published>2008-08-06T08:36:00Z</published>
    <updated>2008-08-06T08:47:39Z</updated>
    
    <summary>The movie My Cousin Vinny has some good lessons for budding architects and their first experience as an architect - about having a good grounding in the fundamentals, acknowledging the limits of your knowledge and handling tough customers</summary>
    <author>
        <name>Guest Author</name>
        
    </author>
            <category term="Organization" />
    
    <content type="html" xml:lang="en" xml:base="http://infosysblogs.com/ea/">
        <![CDATA[<p>- <a title="Information Management" href="http://www.infosys.com/IT-services/information-management/default.asp">Amit Jnagal</a>, Senior Technical Architect, Infosys <br /></p><p>In my last <a href="http://infosysblogs.com/ea/2008/07/role_of_an_architect_lessons_f_3.html" title="Role of an Architect">post</a>, I talked about the movie <a title="The 300 Spartans" target="_blank" href="http://www.imdb.com/title/tt0055719/">The 300 Spartans</a> and the lessons it held for Architects about doing the right thing, courage under fire, looking for alternatives etc.</p><p><a href="http://www.imdb.com/title/tt0104952/" target="_blank" title="My Cousin Vinny">My Cousin Vinny</a> (<em>Year of Release</em>: 1992; <em>Director</em>: Jonathan Lynn; <em>Our Architect</em>: Vincent Gambini, played by Joe Pesci; <em>Architect's Character</em>: Lawyer handling his first case for his cousin).</p><p>&lsquo;My Cousin Vinny&rsquo; is the story of a lawyer who finds himself defending his first cousin on the charges of first degree murder in his first ever trial. He has no experience as a lawyer and has never even attended the court as a lawyer, is totally unaware of the process or the protocol. He learns on the fly, makes silly mistakes on his first case, is excited by the trivial stuff, but makes a solid come back using his fundamental skills and saves his cousin from an almost certain seat on the electric chair. <br /></p>]]>
        <![CDATA[<p>This movie provides us great insights on a budding architect&rsquo;s first experience as architect, kind of things to watch out for and what to look up to in nervous times.<br /></p><p>A few important lessons that this movie can provide us are:<br />&bull;&nbsp;&nbsp; &nbsp;Never to let go of our fundamentals<br />&bull;&nbsp;&nbsp; &nbsp;Acknowledge and know what you do not know<br />&bull;&nbsp;&nbsp; &nbsp;Handling tough customers<br /></p><p>Scenes to look out for:<br />1. There is a scene in the middle of the movie where Vinny thinks that he has built a connection with his prosecuting lawyer and as a result, got access to all his case files. When he tries to show off how smart he is to his fianc&eacute;, she points out that the prosecution is bound by law to share the case files with the defense lawyer, otherwise, it could lead to a mistrial.<br /><br /><em>First inference that we can draw from this scene is to know the law of the land before you get in to a project. Do your home work; find out what works and what doesn&rsquo;t. Try to get any historical inputs about a customer if any precedence is available. If it doesn&rsquo;t make you look smart in front of your customer, at least it will not make you look stupid. This is of particular help if your organization has had a tough history with a customer.</em><br /><br />2. The second theme that flows throughout the movie is how Vinny manages the judge in whose court he is arguing the case. The first two times that he pleads the case, he gets himself arrested for the contempt of court. But he learns from his faults and by the end of the case, he makes a fan out of the tough magistrate.<br /><br /><em>Personally, I like working with tough customers. They bring about a point of inflection in your career which makes you improve just to be able to survive. At the end of a tough assignment, you come out with a new level of maturity and invaluable experience in the form of a few burnt fingers. Secondly, it&rsquo;s usually the tough customers that can help take you and your organization places. Experiencing the way Vinny manages the magistrate, gives you good insights into how to manage tough customers &ndash; understand what excites them and what does not.</em><br /><br /></p>]]>
    </content>
</entry>
<entry>
    <title>Reason, Stakeholder Engagement / Management and EA</title>
    <link rel="alternate" type="text/html" href="http://infosysblogs.com/ea/2008/08/reason_stakeholder_engagement.html" />
    <link rel="service.edit" type="application/atom+xml" href="http://www.infosysblogs.com/ea-mt/mt-atom.cgi/weblog/blog_id=1/entry_id=27" title="Reason, Stakeholder Engagement / Management and EA" />
    <id>tag:infosysblogs.com,2008:/ea//1.27</id>
    
    <published>2008-08-01T19:03:50Z</published>
    <updated>2008-08-01T19:48:54Z</updated>
    
    <summary>“Seven reasons why people hate reason”.  Now, that is a guide I would have loved to have alongside during some rather difficult stakeholder engagements, when I couldn’t stop thinking “If only they could be reasonable…”.</summary>
    <author>
        <name>Rajeev Arora</name>
        
    </author>
            <category term="Best Practices" />
            <category term="Organization" />
            <category term="Tools" />
    
    <content type="html" xml:lang="en" xml:base="http://infosysblogs.com/ea/">
        <![CDATA[<!--[if gte mso 9]><xml>  <w:WordDocument>   <w:View>Normal</w:View>   <w:Zoom>0</w:Zoom>   <w:PunctuationKerning/>   <w:ValidateAgainstSchemas/>   <w:SaveIfXMLInvalid>false</w:SaveIfXMLInvalid>   <w:IgnoreMixedContent>false</w:IgnoreMixedContent>   <w:AlwaysShowPlaceholderText>false</w:AlwaysShowPlaceholderText>   <w:Compatibility>    <w:BreakWrappedTables/>    <w:SnapToGridInCell/>    <w:WrapTextWithPunct/>    <w:UseAsianBreakRules/>    <w:DontGrowAutofit/>   </w:Compatibility>   <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>  </w:WordDocument> </xml><![endif]--><!--[if gte mso 9]><xml>  <w:LatentStyles DefLockedState="false" LatentStyleCount="156">  </w:LatentStyles> </xml><![endif]--><p class="MsoNormal">Current issue of the New Scientist magazine has a very interesting cover story on &ldquo;<a target="_blank" href="http://www.newscientist.com/article.ns?id=mg19926661.400">Seven reasons why people hate reason</a>&rdquo;.<span>&nbsp; </span>Now, that is a guide I would have loved to have alongside during some rather difficult stakeholder engagements, when I couldn&rsquo;t stop thinking &ldquo;If only they could be reasonable&hellip;&rdquo;.</p>  ]]>
        <![CDATA[<!--[if gte mso 9]><xml>  <w:WordDocument>   <w:View>Normal</w:View>   <w:Zoom>0</w:Zoom>   <w:PunctuationKerning/>   <w:ValidateAgainstSchemas/>   <w:SaveIfXMLInvalid>false</w:SaveIfXMLInvalid>   <w:IgnoreMixedContent>false</w:IgnoreMixedContent>   <w:AlwaysShowPlaceholderText>false</w:AlwaysShowPlaceholderText>   <w:Compatibility>    <w:BreakWrappedTables/>    <w:SnapToGridInCell/>    <w:WrapTextWithPunct/>    <w:UseAsianBreakRules/>    <w:DontGrowAutofit/>   </w:Compatibility>   <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>  </w:WordDocument> </xml><![endif]--><!--[if gte mso 9]><xml>  <w:LatentStyles DefLockedState="false" LatentStyleCount="156">  </w:LatentStyles> </xml><![endif]--><p class="MsoNormal">The above cover story is developed through seven micro-essays written on each reason by a separate neuroscientist.<span>&nbsp; </span>It summarises a number of issues about influencing others that we have learnt either by experience or through the practices of <a target="_blank" href="http://en.wikipedia.org/wiki/Change_management_%28people%29">organisational change</a>. Practical techniques such as <a target="_blank" href="http://en.wikipedia.org/wiki/Forming-storming-norming-performing">Storming, norming, forming and performing</a> provide us a tool for systematically influencing groups.<span>&nbsp; </span></p>    <p class="MsoNormal">At a summary level, seven reasons why people don&rsquo;t like reason are:</p>  <ol style="margin-top: 0cm"><li class="MsoNormal">Reason      stands against values and morals (or in my opinion, the existing order)</li><li class="MsoNormal">No      one actually reasons (as illustrated by the micro essay, decision making a      complex brain activity. We only use reason to hypothesise about a conclusion      or decision that our brain has already reached).</li><li class="MsoNormal">I      hear &ldquo;reason&rdquo;, I see lies &ndash; We are all familiar with this one.<span>&nbsp; </span>To really capture an organisation&rsquo;s      reality, you need to document the walk the executives walk, rather than      the talk they talk.</li><li class="MsoNormal">Reason      excludes creativity and intuition</li><li class="MsoNormal">Whose      reason is anyway?<span>&nbsp; </span>.. or the      subjectivity of reason</li><li class="MsoNormal">Reason      destroys itself</li><li class="MsoNormal">Reason      is just another faith</li></ol>    <p class="MsoNormal">When an EA project sponsor entrusts you to work with his or her stakeholders, they are asking you to lead part of their organisation&rsquo;s journey from one way of thinking to another.<span>&nbsp; </span>Those of us who have attempted this many times know that the success rate is less than 100%.</p>    <p class="MsoNormal">What is your experience in this regard? What techniques have you settled on?<span>&nbsp; </span>Is <a target="_blank" href="http://en.wikipedia.org/wiki/Forming-storming-norming-performing">storming-norming-forming-performing</a> enough?</p><p class="MsoNormal">At another time, I will talk about recent thinking in economics about &quot;a society of minds&quot;, as described in the book &quot;<a title="Origin of Wealth" target="_blank" href="http://www.mckinsey.com/ideas/books/originofwealth/overview.asp">Origin of Wealth</a>&quot;.&nbsp; But for now, I will like to know your experiences in the area of influencing individuals and groups during enterprise architecture engagements.</p>  <span style="font-size: 12pt; font-family: &quot;Times New Roman&quot;"> </span>]]>
    </content>
</entry>
<entry>
    <title>The most important considerations for Enterprise Architecture projects</title>
    <link rel="alternate" type="text/html" href="http://infosysblogs.com/ea/2008/07/the_most_important_considerati.html" />
    <link rel="service.edit" type="application/atom+xml" href="http://www.infosysblogs.com/ea-mt/mt-atom.cgi/weblog/blog_id=1/entry_id=26" title="The most important considerations for Enterprise Architecture projects" />
    <id>tag:infosysblogs.com,2008:/ea//1.26</id>
    
    <published>2008-07-31T10:58:03Z</published>
    <updated>2008-07-31T11:09:38Z</updated>
    
    <summary>As part of a proposal, a prospect asked us to provide the 10 most important pieces of advice for an  EA team. Many EA projects are short of a clear objective. 4 key considerations are - understand the issue you are trying to address, organizational transformation is not an IT issue,   get the right stakeholders on board for the scope you are trying to address and communicate, communicate, communicate</summary>
    <author>
        <name>Thomas Obitz</name>
        
    </author>
            <category term="Best Practices" />
    
    <content type="html" xml:lang="en" xml:base="http://infosysblogs.com/ea/">
        <![CDATA[As part of a proposal, a prospect asked us to provide the 10 most important pieces of advice for an <a href="http://www.infosys.com/enterprise-architecture" title="Enterprise Architecture">EA</a> team. Wow, I thought, that&rsquo;s a really good question. And short of being able to do an awful lot of literature research (I am still on this assignment in the Middle East, and my library is at home back in Frankfurt), I just took a shot. <br /><br />I did not manage to get together 10 guidelines, but have a look at these 4 &ndash; and please feel free to fill in with your own experience.<br /><br />]]>
        <![CDATA[1. <strong><em>Understand the issue you are trying to address</em></strong> <br /> Many EA projects are short of a clear objective - which problem to solve and which stakeholder's needs to address. This results in a lack of sponsorship, inability to measure results and to demonstrate benefits, and a general lack of direction.<br /> <br />The key activity when kicking of or revitalizing an EA effort is to understand the issue the organization needs to address. If it is on the path for massive growth, the organizational structure as well as the organisational assets (including IT) need to be focussed on the value streams driving the growth. In a large organizational transformation, existing assets need to be compartmentalized to enable their reconfiguration. <br /><br />If it is about cost control, cost drivers need to be identified, areas and mechanisms of cost reduction need to be defined. All these changes are deeply architectural in nature.<br /> <br />Identifying these core objectives allows getting the right stakeholders on board and enlisting their backing by aligning with their needs (well, in the end with their KPIs and incentives). Without them, EA is just another J2EE &ndash; a pure technicality without any relevance for the performance of the organization.<br /> <br />2. <em><strong>Organizational Transformation is not an IT issue</strong></em><br /> While architectural practices and architectural approaches are often driven out of the CIO's organization, they are not a matter of IT. <a href="http://www.infosys.com/enterprise-architecture" title="Enterprise Architecture">Enterprise Architecture</a> &ndash; in the sense of &quot;Architecture of the Enterprise&quot; &ndash; is about the way the organization leverages its assets to orchestrate its value chains, how it uses them to build a platform for execution. It is about enabling well-understood segments of variability which link into the core execution infrastructure to create organizational leverage and scale, and to execute on unique value propositions quickly. EA also helps identifying transactional utility services which are opportunities for out- or insourcing - strengthening organizational focus or creating business opportunities.<br /> <br />Building such a platform for execution is a massive organizational transformation initiative. IT can help structuring it; but executing and managing the change is a task of the organization as a whole.<br /> <br />3. <em><strong>Get the right stakeholders on board for the scope you are trying to address</strong></em><br /> There is no point making architectural decisions if the changes implied are outside the project's circle of influence. Therefore, the project needs to engage stakeholders who have the money, the resources and the influence to make things happen. <br /> <br />The only way of achieving this is to understand the (visible and hidden) objectives of stakeholders in the right power centres of the organization, and to map out how you are going to address their needs. A powerful tool is to align with an existing strategy map, as the objectives there are already agreed between a large number of stakeholders.<br /> <br />4. <em><strong>Communicate, communicate, communicate</strong></em><br /> Enterprise Architecture has a huge spectrum of stakeholders, most of them outside IT. Engaging them means passing targeted messages through the right &ndash; formal and informal &ndash; channels. It also means communicating continuously, and providing information both in pull and push mode.<br /> This requires marketing techniques, an area many Enterprise Architects tend not to very well-versed in. So the Marketing and Communications department is their natural partner in these efforts. If there is an internal communications group, great - it will even have the channels and infrastructure. Otherwise, it will have people who can at least help defining how to address the organization.<br /> So, as I mentioned before &ndash; feel free to share your advice. I am still 6 topics short from my original target&hellip;<br /><br />Kind Regards from the really, really sunny Middle East<br />Thomas Obitz<br /><br />]]>
    </content>
</entry>
<entry>
    <title>Role of an Architect: Lessons from the movies - Part 6</title>
    <link rel="alternate" type="text/html" href="http://infosysblogs.com/ea/2008/07/role_of_an_architect_lessons_f_3.html" />
    <link rel="service.edit" type="application/atom+xml" href="http://www.infosysblogs.com/ea-mt/mt-atom.cgi/weblog/blog_id=1/entry_id=25" title="Role of an Architect: Lessons from the movies - Part 6" />
    <id>tag:infosysblogs.com,2008:/ea//1.25</id>
    
    <published>2008-07-29T09:40:40Z</published>
    <updated>2008-07-29T09:56:01Z</updated>
    
    <summary>There are a lot of lessons that we, as architects, can pick up from this movie - The 300 Spartans. The most important one being – develop the right attitude and use it! The second most important thought that this movie provokes is to introspect ourselves to see what are we made of? What are our values and how do we prioritize them</summary>
    <author>
        <name>Guest Author</name>
        
    </author>
            <category term="Organization" />
    
    <content type="html" xml:lang="en" xml:base="http://infosysblogs.com/ea/">
        <![CDATA[<p>- <a href="http://www.infosys.com/IT-services/information-management/default.asp" title="Information Management">Amit Jnagal</a>, Senior Technical Architect, Infosys</p><p>In my last <a title="Role of an Architect" href="http://infosysblogs.com/ea/2008/07/role_of_an_architect_lessons_f_5.html">post</a>, I talked about the movie <a href="http://www.swades.com" target="_blank" title="Swades">Swades</a> and the lessons it held for Architects about giving back in the form of teaching budding architects, publishing papers etc. </p><p><a title="The 300 Spartans" href="http://www.imdb.com/title/tt0055719/" target="_blank">The 300 Spartans</a> (<em>Year of Release</em>: 1962; <em>Director</em>: Rudolph Mate; <em>Our Architect</em>: King Leonidas, played by Richard Egan; <em>Architect's Character</em>: The Greek king of Sparta who is up against a stronger Persian army)</p><p>&lsquo;The 300 Spartans&rsquo; depicts the invasion of Greece by the Persian army and the role of King Leonidas, the king of Sparta, known for its proud, bold and courageous army. The story deals with a number of issues &ndash; the role of the senate, the mammoth scale of problem at hand and the values of a team, in this case of a state. <br /></p>]]>
        <![CDATA[<p>The legend is that King Leonidas, prohibited to use his army to fight against the Persians by his own Senate members, decides to take on the swarm of Persian army with 300 of his body guards. His force not only holds the Persian army at bay in a long drawn battle but also ignites the values of the rest of the Greeks who decide to launch an all out war against the Persians. This movie was remade in 2006 under the name &lsquo;300&rsquo;.</p><p>&nbsp;The lessons that this movie offers for architects are:<br />&bull;&nbsp;&nbsp; &nbsp;Doing the right thing &ndash; aligned with our own personal and moral values.<br />&bull;&nbsp;&nbsp; &nbsp;Courage under fire<br />&bull;&nbsp;&nbsp; &nbsp;Setting an example to ignite other minds.<br />&bull;&nbsp;&nbsp; &nbsp;Persistence<br />&bull;&nbsp;&nbsp; &nbsp;Looking for alternatives<br />&bull;&nbsp;&nbsp; &nbsp;Attitude!<br /></p><p>For this movie too, I will skip talking about any specific scenes because it makes its point through the whole storyboard. There are a lot of lessons that we, as <a title="Architecture" href="http://www.infosys.com/enterprise-architecture">architects</a>, can pick up from this movie. The <strong>most</strong> important one being &ndash; develop the right attitude and use it! The <strong>second most</strong> important thought that this movie provokes is to introspect ourselves to see what are we made of? What are our values and how do we prioritize them. <br /></p><p>Values are something that take the form of our signature in all our work. You can tell from the work of an architect that he places higher premium on technology than on business, or if he confronts issues vs. sweeping them under the carpet.&nbsp; Values form the torch light which show us the way when all other light is swept away. They can push us to do the right thing and doing the things right.</p>]]>
    </content>
</entry>
<entry>
    <title>Architecture Speak</title>
    <link rel="alternate" type="text/html" href="http://infosysblogs.com/ea/2008/07/architecture_speak.html" />
    <link rel="service.edit" type="application/atom+xml" href="http://www.infosysblogs.com/ea-mt/mt-atom.cgi/weblog/blog_id=1/entry_id=24" title="Architecture Speak" />
    <id>tag:infosysblogs.com,2008:/ea//1.24</id>
    
    <published>2008-07-24T03:05:45Z</published>
    <updated>2008-07-24T03:27:28Z</updated>
    
    <summary><![CDATA[As I sit down to blog for the first time on the Enterprise Architecture blogs, a very fundamental question crosses my mind.&nbsp; That is how do architects speak, or communicate in general.&nbsp;A very common occurance is to use a lot...]]></summary>
    <author>
        <name>Rajeev Arora</name>
        
    </author>
            <category term="Organization" />
            <category term="Tools" />
    
    <content type="html" xml:lang="en" xml:base="http://infosysblogs.com/ea/">
        <![CDATA[<p>As I sit down to blog for the first time on the Enterprise Architecture blogs, a very fundamental question crosses my mind.&nbsp; That is how do architects speak, or communicate in general.</p><p>&nbsp;A very common occurance is to use a lot of buzzwords.&nbsp; I once encountered an architect who said &quot;issue A and issue B are orthagonal&quot;.&nbsp; He meant A and B are independent of each other.&nbsp; Architecture patterns too - be they singletons or&nbsp;facades - can be confusing explanations to IT management and customers.</p>]]>
        <![CDATA[<p>The main issue I wish to raise is that does our language need to be so threatening to outsiders.&nbsp; No wonder many times architects are described as out of touch or&nbsp;too abstract.</p><p>My experience is that messages to people outside the architecture community need to be in simple language.&nbsp; Business executives who often are sponsors of IT work, and hence of architecture projects, business operations managers, IT project managers are all interested in understanding the recommended course of action and the rationale for it.</p><p>While the rigour of architecture formulations is a necessity, very often architects use complex language to impress each other.&nbsp; Over a long period of enterprise architecture engagements, I have settled on simple and clear working and final deliverables that do not require translation before being tabled to the stakeholders</p><p>I will like to know your experience.&nbsp; What parts of the architecture speak, in your opiniion, are complex by necessity and need the relevant rigorous terminology?&nbsp; Do you or people you work with use long words just to impress each other?&nbsp; Or, as in the words of my above mentioned architect friend, need and practice are othagonal to each other?</p><p>See you around.</p><p>Rajeev Arora</p><p>&nbsp;Melbourne. Australia</p>]]>
    </content>
</entry>
<entry>
    <title>Role of an Architect: Lessons from the movies - Part 5</title>
    <link rel="alternate" type="text/html" href="http://infosysblogs.com/ea/2008/07/role_of_an_architect_lessons_f_5.html" />
    <link rel="service.edit" type="application/atom+xml" href="http://www.infosysblogs.com/ea-mt/mt-atom.cgi/weblog/blog_id=1/entry_id=23" title="Role of an Architect: Lessons from the movies - Part 5" />
    <id>tag:infosysblogs.com,2008:/ea//1.23</id>
    
    <published>2008-07-21T12:45:49Z</published>
    <updated>2008-07-21T12:55:44Z</updated>
    
    <summary>At the end of every year, an architect should measure his/her success by the number of things he/she has given back in that year. The &apos;giveback&apos; can take form of a class that you taught to budding architects, a paper that you published based on your experience to spread your knowledge or a novel item that you invented to aid the industry.</summary>
    <author>
        <name>Guest Author</name>
        
    </author>
            <category term="Organization" />
    
    <content type="html" xml:lang="en" xml:base="http://infosysblogs.com/ea/">
        <![CDATA[<p>- <a href="http://www.infosys.com/IT-services/information-management/default.asp" title="Information Management">Amit Jnagal</a>, Senior Technical Architect, Infosys</p><p>In my last <a href="http://infosysblogs.com/ea/2008/07/role_of_an_architect_lessons_f_4.html" title="Role of an Architect">post</a>, I talked about the movie&nbsp;<a title="Padosan" href="http://www.imdb.com/title/tt0063404/" /><a href="http://www.imdb.com/title/tt0063404/" title="Padosan">Padosan</a> and the lessons it held for Architects about observation, analyzing the non-obvious, taking care of your team, knowing your priorities etc.</p><p><a title="Swades" href="http://www.swades.com/" /><a href="http://www.swades.com/" title="Swades">Swades</a> (<em>Year of Release</em>: 2004; <em>Director</em>: Ashutosh Gowarikar; <em>Our Architect</em>: Mohan Bhargav, played by Shahrukh Khan; <em>Architect's Character</em>: A Music Director by profession, US-based research scientist with NASA, of Indian origin).</p><p>&lsquo;Swades&rsquo; is a story of Mohan Bhargav, a research scientist with NASA. He has Indian origin but is settled in the US with a nice job and comforts of life. He makes a trip to India to see his grandmother when leads him to a village. During this trip, he gets a firsthand experience of life in rural India and how far behind they have been left from the &lsquo;progress&rsquo; made by towns of the world. <br /></p>]]>
        <![CDATA[<p>As a first project, Mohan helps a bunch of villagers set up an electricity generating unit. Subsequently, he decides to move back to India for good and dedicate his life for the advancement of rural India.<br /></p><p>There are three important lessons that this movie can teach architects:<br />&bull;&nbsp;&nbsp; &nbsp;Giveback<br />&bull;&nbsp;&nbsp; &nbsp;Giveback<br />&bull;&nbsp;&nbsp; &nbsp;Giveback<br /></p><p>I will refrain from going into the specifics of a few scenes for this movie, as the message is spread across the whole movie in bits and pieces. </p><p>As architects, we often forget to take a breather and give something back to our community, to our industry which has given us the fabulous opportunity to work and make living doing the stuff that we love enough to do for free.<br /></p><p>At the end of every year, an architect should measure his/her success by the number of things he/she has given back in that year. The 'giveback' can take form of a class that you taught to budding architects, a paper that you published based on your experience to spread your knowledge or a novel item that you invented to aid the industry.</p>]]>
    </content>
</entry>
<entry>
    <title>Architecting Business Solutions vs. the Business of architecting technology solutions (continued)</title>
    <link rel="alternate" type="text/html" href="http://infosysblogs.com/ea/2008/07/architecting_business_solution_1.html" />
    <link rel="service.edit" type="application/atom+xml" href="http://www.infosysblogs.com/ea-mt/mt-atom.cgi/weblog/blog_id=1/entry_id=22" title="Architecting Business Solutions vs. the Business of architecting technology solutions (continued)" />
    <id>tag:infosysblogs.com,2008:/ea//1.22</id>
    
    <published>2008-07-18T11:27:58Z</published>
    <updated>2008-07-18T11:37:16Z</updated>
    
    <summary>Clients have an opportunity (and perhaps responsibility) to ensure that the high-end consultants they engage continually provide unbiased inputs. In a sense, the challenge faced by consulting Enterprise Architects is an opportunity to you, the client. You can efficiently leverage their ideation, selling, persuasion and presentation skills to help your internal Enterprise Architects and CXOs sell the ideas and strategies to your businesses and stakeholders. By doing so, you let consultants gain the privilege of being trusted advisors, which in some cases may lead to additional downstream and business for their firms.</summary>
    <author>
        <name>Guest Author</name>
        
    </author>
            <category term="Organization" />
    
    <content type="html" xml:lang="en" xml:base="http://infosysblogs.com/ea/">
        <![CDATA[<p>- <a href="http://infosysblogs.com/managing-offshore-it/bloggers.html">Mohan Babu K</a> (cross posted from the <a href="http://www.infosysblogs.com/managing-offshore-it/" title="Managing Offshore IT">Managing Offshore IT</a> blog)</p><p>In my <a href="http://infosysblogs.com/ea/2008/07/architecting_business_solution.html" title="Architecting Business Solutions">previous post</a>, I talked about the extending role of Enterprise Architects at services firms into <a href="http://infosysblogs.com/managing-offshore-it/2007/11/can_your_offshore_vendors_marc.html">Marchitects</a>. This &lsquo;selling&rsquo; of <a href="http://www.infosys.com/IT-services/architecture-services/service-offerings/default.asp" title="Architecture Services">architecture services</a> is no different from what our peers in client organizations undertake too. </p><p>Enterprise Architects, many of whom report into a CIO/CTO organization are also under continual pressure to ensure that the organization derives an optimal ROI from their IT investments, which means they need to &lsquo;sell&rsquo; the value of robust, scalable architecture, planning and roadmaps to their stakeholders, some of whom may be focused on the tactical: ensuring that the quarterly targets are met, budgets balanced and operational challenges addressed. Even the &lsquo;strategic&rsquo; focus may sometime involve reacting to&nbsp;external trends (read between the lines: it is the <a href="http://infosysblogs.com/managing-offshore-it/2008/04/connecting_the_dots_slowdown_s.html">economy, slowdown</a> etc)</p>]]>
        <![CDATA[<p>But back to the challenge of <em>selling</em> that Enterprise Architects at service firms face:</p><ul><li>Thinking beyond revenue and dollars: Most service firms aspire to move up the proverbial &lsquo;Value Chain.&rsquo; And when it comes to technology services, what better value chain than consulting with client CxOs on their <a href="http://www.infosys.com/enterpise-architecture" title="Enterprise Architecture">Enterprise Architecture</a>? However, this &lsquo;move up value chain&rsquo; is not as simple, or even sexy as it sounds. Why? Because sales teams at services firms are geared towards (and rewarded for) &lsquo;downstream&rsquo; and &lsquo;incremental revenue.&rsquo; The challenge is that when consultants work with clients on their EA strategies and roadmaps, they shouldn&rsquo;t - and generally don&rsquo;t - have downstream-dollar-signs in their eyes&hellip;. which doesn&rsquo;t always please internal sales teams. [footnote: taking this high-road is not always practical since reward (and bonus) structures for individuals, including architects&nbsp;at service firms are geared towards meeting unit, group and organizational numbers.]&nbsp;</li><li>Being unbiased while recommending solutions: Another challenge consultants, especially from larger services firms face is while recommending solutions and technology options to clients. Architecture consultants from a product vendor organization may have their account teams tacitly leaning on them. The reason is not hard to find: most service firms have their proprietary solutions, frameworks and toolkits for myriad technologies. Consulting organizations make considerable investments in developing such solutions and the ROI can be derived only when sold/deployed by clients. There are times when these toolkits and products may be an ideal fit for a client need; but not always. Consulting Enterprise Architects need to be unbiased and be willing to push back their Account management teams when need arises. [Again, taking the high-road may come at a personal cost: internal bonuses and incentives] </li></ul><p>Clients have an opportunity (and perhaps responsibility) to ensure that the high-end consultants they engage continually provide unbiased inputs. In a sense, the challenge faced by consulting Enterprise Architects is an opportunity to you, the client. You can efficiently leverage their ideation, selling, persuasion and presentation skills to help your internal Enterprise Architects and CXOs sell the ideas and strategies to your businesses and stakeholders. By doing so, you let consultants gain the privilege of being trusted advisors, which in some cases may lead to additional downstream and business for their firms.</p>]]>
    </content>
</entry>
<entry>
    <title>Role of an Architect: Lessons from the movies - Part 4</title>
    <link rel="alternate" type="text/html" href="http://infosysblogs.com/ea/2008/07/role_of_an_architect_lessons_f_4.html" />
    <link rel="service.edit" type="application/atom+xml" href="http://www.infosysblogs.com/ea-mt/mt-atom.cgi/weblog/blog_id=1/entry_id=21" title="Role of an Architect: Lessons from the movies - Part 4" />
    <id>tag:infosysblogs.com,2008:/ea//1.21</id>
    
    <published>2008-07-14T09:22:10Z</published>
    <updated>2008-07-14T09:37:35Z</updated>
    
    <summary>Although it sounds very simple, but keen observation is a very rare skill. The architects who master this skill are automatically promoted to a different league than their competition. They have long lists of satisfied clients and are up to their neck with repeat business.</summary>
    <author>
        <name>Guest Author</name>
        
    </author>
            <category term="Organization" />
    
    <content type="html" xml:lang="en" xml:base="http://infosysblogs.com/ea/">
        <![CDATA[<p>- <a title="Information Management" href="http://www.infosys.com/IT-services/information-management/default.asp">Amit Jnagal</a>, Senior Technical Architect, Infosys</p><p>In my last <a href="http://infosysblogs.com/ea/2008/07/role_of_an_architect_lessons_f_2.html" title="Role of an Architect - Part 3">post</a>, I talked about the movie <a href="http://www.imdb.com/title/tt0210945/" target="_blank" title="Remember The Titans">Remember the Titans</a> and the lessons it held for Architects about leadership, change, how to get people from diverse backgrounds to work together etc.</p><p><a href="http://www.imdb.com/title/tt0063404/" target="_blank" title="Padosan">Padosan</a> (<em>Year of Release</em>: 1968; <em>Director</em>: Jyoti Swaroop; <em>Our Architect</em>: Guru, played by Kishore Kumar; <em>Architect's Character</em>: A Music Director by profession, Guru always has a solution for all problems and never lacks innovation) </p><p>This is one of my favorite movies. It is witty, sharp and outrageously comic. Our architect is the character of Guru (Vidyapathi) played by the legendary Kishore Kumar. Guru has a flock of 4 friends that he is really close to and is always available to them in the role of an advisor, a psychiatrist and above all a friend. He has solution for almost every problem that you can throw at him. Most of his solution look awkward, but they all work beautifully! The outline of this movie is how Guru helps his friend, Bhola (played by Sunil Dutt), who has no knowledge of music, to capture the heart of a dame, Bindu (played by Saira Banu), who is obsessed with music. <br /></p>]]>
        <![CDATA[<p>There are a lot of things that <em>an architect can learn</em> from this movie. A few worth mentioning are:<br />&bull;&nbsp;&nbsp; &nbsp;Never say die!<br />&bull;&nbsp;&nbsp; &nbsp;Keen Observation<br />&bull;&nbsp;&nbsp; &nbsp;Analyze the non-obvious<br />&bull;&nbsp;&nbsp; &nbsp;Take care of your team, your mentees, be there for them.<br />&bull;&nbsp;&nbsp; &nbsp;Know your priorities<br /></p><p>Scenes to watch for:<br />1.&nbsp;&nbsp; &nbsp;There is a scene in the middle of the movie, where the whole gang tries to spy on Bindu and her music teacher &ndash; Master Pillai (played by Mehmood). While spying, most of the other members of the team are obsessed by how beautiful Bindu looks and some are totally angry with Master Pillai for his bold movies. While all this is happening around him, Guru, using his keen observation skill analyzes that in reality, Bindu has no liking for the teacher per se, instead, she is fascinated by his musical talent and respects him for that. This single observation shapes up the remainder of the movie and becomes the key instrument in getting Bhola, his life&rsquo;s love.<br /><br /><em>Although it sounds very simple, but keen observation is a very rare skill. Unfortunately, it is also one of those skills that you cannot pick up in a class. You need to practice it by opening your mind and trying to look beyond the obvious. The architects who master this skill are automatically promoted to a different league than their competition. They have long lists of satisfied clients and are up to their neck with repeat business.</em><br /><br />2.&nbsp;&nbsp; &nbsp;At one point during the movie, when Bhola loses faith in Guru&rsquo;s strategy and approach, he grows dull and erratic. In this scene, Guru cheers him up by pointing out the silver lining and giving him a projection of what future could hold. At the same time, he also addresses his immediate concern by justifying his approach and elaborating on why he is doing things the way he is doing it.<br /><br /><em>It is a very common problem with us as Architects. We usually get carried away with the details of the technology and assume that our team and the people sitting across the table understand the reasons and rationale, right? Wrong! It is quite important for you as an architect to explain your decisions to the people around you &ndash; in the form of architectural decisions documentation or one-on-one discussions - whatever works. The flip side of this aspect is that if your team does not understand why a decision has been made, they will not be able to sell it on your behalf to others. In fact, it can also happen that they come back from meeting convinced that the decision that you have made is wrong. And the problem keeps on snowballing &hellip;</em><br /><br />3.&nbsp;&nbsp; &nbsp;In general, throughout the movie you will notice that our architect never gives up. He is always on the lookout for alternatives, for other things that may click &hellip; for a plan B. During the first half of the movie, upon learning of Bindu&rsquo;s fascination of music, Guru tries to teach Bhola the fine art of music.&nbsp; After failing miserably at that, he comes to terms with the fact this approach is not going to work and let&rsquo;s go of the approach. While he is pondering over what to do next, his mind picks up the faint sound of a radio playing at a distance. One thing leads to another and not a long time after, he decides to work with Bhola as his playback singer. A pure, master stroke of genius!<br /><br /><em>This scene can teach us the value of keeping our eyes, ears and mind open. The next big idea can come from anywhere and at any time. There are lots of corollaries available outside the technology world which can give us insights into how to tackle the most complex of IT issues. Another important lesson in this scene is to understand and appreciate different talents available in your team and come up with ingenious ways on how to put them to best use. You have dead weights in your team only because you have given up on figuring out how best to use the skills available.</em></p>]]>
    </content>
</entry>
<entry>
    <title>Architecting Business Solutions vs. the Business of architecting technology solutions</title>
    <link rel="alternate" type="text/html" href="http://infosysblogs.com/ea/2008/07/architecting_business_solution.html" />
    <link rel="service.edit" type="application/atom+xml" href="http://www.infosysblogs.com/ea-mt/mt-atom.cgi/weblog/blog_id=1/entry_id=20" title="Architecting Business Solutions vs. the Business of architecting technology solutions" />
    <id>tag:infosysblogs.com,2008:/ea//1.20</id>
    
    <published>2008-07-11T11:25:46Z</published>
    <updated>2008-07-11T11:33:41Z</updated>
    
    <summary>Enterprise Architects with service firms juggle the above challenges, along with their day-jobs of helping clients architect robust, scalable technology and business solutions. Which brings us back to where I started: the delicate balance between Architecting business and technology solutions - which architects are skilled at – and the business of architecting technology solutions</summary>
    <author>
        <name>Guest Author</name>
        
    </author>
            <category term="Organization" />
    
    <content type="html" xml:lang="en" xml:base="http://infosysblogs.com/ea/">
        <![CDATA[<p>- <a href="http://infosysblogs.com/managing-offshore-it/bloggers.html">Mohan Babu K</a> (cross posted from the <a href="http://www.infosysblogs.com/managing-offshore-it/" title="Managing Offshore IT">Managing Offshore IT</a> blog)</p><p>While reading <a href="http://infosysblogs.com/ea/bloggers.html" title="Andrew Manning">Andrew Manning</a>&rsquo;s blog entry on &ldquo;<a href="http://infosysblogs.com/ea/2008/04/enterprise_architects_time_for.html">Enterprise Architects: Time for more job titles</a>?&rdquo;&nbsp; I began thinking about a barbeque I attended at a friend's place few weeks ago where colleagues and peers had gathered. It was interesting to observe that folks who had gathered were finding it hard to pick on neutral topics beyond the day&rsquo;s weather and the difficulty in maintaining the lawn, using the host&rsquo;s backyard as a case-in-point. It was not hard to see why.&nbsp; A few were from the &lsquo;<em>sales&rsquo;</em> side of our business &ndash; account managers, engagement leaders and the like &ndash; and others from the <em>consulting</em> side - IT architects and consultants. And not surprisingly, it was the few <a href="http://infosysblogs.com/managing-offshore-it/2007/11/can_your_offshore_vendors_marc.html"><em>Marchitectects</em></a> in our midstwho were trying to find an icebreaker. <br /></p>]]>
        <![CDATA[<p>Going back to Andrew&rsquo;s list, I guess, one title, I would add is Enterprise Marchitects: folks at service firms who act as a bridge between sales and consulting. The &ldquo;Enterprise Architects&rdquo; at service firms - many of whom are also Marchitects -&nbsp; have a distinct role to play in the industry. The role also comes with its share of challenges for obvious reasons:</p><ul><li>Consulting Architects are generally sought ought in the industry and are well compensated, because of which their services also command premium/higher billing rates. From a software services context, it also means that Architects can add to a significant &lsquo;cost&rsquo; component of a typical project. Cognizant of client&rsquo;s cost constraints, the some Account Managers are more comfortable underselling the need for an architect to ensure a bigger pie of rest of the project rather than translate &lsquo;cost&rsquo; to demonstrate &lsquo;value.&rsquo; This means the architect, who is already under pressure to be continually &lsquo;billable&rsquo; also has to juggle the hat of a Marchitect</li><li>Architects also need to accept the fact that though they bring a specialized/niche skill to the table, they are still considered as &lsquo;<a href="http://infosysblogs.com/managing-offshore-it/2007/01/musings_on_offshore_resources.html">resources</a>,&rsquo;&nbsp;&nbsp;both to a firm&rsquo;s own sales folks and of course to client&rsquo;s FTEs and program stakeholders who naturally look at external consultants as <a href="http://www.informationweek.com/blog/main/archives/2007/08/hired_guns_cio.html">hired-guns</a>.</li><li>Another Marchitecture dimension is to juggle the buzz from internal and external spin doctors. Those of us who have been in the industry long enough know what I mean by spin doctors: folks who can take archaic sounding acronyms coined by industry analysts, visualize a few possible &lsquo;scenarios&rsquo; and &lsquo;solutions&rsquo; and start preaching it to clients, all with the conviction of a convert.</li></ul><p>Enterprise Architects with service firms juggle the above challenges, along with their day-jobs of helping clients architect robust, scalable technology and business solutions. Which brings us back to where I started: the delicate balance between Architecting business and technology solutions - which architects are skilled at &ndash; and the business of architecting technology solutions (read &lsquo;selling&rsquo; architecture as a service) which is a skill Architects try to acquire. Now, this yin-yang has another dimension to it: measuring the &lsquo;value&rsquo; that a consulting Enterprise Architect/Marchitect brings to the table. &hellip; </p><p>I will continue the line of thinking in my next post</p>]]>
    </content>
</entry>
<entry>
    <title>Role of an Architect: Lessons from the movies - Part 3</title>
    <link rel="alternate" type="text/html" href="http://infosysblogs.com/ea/2008/07/role_of_an_architect_lessons_f_2.html" />
    <link rel="service.edit" type="application/atom+xml" href="http://www.infosysblogs.com/ea-mt/mt-atom.cgi/weblog/blog_id=1/entry_id=19" title="Role of an Architect: Lessons from the movies - Part 3" />
    <id>tag:infosysblogs.com,2008:/ea//1.19</id>
    
    <published>2008-07-07T07:58:01Z</published>
    <updated>2008-07-07T08:08:53Z</updated>
    
    <summary>The lessons that an architect can learn from the movie &quot;Remember the Titans&quot; are about Leadership Qualities, Acting as Change Agents, How to get people of diverse values &amp; backgrounds to come together as a team, Maturity to appreciate when usual rules do not apply and Improvisation</summary>
    <author>
        <name>Guest Author</name>
        
    </author>
            <category term="Organization" />
    
    <content type="html" xml:lang="en" xml:base="http://infosysblogs.com/ea/">
        <![CDATA[<p>- <a href="http://www.infosys.com/IT-services/information-management/default.asp" title="Information Management">Amit Jnagal</a>, Senior Technical Architect, Infosys</p><p>In my last <a title="Role of an Architect - Part 2" href="http://infosysblogs.com/ea/2008/06/role_of_an_architect_lessons_f_1.html">post</a>, I talked about the movie <a title="Lagaan" target="_blank" href="http://www.lagaan.com/">Lagaan</a> and the lessons it held for Architects about selling ideas, negotiations, leading change etc.</p><p>&lsquo;<a title="Remember the Titans" target="_blank" href="http://www.imdb.com/title/tt0210945/">Remember the Titans</a>&rsquo; (<em>Year of Release</em>: 2000; <em>Director</em>: Boaz Yakin; <em>Our Architect</em>: Coach Boone, played by Denzel Washington; <em>Architect's Character</em>: Chief Coach of the first mixed race football team) is set against the time of segregation. Then the Government abolished segregated schools and gave the right to all students to enroll in any school. The movie focuses on one such school - T C Williams High School in Virginia which has been educating white students but has now opened up to black students too. There is an atmosphere of tension and apprehension on all sides. In the midst of all this turmoil, Coach Boone lands up as the head coach of the school&rsquo;s new football team.<br /></p>]]>
        <![CDATA[<p>Even in the game of football, there is a lot of resistance from both the sides to come together. Coach Boone leads the team to look beyond the color of their skin and teaches them to function as one integrated unit. This movie is based on a true story and the team that the coach put together went all the way to win the high school championship in its first year.<br /></p><p>The <strong>lessons that an architect</strong> can learn from this movie are:<br />&bull;&nbsp;&nbsp; &nbsp;Leadership Qualities<br />&bull;&nbsp;&nbsp; &nbsp;Acting as Change Agents<br />&bull;&nbsp;&nbsp; &nbsp;How to get people of diverse values &amp; backgrounds to come together as a team<br />&bull;&nbsp;&nbsp; &nbsp;Maturity to appreciate when usual rules do not apply<br />&bull;&nbsp;&nbsp; &nbsp;Improvisation<br /></p><p>Scenes to watch for:<br />1. There is a scene during the initial rounds of practice when a black team mate is confronted by the captain, who happens to be white, on how he is not playing for the team. The captain goes on to describe this player as a waste of God gifted talent and criticizes his attitude. To this, the black player replies &ndash; &ldquo;Attitude reflects the leadership, Captain.&rdquo; He further substantiates his statement by pointing out how some of the white players are not playing the game in the correct spirit, right under the captain&rsquo;s nose and how that does not bother him.<br /></p><p><em>This is one big, big take away from this movie. In our world too, attitude of the team that we are working with reflects the attitude and approach of the leader. This particular scene teaches us the value of being fair, treating every team member with respect and impartially. It also emphasizes the importance of seeking feedback from the juniors who work with you directly. This can happen informally, over a cup of coffee or a beer. What differentiates a good architect from a great architect is the latter&rsquo;s ability to be open to criticism and adaptability to change.<br /></em><br />2. After the end of a very trying training camp which lasts for a few weeks, Coach Boone congratulates the selected team by saying &ndash; &ldquo;I am not going to talk to you about winning or losing. You are all winners in my book already. Because you did not kill each other at the camp&rdquo;.<br /><br /><em>The very simple gesture of appreciation can go a long way in boosting your team&rsquo;s morale. And yet, we don&rsquo;t see it happening as often as it should. This is doubly true for high risk, high stake projects because everyone gets so engrossed in the day to day work that there is hardly any time for appreciation. Regardless of the nature and complexity of the project that you work on, do remember that you are working with people; people, who are not machines. Appreciation is a nice gesture that should be displayed whenever the opportunity arises. For complex projects you should list it as a to-do item in your task list to look for opportunities for appreciation the same way you find out time for reviews.</em><br /><br />3. In the concluding scene of the movie, there is a dialogue by one of the coach&rsquo;s daughters &ndash; &ldquo;People say that it can't work - black, white. Here we make it work every day. We still have our disagreements, of course, but before we reach for hate, always, always, we remember the Titans.&rdquo; That, kind of, sums it all up!<br /><br /><em>Gives you a true picture of how team with diverse backgrounds can come together and achieve wonders under the architect&rsquo;s leadership. <strong>Need I say more</strong>?</em><br /><br /></p>]]>
    </content>
</entry>

</feed> 

