<?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,2008:/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-08-06T08:47:25Z</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 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:25Z</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>
<entry>
    <title>Enterprise Architecture Tools &amp; the Gartner Magic Quadrant</title>
    <link rel="alternate" type="text/html" href="http://infosysblogs.com/ea/2008/07/enterprise_architecture_tools.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=18" title="Enterprise Architecture Tools &amp; the Gartner Magic Quadrant" />
    <id>tag:infosysblogs.com,2008:/ea//1.18</id>
    
    <published>2008-07-01T11:53:11Z</published>
    <updated>2008-07-01T12:08:35Z</updated>
    
    <summary>Tools are rarely the main reason for unsuccessful EA activities. For many organisations mandating one tool is not the answer to successful EA. An EA tool portfolio and roadmap can allow different people and material to be brought into the &apos;fold&apos; and provide a basis for integration</summary>
    <author>
        <name>Andrew Manning</name>
        
    </author>
            <category term="Tools" />
    
    <content type="html" xml:lang="en" xml:base="http://infosysblogs.com/ea/">
        <![CDATA[<p>Gartner recently published their June 2008 Magic Quadrant for Enterprise Architecture (EA) tools. (See http://www.gartner.com/DisplayDocument?id=697707&amp;ref=g_sitelink (<strong>registration required</strong>); or a free version at http://www.troux.com/company/news/pressrelease.asp?pr=080618_gartnermq_pr.xml). </p><p>A couple of things sprang to mind as I skimmed through the report: </p><p>Tools are rarely the main reason for unsuccessful EA activities. There's the commonly quoted phrase &quot;a fool with a tool is still a fool&quot; (and can add &quot;a fool with a tool can do more damage more quickly&quot;). <br /></p>]]>
        <![CDATA[The same is true for the Gartner Magic Quadrants. As a tool they can be misused, intentionally or not. The report has a specific scope, focussing on the modelling and repository aspects of the tools (and to some extent publication) as well as supplier capabilities. It's easy to be lulled into thinking that tool X is better than tool Y (even if it is only at a high level). But this ignores a number of other dimensions such as: the tool's ability to support different levels of organisational capability; how likely it is to be adopted by different user communities; how well it supports 'getting stuff used'...<br />&nbsp;<br />Personally, I like the Gartner 'Magic Quadrants' . They're handy for showing people an overview of the main players (selected by Gartner, and less useful if there is something you want to promote that doesn't rank highly). The quadrants have a reassuring, semi-quantitative feel. And, they indicate '<em>ability to execute</em>' vs. '<em>vision</em>'. Surely not much more that people developing EA roadmaps need!?.. <br />&nbsp;<br />However, for many organisations mandating one tool is not the answer to successful <a title="Enterprise Architecture" href="http://www.infosys.com/ea">EA</a>. An EA tool portfolio and roadmap can allow different people and material to be brought into the 'fold' and provide a basis for integration. (This is where EA metamodels start to become handy, as well as adoption of standard modelling notations such as BPMN). There are several Enterprise Architectural maturity <a title="Enterprise Architecture Survey" href="http://www.infosys.com/ea-survey">assessments</a> around. Looking at the tooling needs for the different dimensions being assessed is one way of identifying tool requirements and priorities. &nbsp;<br />&nbsp;<br />A couple of specific thoughts on the report: <br />&nbsp;<br />It'll be interesting to see how IBM takes forward the Telelogic suite (and the access it now has to EA groups in various companies). And also how it deals with the potential synergies/overlaps/duplication between various modelling products such as System Architect, Rational Rose, Tau Modeller ... as well the requirements management tools (Requisite Pro and DOORS, though the latter has quite a mature following in the government and defence areas). &nbsp;<br />&nbsp;<br />SAP: Aris (IDS Scheer) and Mega are still tempting for organisations with large SAP investments.<br />&nbsp;<br /><a title="Microsoft" href="http://www.infosys.com/microsoft">Microsoft</a> isn't listed specifically (always interesting to see how Enterprise Architects react when you mention Visio). Visio is not a 'proper/traditional' enterprise architecture tool. However, many organisations do have models in Visio and most of the more sophisticated tools will support Visio import (and in some instances export)&nbsp; eg System Architect's improved Visio import capability makes it easier to leverage some of that existing collateral. Over the next few years, as Microsoft's &quot;Oslo&quot; takes shape; as the gap between design and implementation reduces, it will be interesting to see how things change. Portals (eg SharePoint and Visio 2007 +) will provide many organisations with a way of quickly providing interaction/discussion around models - outside of the traditional EA group.<br />&nbsp;<br />Perhaps surprisingly (or not), there is no explicit reference to <a title="SOA" href="http://www.infosys.com/soa">SOA</a> in this EA tool assessment. Many of the tool vendors listed do provide SOA support linked into the broader EA capability to varying degrees.<br />&nbsp;<br />Irrespective of what people think of the content of the Gartner EA tool Magic Quadrant many &quot;decision makers&quot; will look at this when considering tools and that is sufficient reason to at least skim the report.<br />&nbsp;<br />Andrew<br />&nbsp;<br />(As an example of a set of detailed EA tool features see http://www.enterprise-architecture.info/Images/EA%20Tools/Enterprise%20Architecture%20Tool%20Selection%20Guide%20v4.2.pdf )]]>
    </content>
</entry>
<entry>
    <title>Role of an Architect: Lessons from the movies - Part 2</title>
    <link rel="alternate" type="text/html" href="http://infosysblogs.com/ea/2008/06/role_of_an_architect_lessons_f_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=17" title="Role of an Architect: Lessons from the movies - Part 2" />
    <id>tag:infosysblogs.com,2008:/ea//1.17</id>
    
    <published>2008-06-30T06:02:30Z</published>
    <updated>2008-06-30T06:25:59Z</updated>
    
    <summary>What is the role of an Enterprise Architect? What are the essential skills for an Enterprise Architect? What lessons do movies hold for enterprise architects? The lessons that an architect can learn from this movie are - Selling ideas &amp; on boarding people, Never lose sight of the goal even in turmoil, Negotiation, Leading change etc.
</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 previous <a href="http://infosysblogs.com/ea/2008/06/role_of_an_architect_lessons_f.html" title="Role of an Architect">post</a>, I talked about Henry Fonda's role in 12 Angry Men and the lessons it held for an Enterprise Architect. Let us switch from Hollywood to Bollywood. Consider the movie <a href="http://www.lagaan.com/" title="Lagaan">Lagaan</a> (<em>Year of Release</em>: 2001; <em>Director</em>: Ashutosh Gowarikar; <em>Our Architect</em>: Bhuwan, played by Aamir Khan; <em>Architect's character</em>: Peasant, captain of a novice cricket team).</p><p>Lagaan highlights some aspects of an Architect's job - selling ideas, negotiation, leading change etc. <br /></p>]]>
        <![CDATA[<p>The movie &lsquo;Lagaan&rsquo; will always be remembered for having made it to the Oscars from India and being one of the most successful Indian movies of recent times. The word &lsquo;Lagaan&rsquo; translates to Tax that the British Government used to collect, from Indian peasants &amp; Kings alike, during their rule. The movie depicts the struggle of a man who is offered a tax release package if he can beat the English at the game of cricket. The only problem is that neither he nor anyone else that he knows understands or has ever played the game. He is given three months time to learn the game, convince others, form a team and beat the English team.<br /></p><p>The <strong>lessons that an architect can learn</strong> from this movie are:<br />&bull;&nbsp;&nbsp; &nbsp;Selling ideas &amp; on boarding people<br />&bull;&nbsp;&nbsp; &nbsp;Never lose sight of the goal even in turmoil<br />&bull;&nbsp;&nbsp; &nbsp;Negotiation<br />&bull;&nbsp;&nbsp; &nbsp;Leading change<br />&bull;&nbsp;&nbsp; &nbsp;Asking for help<br />&bull;&nbsp;&nbsp; &nbsp;Overcoming traditional barriers<br />&bull;&nbsp;&nbsp; &nbsp;Having &amp; maintaining faith<br />&bull;&nbsp;&nbsp; &nbsp;Courage under fire<br /></p><p>Scenes to watch for:<br />1. In the first half of the movie there is a scene where our architect is thrown the challenge of beating the English at the game. He does not react immediately and waits for the opponent to raise the stake from one year&rsquo;s tax break for one village to three years tax break for the whole province.<br /><br /><em>Nothing has taught me to do my due diligence more than this scene from this movie. As an architect you need to know when is the stake good enough to take a risk or walk away. Walking away is extremely difficult for most of us but sometimes it just makes common sense!<br /></em><br />2. There is another very interesting scene during the beginning of the match between the two teams.&nbsp; Since our architect&rsquo;s team has never played the game of this scale before, they fret when the match starts. Irrespective of the direction of any shot being hit, everyone on the field starts running towards the ball. Till the time the architect instructs everyone to hold their ground and purpose and only pursue shots that are fired in their direction.<br /><br /><em>I have personally experienced this problem in large scale projects. The team totally loses control from top to bottom when a small issues comes in a high risk, high stakes project. It is at times like these that the architect should preserve common sense and pacify his team. Make sure the issues are tackled in the same way that they are tackled in a medium scale project. He needs to keep panic at bay and maintain order in the functioning of the team.<br /></em><br />3. There is another scene shot on the immediate next day after the challenge is accepted by our architect. He still does not have any other player in his team and is looking for recruitment. The approach that he uses is same as that used by Napoleon when he had to get his army across the Alps - by convincing the army that this was in fact not the Alps, but just another mountain. In the movie, our architect ridicules the game of cricket by comparing it with a simple game of stick &amp; peg which everyone is comfortable with. He gets a child to take the bowl and tries to hit it hard with a home-made bat. The setting that he chooses is the village center to get maximum effect.<br /><br /><em>This scene can teach an architect attributes like <strong>idea selling, on-boarding people &amp; leading change</strong>. It also gives good insight into how to handle new technology and get your team up to speed. People who have seen this movie will also agree with another lesson that comes from this episode &ndash; help can come from unexpected quarters. The first team mate that our architect gathers is a mad fortune teller whom most of the village has written off as a no good, cynic.<br /></em><br />4. While the team is practicing for the big day and they are still short of players our architect stumbles upon a hidden talented spin bowler. The problem is that he is an untouchable belonging to a lower caste and none of the other players want to play with him. The way our architect tackles this problem in the movie is by first embracing the new bowler and then reminding everyone of the common goal and common enemy. He also makes it crystal clear that this is not just a game and there is no one in the team whose ego is bigger than the goal. Later in the movie, this decision turns out to be a match winner where this same bowler walks away with the hat-trick. <br /><br /><em>The corollary on our side is not too hard to imagine. Working with big teams, all of us come across people whose egos sometime wears bigger shoes than their own. It becomes the job of an architect to herd everyone as a team and lead them to a common goal. It also teaches us how to overcome traditions and barriers that they impose.<br /></em><br />5. One last scene that I would like to mention is in the last 30 minutes of the movie. The team finds out that one of them has been cheating in the game with the intention of making them lose for his personal gains. As soon as this truth surfaces, the immediate reaction from everyone is to kill that person in utter rage. Everyone besides our architect, that is. He knows that in this last hour, he cannot afford to lose out one player and go to play with one player short. His best bet is to make sure that this person turns around and plays his heart out in the next day&rsquo;s play. After saving him from the rage of the crowd, he explains him how this is his last chance and how he would need to prove himself in order to stay alive. This gamble pays off handsomely the next day when that person plays instrumental role in clinching a crucial wicket.<br /><br /><em>The lesson that we architects can take from this particular scene is to never lose sight of the big goal, even under pressure or turmoil. It also teaches us about second chances and the process of renegotiating trust.</em></p>]]>
    </content>
</entry>
<entry>
    <title>Role of an Architect: Lessons from the movies</title>
    <link rel="alternate" type="text/html" href="http://infosysblogs.com/ea/2008/06/role_of_an_architect_lessons_f.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=16" title="Role of an Architect: Lessons from the movies" />
    <id>tag:infosysblogs.com,2008:/ea//1.16</id>
    
    <published>2008-06-23T08:54:01Z</published>
    <updated>2008-06-24T13:58:44Z</updated>
    
    <summary>What is the role of an Enterprise Architect? What are the essential skills for an Enterprise Architect? What lessons do movies hold for enterprise architects?</summary>
    <author>
        <name>Guest Author</name>
        
    </author>
            <category term="Organization" />
    
    <content type="html" xml:lang="en" xml:base="http://infosysblogs.com/ea/">
        <![CDATA[<p>- Amit Jnagal, Senior Technical Architect, Infosys <br /></p><p>None of us are new to the entertainment value of movies. They can make us laugh, cry, ponder, put us to sleep, wake us up and can entertain. The use of movies for the purpose of education is not new either. In fact, there is a special genre of movies with educational values, meant for different audiences.<br /><br />Recently, I was in a discussion with my mentor. We started talking about challenges faced by the new age architects. Gradually, the conversation drifted from these challenges to the amazing world of movies. Soon after that conversation, I was conducting some training sessions for budding architects. The opening act for this training was titled &ndash; &lsquo;<em>The Role of an Enterprise Architect</em>&rsquo;.&nbsp; While preparing for that workshop, I related it back to the conversation about movies and what lessons can we architects learn from them<br /><br />Movies (from Hollywood &amp; Bollywood) can offer good lessons to architects and in general provide a good overview about role of an architect.</p>]]>
        <![CDATA[<p>Let us consider <a title="12 Angry Men" target="_blank" href="http://www.imdb.com/title/tt0050083/">12 Angry Men</a> (<em>Year of Release</em>:1957; <em>Director</em>: Sidney Lumet; <em>Our Architect</em>: Juror#8 played by Henry Fonda; <em>Architect's character</em>: Juror in a 12 member Jury<br /></p><p>It would be highly in-appropriate if I tried to relate the role of an Architect to characters in movies and started with any other movie. 12 Angry Men is a black and white movie which depicts a murder trial for which a jury of 12 members is to deliberate and come up with a decision. </p><p>At the start of the deliberation, 11 of the members are convinced that the defendant is guilty of murder in the first degree and one person, only one person is doubtful. For the next one hour, this single gentleman convinces everyone else of the loopholes in the case and gets a 12-0 verdict acquitting the accused of all charges. <br /><br />Incidentally, this 12th person who single handedly turns the opinion around happens to be an Architect by profession (a civil one though).<br /></p><p>The <strong>lessons</strong> that an architect can learn from this movie are:<br />&bull;&nbsp;&nbsp;&nbsp; Consensus Building<br />&bull;&nbsp;&nbsp;&nbsp; How to speak your mind and not go with the general opinion when you are not convinced<br />&bull;&nbsp;&nbsp;&nbsp; How to use facts to justify your argument when emotions run high<br />&bull;&nbsp;&nbsp;&nbsp; Innovation<br />&bull;&nbsp;&nbsp;&nbsp; Never, ever to let go of your common sense<br /></p><p>Scenes to watch out for:</p><ul><li><p>There is a scene in the middle of the movie about a fact presented in the case according to which it takes less than 10 seconds for an injured person to walk about 20 meters. Our architect proves, by enacting the situation, that it is not possible. </p></li></ul><blockquote><p>I can very easily relate to this situation in <a title="Enterprise Architecture" href="http://www.infosys.com/ea">architecture</a> work. A lot of time people come to the negotiation table with pre-conceived notions or facts that they believe to be true. If you doubt the authenticity of a fact, go ahead and challenge it. Do some research, collect facts and go back to the table with figures and numbers. It can help you turn the balance to your advantage. The other aspect of our work that this scene highlights is the need and importance of PoC&rsquo;s to validate hypothesis and bring certainty in projects.</p></blockquote><ul><li><p>Towards the beginning of the movie, there is a scene where the jury talks about a witness who remembers the accused carrying the same knife with which the murder was committed. The architect produces an exactly similar looking knife that he purchased after hearing the argument. He proves that the knife is not extra ordinary and is very easy to get hold of. This shows the importance of doing your homework or research on a project.</p></li></ul><blockquote><p>This scene again emphasis the value of research and doing your homework. Before going for a discussion, you can find new insights if you spend some time with Google or an expert that you trust. It also teaches us architects to look beyond what the eye can see. Sometimes, the facts are not what they seem. </p></blockquote>]]>
    </content>
</entry>
<entry>
    <title>EA Coverage in Orlando (The Gartner EA Summit)</title>
    <link rel="alternate" type="text/html" href="http://infosysblogs.com/ea/2008/06/ea_coverage_in_orlando_the_gar.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=15" title="EA Coverage in Orlando (The Gartner EA Summit)" />
    <id>tag:infosysblogs.com,2008:/ea//1.15</id>
    
    <published>2008-06-16T04:21:12Z</published>
    <updated>2008-06-16T04:30:10Z</updated>
    
    <summary>The Gartner EA Summit was about Business Architecture (BA), EBA, SOA and Information Architecture. There was an over bearing importance on Business Architecture. Given the magnifying glass business sponsors have on IT budgets and its alignment to strategic corporate initiatives, EA, information architecture, security are key topics.</summary>
    <author>
        <name>Sohrab Kakalia</name>
        
    </author>
            <category term="Organization" />
    
    <content type="html" xml:lang="en" xml:base="http://infosysblogs.com/ea/">
        <![CDATA[<p>Wow, is the only way to start looking at the turnout in Orlando for the <a href="http://www.gartner.com" title="Gartner" target="_blank">Gartner</a> Enterprise Architecture (EA) Summit held last week (June&nbsp; 11 - 13). More so since all the participants braved the thunderstorms and weather to show up despite stranded flights. For myself, I decided to take matters into my own hands after an unscheduled landing in Tampa and drove down enjoying Florida&rsquo;s wide lane freeways which seemed surprisingly dry given the stormy weather hours ago.</p><p>Back to the EA conference which mostly starred Gartner VPs and Analysts, the whole conference was about Business Architecture (BA), EBA, <a href="http://www.infosys.com/soa" title="SOA">SOA</a> and Information Architecture. <br /></p>]]>
        <![CDATA[<p>There was an over bearing importance on Business Architecture and managing the goals of the organization and hence the CEO.<br /><br />One area which keeps beating us is the missing steps between the as-is to to-be systems. Especially rationalization of systems and the specific options to &ldquo;simplify&rdquo; the underlying assets without making systems overly complex as we add BA, BPM, SOA into the mix.<br /><br />The turnout as mentioned in the Gartner opening by Anne Lapkin (Research VP, Gartner), had an extended industry presence from manufacturing, services industry and telcos besides the regular financial services, retail and insurance segment. While the turnout was huge, we still missed the CIOs in the audience. </p><p>Does this mean the CIOs and CTOs relate less to <a href="http://www.infosys.com/ea" title="Enterprise Architecture">EA</a>? Given the magnifying glass business sponsors have on IT budgets and its alignment to strategic corporate initiatives, EA, information architecture, security are topics getting into the hot seat.</p>]]>
    </content>
</entry>
<entry>
    <title>The changing discipline of Enterprise Architecture</title>
    <link rel="alternate" type="text/html" href="http://infosysblogs.com/ea/2008/06/the_changing_discipline_of_ent.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=14" title="The changing discipline of Enterprise Architecture" />
    <id>tag:infosysblogs.com,2008:/ea//1.14</id>
    
    <published>2008-06-11T08:25:26Z</published>
    <updated>2008-06-11T08:36:55Z</updated>
    
    <summary>t was interesting to note that a majority of the participants had already implemented foundation elements of Enterprise Architecture, such as enterprise-wide technology standards and policies.  There was a definite push towards business process architecture. However, we need to do a much better job with enterprise IT architecture before going the whole hog into the architecture of an enterprise.</summary>
    <author>
        <name>Sohel Aziz</name>
        
    </author>
            <category term="Organization" />
    
    <content type="html" xml:lang="en" xml:base="http://infosysblogs.com/ea/">
        <![CDATA[Recently, I made a presentation (below) on the changing discipline of <a title="Enterprise Architecture" href="http://www.infosys.com/ea">Enterprise Architecture</a> (EA) at a Butler group <a title="Enterprise Architecture Masterclass" href="http://www.infosys.com/newsroom/events/2008/EA-master-class.asp">event</a>.&nbsp; It was interesting to note that a majority of the participants had already implemented foundation elements of EA, such as enterprise-wide technology standards and policies.&nbsp; There was a definite push towards business process architecture.&nbsp; This obviously got us into <a title="SOA" href="http://www.infosys.com/soa">SOA</a> territory (when was the last time someone tried to do services without processes?)&nbsp; <br />]]>
        <![CDATA[<p>One of the lead Butler Group analysts went on to explain how one can't necessarily do one without the other, especially if we are looking at a business transformation context.&nbsp; Incidentally, he coined the term &lsquo;Service Oriented Enterprise Architecture&rsquo; too, which naturally put a smile on my face as a colleague and I wrote a <a href="http://www.infosys.com/IT-services/architecture-services/white-papers/SOA-link-between-EA-SOLA.pdf">paper</a> on the missing link between EA and SOA last year. We presented it at the Deutsche Post SOA Days Conference held in Bonn, Germany (this is the pre-eminent SOA conference held in the ASG region).<br /><br />So, it's good to know that the industry is heading in the same direction.&nbsp; We need to do a much better job with enterprise IT architecture before going the whole hog into the architecture of an enterprise.&nbsp; Today, we are still unable to effectively define an execution platform to support a business operating model.&nbsp; I have also been a fan of learning to walk before one runs!&nbsp; So, let's get the operating model defined and ensure that we collectively define and model the 4 dimensions of EA for that operating model in a consistent, repeatable and manageable fashion.</p><p><strong>The presentation</strong>:&nbsp;</p>

<div style="width:425px;text-align:left" id="__ss_460214"><object style="margin:0px" width="425" height="355"><param name="movie" value="http://static.slideshare.net/swf/ssplayer2.swf?doc=makingenterprisearchitecturestrategic-1213163546236119-9"/><param name="allowFullScreen" value="true"/><param name="allowScriptAccess" value="always"/><embed src="http://static.slideshare.net/swf/ssplayer2.swf?doc=makingenterprisearchitecturestrategic-1213163546236119-9" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="425" height="355"></embed></object><div style="font-size:11px;font-family:tahoma,arial;height:26px;padding-top:2px;"><a href="http://www.slideshare.net/?src=embed"><img src="http://static.slideshare.net/swf/logo_embd.png" style="border:0px none;margin-bottom:-5px" alt="SlideShare"/></a> | <a href="http://www.slideshare.net/Infosys/making-enterprise-architecture-ea-strategic-with-business-and-information-architecture?src=embed" title="View Making Enterprise Architecture (EA) Strategic with Business and Information Architecture on SlideShare">View</a> | <a href="http://www.slideshare.net/upload?src=embed">Upload your own</a></div></div>]]>
    </content>
</entry>

</feed> 

