<?xml version="1.0"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
<atom:link href="http://www.architecting-the-enterprise.com/rss/rss_articles.xml" rel="self" type="application/rss+xml" />
<title>Architecting the Enterprise</title>
<description>Architecting the Enterprise's articles RSS feed.</description>
<link>http://www.architecting-the-enterprise.com</link>
<image>
  <url>http://www.architecting-the-enterprise.com/images/logo-ate.gif</url>
  <title>Architecting the Enterprise</title>
  <link>http://www.architecting-the-enterprise.com</link>
  <description>Architecting the Enterprise</description>
  <width>132</width>
  <height>158</height>
</image>

<item>
<title>Leadership - Value Creation</title>
<description><![CDATA[<p>One of the key responsibilities of a leader is to create value for an organisation. This may sound very obvious, as you may have worked on such things as investment proposals, business cases, budgets and RFP’s. Also, at a personal level, your compensation plan may be linked to operating performance of your organisation. You may even manage a Profit & Loss statement for your part of the organisation. Still, many Enterprise Architects and IT managers have not grown up with financials, as it is not part of most standard IT curricula in tertiary education. To be an effective leader you need a clear understanding of the financial principles and practices behind value creation. Leaders will need to make financial decisions that create value at all levels in an organisation. In this article we will briefly explain what value creation is, why it is essential for leaders, and how it impacts an organisation.</p>
<h2>What is Value?</h2>
<p>Imagine that you have found a unique product for which you believe is a need in the market. You are dreaming of getting rich quickly and want to go ahead straight away. But wait, how are you going to fund this project?  You will need to buy equipment to create the product. And how are you going to pay for marketing and sales? You slowly realise that your “get rich quickly” dream might not be that easy. Before you make a decision on the new business you will need to ask the question whether your project creates value.</p>
<p>In order to fund the project you may need some money. As an owner you may provide some of this money and lend it to your company (equity). You may even find others (shareholders) who are willing to put money in your company (equity).  However, this might not be enough and you may need to borrow money from the bank as well (debt). The bank and investors don’t provide their money for free. They want to see a healthy return. Suppose you managed to borrow 10,000 dollar against 10% interest. This means that at the end of the year you need to pay back 1,000 dollar to shareholders and debt holders to finance your project. This also means that you need a return on your project of at least 1,000 dollar (10%) to pay for the money you borrowed.  However, if you expect to make exactly 1,000 dollar then you won’t add value and you should not go ahead. Not doing the project would give you the same result. So shortly, <i>your project’s expected return needs to exceed the cost of capital for your project</i>. If this is the case you will create value, otherwise you will destroy value.</p>
<h2>Value management</h2>
<p>Leaders at all levels of an organisation make decisions on a daily basis that impact value creation. These decisions can be on capital investments,  mergers & acquisitions, foreign investments, financial structures, executive remunerations and obviously IT investments. All these decisions will have an impact on the company as a whole and is reflected in the market value of a company (total value of all shares outstanding). For example, if a listed company announces a major project then the increase in the value of shares should reflect the expected additional value created by that project. It is therefore essential that organisations have a comprehensive value management system in place to help them to manage and create value.</p>
<h2>Value for whom?</h2>
<p>Value created will accrue to shareholders (owners) of the company, but what about the customers, suppliers and employees? Every company knows that it is important to value its customers, employees and suppliers. However, a company can only raise shareholder funds when they make a healthy return. If the company doesn’t manage to create healthy return then its sources of finance may dry up and it might not be able to fund its activities anymore. There are not many investors that don’t want a return on their investments. Creating value does not happen in isolation. Having healthy relationships with customers, employees and suppliers is a necessity for creating value. So the one doesn’t go without the other and the company has to find the right balance if it wants to sustain long-term value creation.</p>
<h2>Profitability</h2>
<p>Leaders in companies want to know how their decisions will impact value creation. There are a few key measures of profitability that leaders can use, depending on where they sit in an organisation. For example, an executive, whose pay package contains a large amount of shares, may look at ROE (Return on Equity). The Sales executive may be looking at ROS (Return on Sales), which is the profit per dollar of sales. Or in other words, how efficient does sales activity generate profit. IT is often measured by ROA (Return on Assets) because IT assets support the creation and delivery of products and services. The more efficient IT can deliver products and services for the organisation the more efficient IT is. This measure shows the profit of every dollar we put into IT assets. So, if we can bring IT cost down and keep the net revenue level of the company the same then we are more efficient as an IT organisation, our ROA goes up, and we add more value, right? Well, it is slightly more complicated then this. Measuring profit doesn’t necessary create more value. In fact profits are accounting measures of benefit and may not translate in cash. Value management is only interested in cash benefits. There are many organisations that reported large profits just before they went in receivership.</p>
<h2>Managing Risk</h2>
<p>Leaders deal with many complex decisions and it doesn’t get easier in value management. Not only do profitability measures relate to each other, the sources of capital (capital structure) also have an impact. Managing value inherently involves managing risk, which adds to the complexity of decision making as a leader. For example the cost of debt of a company can be deducted from the company’s income before paying tax (the interest tax shield).  This saves the company tax and therefore reduces the cost of financing and leaves more money for shareholders.  So you may think that financing the company’s capital on only debt might be a great solution. However, by doing this, the company increases its financial risk, the increased risk of not being able to pay the interest back in time. If a company takes on a lot of debt then customers and suppliers may become reluctant to buy or supply goods. They don’t’ want to take the risk of you not being able to deliver or pay. The result will be that your sales will go down and eventually it will offset the savings from your capital structure.</p>
<p>Not only do leaders deal with financial risk but also other risks related to the company, such as economic, political, competition, and operational risk. Your debt holders are not that interested in your risk as long as you pay your interest back at the end of the year, but shareholders are. Shareholders bear the additional risk because they are paid after tax and interest is deducted from the earnings. Obviously they want to be compensated for the additional risk and will therefore require higher returns for their investment than banks or other debt holders. This means that risks can be articulated in terms of value and therefore integrated with our value management.</p>
<h2>Leading for value creation</h2>
<p>As a leader you will have to make many decisions that either create or destroy value. These decisions are roughly in two areas; you have to decide what you are going to invest in for maximum value creation and decide on the right capital structure to finance these investments. At the end of the day you want your company’s <i>expected returns on investments to exceed the cost of financing these investments</i>.</p>
<p>Value management is a very comprehensive and exciting practice, which sits at the heart of every organisation. An effective leader has a clear understanding of what adds value to an organisation.</p>]]></description>
<link>http://www.architecting-the-enterprise.com/enterprise_architecture/articles/leadership_-_value_creation.php</link>
<guid isPermaLink='true'>http://www.architecting-the-enterprise.com/enterprise_architecture/articles/leadership_-_value_creation.php</guid>
<pubDate>Thu, 21 Jul 2011 09:49:09 GMT</pubDate>
</item>

<item>
<title>How Strategic Planning relates to Enterprise Architecture</title>
<description><![CDATA[<p>TOGAF® often refers to Strategic Planning without specifying the details of what it consists of. This document explains why there is a perfect fit between the two.</p>
<p>Strategic Planning means different things to different people.  The one constant is its reference to Business Planning which usually occurs  annually in most companies. One of the activities of this exercise   is the consideration of the portfolio of projects for the following financial year, also referred to as Project Portfolio Management (PPM). This activity may also be triggered when a company modifies its strategy or the priority of its current developments.</p>
<p>Drivers for Strategic Planning may be</p>
<ul>
  <li>New products or services</li>
  <li>A need for greater Business flexibility and agility</li>
  <li>Merger & Acquisition</li>
  <li>Company’s reorganization</li>
  <li>Consolidation of manufacturing plants, lines of business, partners, information systems</li>
  <li>Cost reduction</li>
  <li>Risk mitigation</li>
  <li>Business Process Management initiatives</li>
  <li>Business Process Outsourcing</li>
  <li>Facilities outsourcing or in sourcing</li>
  <li>Off shoring</li>
</ul>
<p>Strategic Planning as a process may include activities such as:</p>
<p>1. The definition of the mission and objectives of the enterprise</p>
<p>Most companies have a mission statement depicting the business vision, the purpose and value of the company and the visionary goals to address future opportunities. With that business vision, the board of the company defines the strategic (e.g. reputation, market share) and financial objectives (e.g. earnings growth, sales targets).</p>
<p>2. Environmental analysis</p>
<p>The environmental analysis may include the following activities:</p>
<ul>
  <li>Internal analysis of the enterprise</li>
  <li>Analysis of the enterprise's industry</li>
  <li>A PEST Analysis (Political, Economic, Social, and Technological factors). It is very important that an organization considers its environment before beginning the marketing process. In fact, environmental analysis should be continuous and feed all aspects of planning, identify the strengths and weaknesses, the opportunities and threats (SWOT).</li>
</ul>
<p>3. Strategy definition</p>
<p>Based on the previous activities, the enterprise matches strengths to opportunities and addressing its weaknesses and external threats and elaborate a strategic plan. This plan may then be refined at different levels in the enterprise. Below is a diagram explaining the various levels of plans.</p>
<br><div align="center"><img src="/images/articles/strategy_definition.jpg" alt="Strategy Definition"></div><br>
<p>To build that strategy, an Enterprise Strategy Model may be used to represent the Enterprise situation accurately and realistically for both past and future views. This can be based on Business Motivation Modeling (BMM) which allows developing, communicating and managing a Strategic Plan. Another possibility is the use of Business Model Canvas which allows the company to develop and sketch out new or existing business models. (Refer to the work from Alexander Osterwalder <a href="http://alexosterwalder.com/" target="_blank">http://alexosterwalder.com/</a>).</p>
<p>The model’s analyses should consider important strategic variables such as customers demand expectations, pricing and elasticity, competitor behavior, emissions regulations, future input, and labor costs.</p>
<p>These variables are then mapped to the main important business processes (capacity, business capabilities, constraints), and economic performance to determine the best decision for each scenario. The strategic model can be based on business processes such as customer, operation or background processes. Scenarios can then are segmented and analyzed by customer, product portfolio, network redesign, long term recruiting and capacity, mergers and acquisitions to describe Segment Business Plans.</p>
<p>4. Strategy Implementation</p>
<p>The selected strategy is implemented by means of programs, projects, budgets, processes and procedures. The way in which the strategy is implemented can have a significant impact on whether it will be successful, and this is where Enterprise Architecture may have a significant role to play. Often, the people formulating the strategy are different from those implementing it. The way the strategy is communicated is a key element of the success and should be clearly explained to the different layers of management including the Enterprise Architecture team.</p>
<p>To support that strategy, different levels or architecture can be considered such as strategic, segment or capability architectures.</p>
<br><div align="center"><img src="/images/articles/summary_classification_model_for_architecture_landscapes.jpg" alt="Summary Classification Model for Architecture Landscapes"></div><br>
<p>This diagram below illustrates different examples of new business capabilities linked to a Strategic Architecture.</p>
<br><div align="center"><img src="/images/articles/new_business_capabilities_linked_to_a_strategic_architecture.jpg" alt="New business capabilities linked to a Strategic Architecture"></div><br>
<p>It also illustrates how Strategic Architecture supports the enterprise’s vision and the strategic plan communicated to an Enterprise Architecture team.</p>
<p>Going to the next level allows better detail the various deliverables and the associated new business capabilities. The segment architecture maps perfectly to the Segment Business Plan.</p>
<br><div align="center"><img src="/images/articles/segment_architecture_maps_perfectly_to_the_segment_business_plan.jpg" alt="Segment architecture maps perfectly to the Segment Business Plan"></div><br>
<p>5. Evaluation and monitoring</p>
<p>The implementation of the strategy must be monitored and adjustments made as required.</p>
<p>Evaluation and monitoring consists of the following steps:</p>
<ol>
  <li>Definition of  KPIs, measurement and metrics</li>
  <li>Definition of  target values for these KPIs</li>
  <li>Perform measurements</li>
  <li>Compare measured results to the pre-defined standard</li>
  <li>Make necessary changes</li>
</ol>
<p>Strategic Planning and Enterprise Architecture should ensure that information systems do not operate in a vacuum. At its core, TOGAF 9 uses/supports a strong set of guidelines that were promoted in the previous version, and have surrounded them with guidance on how to adopt and apply TOGAF to the enterprise for Strategic Planning initiatives. The ADM diagram below clearly indicates the integration between the two processes.</p>
<p>The company’s mission and vision must be communicated to the Enterprise Architecture team which then maps Business Capabilities to the different Business Plans levels.</p>
<br><div align="center"><img src="/images/articles/adm_business_capabilities_and_business_plans.jpg" alt="ADM business capabilities and business plans.jpg"></div><br>
<p>Many Enterprise Architecture projects are focused at low levels but should be aligned with Strategic Corporate Planning. Enterprise Architecture is a critical discipline, one Strategic Planning mechanism to structure an enterprise. TOGAF 9 is without doubt an effective framework for working with stakeholders through Strategic Planning and architecture work, especially for organizations who are actively transforming themselves.</p>]]></description>
<link>http://www.architecting-the-enterprise.com/enterprise_architecture/articles/how_strategic_planning_relates_to_enterprise_architecture.php</link>
<guid isPermaLink='true'>http://www.architecting-the-enterprise.com/enterprise_architecture/articles/how_strategic_planning_relates_to_enterprise_architecture.php</guid>
<pubDate>Wed, 29 Jun 2011 09:51:54 GMT</pubDate>
</item>

<item>
<title>Leadership - Environment, behaviour and personality</title>
<description><![CDATA[<p>In last month’s article we discussed the role of power in organizations and how this relates to organizational culture. We also discussed the significant impact that politics and culture can have on productivity. Therefore many personal attributes of successful IT Managers and Enterprise Architects have to do with politics and the ability to inspire respect, build teams and shape culture. This article describes the key attributes and behaviors commonly associated with successful leaders.</p>
<h2>Leadership and environment</h2>
<p>People who are a successful leader in one situation are not necessarily successful in another situation. Different organizations are likely to require different styles of leadership and organizations may need various leadership styles during their lifespan. Leadership crises within fast changing environments is most prevalent in start-ups. Entrepreneurial leaders often compromise their business when they move from innovative to professional leadership, which is one of the largest failure factors of young organizations. They never learn to delegate and give responsibility to management and get submerged in the business detail of their creation. It is therefore important for successful leaders to have a strong awareness of the changing environment and situation they are in. Some leadership theories (such as situational and contingency theories) believe that the environment is one of the most important aspects of leadership and determines how leaders will act.</p>
<h2>Leadership and behaviour</h2>
<p>Although the environment is an important factor, you can still make a decision how to act in certain situations. Kurt Lewin, a German-American psychologist, was one of the pioneers of the behavioural approach. He identified three types of leaders based on how they made decisions: <i>Autocratic leaders</i> who make decisions without consulting; <i>Democratic leaders</i> who make decisions after input from their team; and <i>Laissez-faire leaders</i> who leave decision making largely to their teams. The approach clearly describes associated environments so that you can choose which behavior to employ in which situation. For example, Laissez-faire leaders would be most effective in situations where teams are highly motivated and capable and don’t need close supervision.</p>
<p>Another widely used model based on the behavior approach was developed by Robert Blake and Jane Mouton. Their Managerial Grid helps you decide what leadership style to use, depending on your concern for people versus your concern for production or task. They defined five leadership styles; <i>country-club</i> style, <i>team</i> style, <i>middle-of-the-road</i> style, <i>impoverished</i> style, and produce-or-perish style. Each style helps you understand your own leadership behavior and how to change it to meet the needs of the situation.</p>
<h2>Leadership and personality</h2>
<p>Many other models have been developed based on the behavioral approach and it is clear that the most successful leaders are those who are able to adapt their behavior to the situation they are in. New research based on statistical analysis across many leadership studies confirms this; it shows that individuals can emerge as leaders across many situations and tasks. Also, it shows that there is a strong relationship between leadership behavior and personality characteristics. This leads to the <i>Trait theory</i>, which argues that successful leaders share a number of personality characteristics. Obviously, the world of today is completely different from the recent past. Your ability to influence is far more important today than twenty years ago when seniority, position and status were more important. Also, leadership across cultures, as a result of further globalization, requires a very different set of competencies. So what are the main characteristics of highly successful leaders today?</p>
<h2>Intelligence Quotient</h2>
<p>IQ tests have long been part of the instruments of recruitment officers to "filter" applicants for leadership positions. IQ refers to pure cognitive ability and is one of the factors that determines whether you will be able to become a successful leader. However, IQ is a threshold, you need a certain amount of it to be able to succeed but IQ alone doesn’t get you there.</p>
<h2>Technical skills</h2>
<p>People in your team will look to you for information and experience. It will be much harder to build credibility and trust without this. If you lead an enterprise architecture team and don’t have a clue about the subject, then it will be almost impossible to build a collaborative team and align the team with the direction of your organization. But, again, technical skills alone don’t get you there.</p>
<h2>Analytical and Coordination skills</h2>
<p>Even more important than your IQ and technical skills are your analytical and coordination skills. Many of you will move from individual contributors in teams to leaders of teams. As an individual contributor you are dependent on your own knowledge, skills and experience. As a leader you are dependent on other people’s knowledge, skills and experience. Your ability to coordinate other people’s capabilities becomes more important than your own capability. Remember what organizations are in the first place; <i>“organizations are tools that permit groups of human beings to aim at and achieve goals that would be far beyond the reach of their powers as individuals”</i> (see last month’s article about <a href="http://www.architecting-the-enterprise.com/enterprise_architecture/articles/leadership_-_power_and_politics.php">Power and Politics</a>). As a leader you have to align people’s interest with the direction of the organisation and create collaborative teams. Moreover, you need to be able to see your team within the fabric of the whole organisation.</p>
<h2>Interpersonal skills</h2>
<p>While IQ and technical skills are threshold capabilities, interpersonal skills will often set you apart as a leader. Personality, attitude and associated behaviour are key. Your personality is jointly influenced by genetics and environmental factors such as family, culture, and social status. Personality is not static but the way we think, feel and behave continues to evolve over your lifetime.  It is largely a social construct and relates to how we interact with and influence other people. So what does the personality profile of a successful leader look like?</p>
<h2>Behaviours of successful leaders</h2>
<p>There is potentially an unlimited amount of characteristics that can be used to describe personality. Many of these characteristics show a reliable correlation so we can group them into aggregated dimensions. A good example of this is the widely accepted Five Factor Model (FFM) which uses five broad dimensions to describe personality.  These five factors are Openness, Conscientiousness, Extraversion, Agreeableness and Neuroticism. Each factor contains a cluster of correlated specific personality characteristics. Together they can provide an accurate description of your personality. Psychiatrists use their own additional personality descriptions to make assessments and diagnoses, such as narcissistic, paranoid, schizotypical, antisocial, sadistic, passive-aggressive and obsessive-compulsive. In this article we limit ourselves to the key common characteristic dimensions that are found in successful global leaders:</p>
<h3>Direction Setting</h3>
<p>Direction setting is your ability to communicate and instill a clear compelling direction for the organization, for all stakeholders, across multiple functions and across different cultures. This requires a global mindset and strong awareness of economics and politics. You should also feel comfortable in multi-cultural teams, be able to shape culture and instill trust across the organization.</p>
<h3>Team building</h3>
<p>Building teams is a large component of the overall capabilities of a leader. Aligning people with the vision of the organization and building collaborative teams with associated management structures, ownership, responsibility and accountability will be essential. You will be a role model and need to know how to inspire people and energize teams.</p>
<h3>Conscientiousness</h3>
<p>Conscientiousness is used in many psychometric tests because it is a very good predictor of performance. It relates to your ability to motivate yourself, show self-discipline, tenacity, carefulness, aim for achievement, thoroughness and organization. Or in other words, whether you are efficient and organized. You will need to be role model in your team and you will need to set a personal example that employees respect, trust and follow.</p>
<h3>Emotional Intelligence (EI)</h3>
<p>Emotional Intelligence is vital and probably the most important dimension for effective and successful leaders. Those who are emotional intelligent are very likely to become better leaders. According to Peter Salovey and John Mayer (1990) emotional intelligence is “a form of social intelligence that involves the ability to monitor ones own and others feelings and emotions, to discriminate among them, and to use this information to guide ones thinking and action.” Their model has five domains: self-awareness, self-management, motivation, empathy and social skills.</p>
<p>Daniel Goleman popularized the term emotional intelligence in the mid-90s and claimed that EI was very powerful in predicting life success. He first agreed with Salovey and Mayer’s five domains but later simplified these into four domains where motivation is merged into the other four domains:</p>
<ol>
  <li><i>Self-awareness</i> – the awareness of your moods and emotions. This is the first step to self-management. If you are not aware of your emotions then it is very hard to manage them.</li>
  <li><i>Self-management</i> – this involves controlling emotions and using your emotions selectively in communication; adapting to changing circumstances.</li>
  <li><i>Social awareness</i> – this is your awareness to others' emotions and perspectives.</li>
  <li><i>Relationship management</i> – this is your ability to inspire, influence, and develop others while managing conflict. This comes down to your social skills and empathy.</li>
</ol>
<h2>What can you do to improve?</h2>
<p>In my April article called <a href="http://www.architecting-the-enterprise.com/enterprise_architecture/articles/leadership:_how_to_get_to_the_top.php">“Leadership – how to get to the top”</a>, I described various ways to improve your leadership. Same as overall leadership development, becoming more emotionally intelligent is an experiential process. You can only become a better leader by being a leader. It is a long term commitment. If you are an introvert today then don’t expect to become an extrovert overnight. Your success depends on other people so involve them in your development.</p>
<p>-- <i>He was a self-made man who owed his lack of success to nobody</i> -- (Joseph Heller).</p>]]></description>
<link>http://www.architecting-the-enterprise.com/enterprise_architecture/articles/leadership_-_environment,_behaviour_and_personality.php</link>
<guid isPermaLink='true'>http://www.architecting-the-enterprise.com/enterprise_architecture/articles/leadership_-_environment,_behaviour_and_personality.php</guid>
<pubDate>Tue, 28 Jun 2011 09:51:53 GMT</pubDate>
</item>

<item>
<title>Leadership - Power and Politics</title>
<description><![CDATA[<p>In last month’s article, <a href="http://www.architecting-the-enterprise.com/enterprise_architecture/articles/leadership:_how_to_get_to_the_top.php" target="_blank">Leadership: How to get to the top,</a> we discussed the changing landscape of leadership and the various approaches you can take to becoming a better leader. We still haven’t talked about the key attributes of excellent leaders but before we do that we need to have a closer look at power and politics. Successful IT Managers and Enterprise Architects have the ability to identify power in an organization and thus establish collaborative relationships with and amongst people in their networks. You will need to be aware of your own power sources, how you can increase your power, and how you can use power to influence. This article describes the role of power in organisations and how it relates to culture.</p>   

<h3>Power and politics in organisations</h3>
<p>In order to get an understanding of why power and politics are so important, we first need to have a look at organisations. Herbert Simon (Nobel Laureate in Economics 1978) described organisations as;<i> “tools that permit groups of human beings to aim at and achieve goals that would be far beyond the reach of their powers as individuals”.</i> Groups of human beings do not automatically “organise” themselves towards a common goal. Each person has a different background and has a unique set of capabilities. If we drop a random group of people, one by one, in the middle of the jungle without any direction then everybody is likely to go in a different direction to find the way out.  It is the task of the leader to communicate a clear vision and transform this into reality.  By knowing what exactly is expected of them, employees waste little time in deciding how to act in a given situation.</p> 

<p>As a leader you use power to align people’s interest with the overall vision of the organisation. Power is the ability to get people to do things they wouldn’t do naturally. You need to build collaboration between people with very different backgrounds, especially in global organisations where different cultures and languages add to the diversity. <i>Politics</i> can be described as the <i>use of power to influence your social environment to better achieve your personal and collective goals.</i></p>

<h3>Ambiguity about power</h3>
<p>Power is an inevitable part of the makeup of organisations but you may not be comfortable with the use of power. There is a high level of ambiguity about the use of power. Some people associate the use of power with abuse and therefore avoid the use of it. In fact, the use of power can be perceived as abuse in one situation and can be fully acceptable in another situation. Culture often determines what is acceptable and desirable. It is therefore important for you as a leader to assess your sources of power (your potential to influence), analyse your social environment, and determine what tactics you will use to realise change.</p>

<h3>Your sources of power</h3>
<p>Your individual sources of power can be categorised into <i>personal power</i>, positional power and relational power. Personal power is based on your personal characteristics and skills. This relates to your ability to create cooperation and build collaboration between people. Many of the competencies of excellent leaders relate to this ability, such as visioning, empowering, energising, team building, emotional intelligence, focus, tenacity, tolerance for conflict and resilience to stress. Your experience, charisma and linguistic attributes relate to your ability to get support from others and also add to your personal power.</p>

<p><i>Positional power</i> is based on the formal position you hold in your organisation and social environment. Those at the top of organisations are traditionally seen as having formal authority and therefore having more power. Positional power not only relates to the formal hierarchical position but also to the strategic resources you have under control. For example, if you are the only one who has a full understanding of a unique system, critical to your organisation, then that gives you more power than a coworker who is in charge of non-critical systems. Just imagine what would happen if the organisation has to lay-off employees. </p>

<p><i>Relational power</i> is based on your relationships with others. Relationships are not just the number of links that you have on Facebook or LinkedIn but also the quality or strength of the relationships. This requires active investment in relationships so you will have to choose whom you interact with and how. These choices will determine your level of relational power. Other aspects of relational power are based on the connections between your direct links and the overall structure of your social network. For example, if your direct links are not connected to each other then you are likely to have access to more unique resource bases and therefore you may have more relational power.</p>

<p>Personal, positional and relational power always needs to be considered together to provide maximum support for your influence strategy.</p> 
<h3>Power shapes culture</h3>
<p>Culture and power are highly intertwined. A strong culture needs little influence from management because people have internalised the values of the organisation and can make decisions based on this. People know exactly what is expected of them and know how to act in a given situation. In a weak culture people waste a lot of time trying to find out where the organisation is going, what they should do, what their role is, and how they should do things.</p>

<p>Strong leadership is needed to communicate a clear direction and values to shape culture. These values need to be reinforced in everything the organisation does. This allows people the freedom and trust to act and to execute consistent with these values. Terrence Deal and AlIen Kennedy wrote in their book called <i>Corporate Cultures: The Rites and Rituals of Corporate Life</i>, that the impact of strong culture on productivity is amazing. They estimated that an organisation could gain as much as 25% productivity gain by having a strong culture. </p> 

<p>But be careful, we discussed this in our March issue, changing attitude and behaviour is not an easy task. While top leaders can largely initiate cultural change, it cannot be enforced or mandated. Top leaders can only put the conditions in place for the culture to change. The people in organisations need to change themselves in order for the cultural change to take place.</p> 

<h3>Leadership starts with yourself</h3> 	
<p>Your sources of power are not only based on your position in the organisation (positional power), but also on your personal characteristics and skills (personal power) and your network of relations (relational power). This means that you can start your leadership journey right now and don’t have to wait until you get the position of leader. Carefully assess you individual power, explore your social environment, and determine your influence strategy and tactics. Your ability to influence is larger than you think. It is not about what your position is in your  organisation, it is about your ability to influence. </p>   
]]></description>
<link>http://www.architecting-the-enterprise.com/enterprise_architecture/articles/leadership_-_power_and_politics.php</link>
<guid isPermaLink='true'>http://www.architecting-the-enterprise.com/enterprise_architecture/articles/leadership_-_power_and_politics.php</guid>
<pubDate>Wed, 18 May 2011 09:51:53 GMT</pubDate>
</item>

<item>
<title>Managing Requirements from a Business Analyst or an Enterprise Architect perspective using BABOK 2.0 and or TOGAF(R) 9</title>
<description><![CDATA[<p>Many Business Analysts are using the IIBA’s  BABOK 2.0 (Business Analyst Body of Knowledge ) which contains information about a Requirements Management process, from identifying organizational situations that give cause to a project, through to starting the requirements gathering process, to delivering a solution to the business or a client. TOGAF 9 from an Enterprise Architecture viewpoint also provides some techniques to gather requirements to equally deliver business solutions. This paper illustrates the two processes, defines the mapping between the two approaches and identifies gaps in each.</p>

<br>
<div align="center">
<img src=" http://www.architecting-the-enterprise.com/images/articles/babok_togaf_9_business_analysis_plannings.jpg" alt="BABOK TOGAF 9 Business Analysis Planning">
</div>
<br>

<p>BABOK 2.0 Knowledge Area (KA) 4 covers Requirements Management and Communication which <i>“describes the activities and considerations for managing and expressing Requirements to a broad and diverse audience”</i> (The other KAs: Plan Requirements, Management Process, and Requirement Analysis will not be included here).</p>
<p>The tasks from this KA <i>“are performed to identify business needs</i> (the why of the project; whereas requirements are the how),<i> the state the scope of their business solutions, ensure that all stakeholders have a shared understanding of the nature of these solutions and that those stakeholders with approval authority are in agreement as to the requirements that the business solution shall meets.”</i> </p>
<p>It manages a baseline, tracks different versions of Requirements documents, and traces requirements from origin to implementation.</p>
<p>This area includes five steps described below.</p>

<br>
<div align="center">
<img src=" http://www.architecting-the-enterprise.com/images/articles/babok_5_steps.jpg" alt="BABOK_5_Steps">
</div>
<br>

<h2>1. Manage Solution Scope and Requirements</h2>
<p>In this step, we <i>“obtain and maintain consensus among stakeholders regarding the overall solution scope and the requirements that will be implemented”.</i> Requirements may be baselined following an approval and a signoff. That means that all future changes are recorded and tracked, and the current state may be compared to the baselined state. Subsequent changes to the requirements must follow a Change Management process and will require additional approval. As changes are approved, a Requirements Management Plan may require that the baselined version of the requirements be maintained in addition to the changed Requirement. Additional information is often maintained such as a description of the change, the person who made the change, and the reason for the change. As requirements are refined or changed as the result of new information, changes will be tracked as well.</p>

<br>
<div align="center">
<img src=" http://www.architecting-the-enterprise.com/images/articles/manage_solution_scope_and_requirements.jpg" alt="Manage Solution Scope and Requirements">
</div>
<br>

<p>A signoff formalises an acceptance by all stakeholders that the content and presentation of documented requirements is accurate and complete. This can be done in a face to face meeting.</p>

<h2>2. Manage Requirements Traceability</h2>
<p>Traceability consists of understanding the relationship between Business Objectives, the requirements, the stakeholders, other deliverables and components to support the business analysis among other activities. It also allows documenting <i>“the lineage of each requirement, its backward and forward traceability, and its relationship to other requirements”.</i> The reasons for creating relationships are “Impact Analysis”, and “Requirements coverage and allocation”. A coverage matrix may be used to manage tracing.</p>

<br>
<div align="center">
<img src=" http://www.architecting-the-enterprise.com/images/articles/manage_requirements_traceability.jpg" alt="Manage Requirements Traceability">
</div>
<br>

<h2>3. Maintain Requirements for re-use</h2>
<p>Requirements re-use is another important aspect in the process and there is a need to manage knowledge of requirements following their implementation, identify the requirements that are candidates for long-term usage by the organisation. <i>“These may include requirements that an organisation must meet on an ongoing basis, as well requirements that are implemented part of a solution”</i> (e.g. regulatory, contractual obligations, quality standards, service level requirements, etc.). Each will have to be clearly named, defined, and available to all analysts.</p>

<br>
<div align="center">
<img src=" http://www.architecting-the-enterprise.com/images/articles/maintain_requirements_for_re-use.jpg" alt="Maintain Requirements for re-use">
</div>
<br>

<h2>4. Prepare Requirements Package</h2>
<p>This step consists in selecting and structuring a set of requirements <i>“in an appropriate fashion to ensure that the requirements are effectively communicated to, understood and usable”</i> by the various stakeholders. The Requirements Package could have different forms such as documentation (can be managed in a Requirements Repository), presentations, templates, etc.</p>

<br>
<div align="center">
<img src=" http://www.architecting-the-enterprise.com/images/articles/prepare_requirements_package.jpg" alt="Prepare Requirements Package">
</div>
<br>

<h2>5. Communicate Requirements</h2>
<p>This step relates to the communication of requirements to the various stakeholders for a common understanding. It may happen that new requirements have to be considered.</p>

<br>
<div align="center">
<img src=" http://www.architecting-the-enterprise.com/images/articles/communicate_requirements.jpg" alt="Communicate Requirements">
</div>
<br>

<p>The BABOK bundles Requirements Communication together with Requirements Management.</p>
<p>Requirements Analysis is another KA which describes <i>“how we progressively elaborate the solution definition in order to enable the project team to design and build a solution that will meet the needs of the business and stakeholders. In order to do that, we have to analyze the stated requirements of our stakeholders to ensure that they are correct, assess the current state of the business to identify and recommend improvements, and ultimately verify and validate the results”.</i> BABOK 2.0 Requirements Analysis being not really covered within TOGAF 9, there are no comparisons done at this stage.</p>
<p>Within TOGAF 9, the objective of the Requirements Management activity is to define a process whereby all kinds of requirements, including most notably business drivers, concerns, and new functionality and change requests for Enterprise Architecture are identified, stored, and fed into and out of the relevant Architecture Development Method (ADM) phases.  As such it forms part of the activities and steps carried out in each of the ADM Phases. Architecture requirements are subject to constant change, and requirement management happens throughout the entire Enterprise Architecture implementation lifecycle.</p>
<p>It is important to note that the Requirement Management circle denotes not a static set of requirements but a dynamic process.</p>
<p>As indicated by the Requirements Management circle at the centre of the ADM graphic, the ADM is continuously driven by the Requirements Management process.</p>

<br>
<div align="center">
<img src=" http://www.architecting-the-enterprise.com/images/articles/togaf_9_adm.jpg" alt="TOGAF® 9 ADM">
</div>
<br>

<p>Enterprise Architecture has specific techniques to gather requirements. TOGAF as a framework uses a method based on what we call a “Business Scenario” which is used heavily in the initial phases A & B of the ADM to define the relevant business requirements and build consensus with business management and other stakeholders.</p>
<p>A Business Scenario ensures that there is a complete description of business problem in business and architectural terms. Individual requirements are viewed in relation to one another in the context of the overall problem; the architecture is based on complete set of requirements that add up to a whole problem description; the business value of solving the problem is clear and the relevance of potential solutions is clear.</p>
<p>Below is a mapping between the 2 approaches.</p>
<br>
<div align="center">
  <table width="97%" border="1px">
    <tr>
      <th width="24%">BABOK 2.0 Knowledge Area (KA) 4</th>
      <th width="24%"> </th>
      <th width="24%"> </th>
	  <th width="1%" style="background-color: #FFFFFF";> </th>
      <th width="24%">TOGAF 9</th>
    </tr>
    <tr>
      <td valign="top" style="background-color: #FFCC66";>Requirement Management and Communication</td>
      <td valign="top" style="background-color: #FFCC66";> </td>
      <td valign="top" style="background-color: #FFCC66";> </td>
	  <td valign="top" style="background-color: #FFFFFF";> </td>
      <td valign="top" style="background-color: #c2d69a";>ADM Architecture Requirements Management</td>
    </tr>
    <tr>
      <td valign="top" style="background-color: #FFCC66";> </td>
      <td valign="top" style="background-color: #FFCC66";>Manage Solution Scope and Requirements</td>
      <td valign="top" style="background-color: #FFCC66";>Baseline and current state</td>
	  <td valign="top" style="background-color: #FFFFFF";> </td>
      <td valign="top" style="background-color: #c2d69a";>This is similar and documented as a Step 2 and 3 in the suggested process</td>
    </tr>
    <tr>
      <td valign="top" style="background-color: #FFCC66";> </td>
      <td valign="top" style="background-color: #FFCC66";> </td>
      <td valign="top" style="background-color: #FFCC66";>Change process, approval, signoff</td>
	  <td valign="top" style="background-color: #FFFFFF";> </td>
      <td valign="top" style="background-color: #FFFF00";>There is not a formal approval and signoff</td>
    </tr>
    <tr>
      <td valign="top" style="background-color: #FFCC66";> </td>
      <td valign="top" style="background-color: #FFCC66";> </td>
      <td valign="top" style="background-color: #FFCC66";>Requirement Management Plan</td>
	  <td valign="top" style="background-color: #FFFFFF";> </td>
      <td valign="top" style="background-color: #c2d69a";>We may consider that the management of the solution scope is addressed in the Phase A: Architecture Vision with the Business Scenario</td>
    </tr>
    <tr>
      <td valign="top" style="background-color: #FFCC66";> </td>
      <td valign="top" style="background-color: #FFCC66";> </td>
      <td valign="top" style="background-color: #FFCC66";>Stakeholder list roles and responsibilities</td>
	  <td valign="top" style="background-color: #FFFFFF";> </td>
      <td valign="top" style="background-color: #c2d69a";>In Phase A: Architecture Vision, we do Stakeholder Management in the step: Indentify Stakeholder Concerns & Requirements</td>
    </tr>
    <tr>
      <td valign="top" style="background-color: #FFCC66";> </td>
      <td valign="top" style="background-color: #FFCC66";> </td>
      <td valign="top" style="background-color: #FFCC66";>Requirement Status</td>
	  <td valign="top" style="background-color: #FFFFFF";> </td>
      <td valign="top" style="background-color: #FFFF00";>There are no status defined (modelled, stated, specified, etc)</td>
    </tr>
    <tr>
      <td valign="top" style="background-color: #FFCC66";> </td>
      <td valign="top" style="background-color: #FFCC66";> </td>
      <td valign="top" style="background-color: #FFCC66";>Communication</td>
	  <td valign="top" style="background-color: #FFFFFF";> </td>
      <td valign="top" style="background-color: #FFFF00";>Not formally defined</td>
    </tr>
    <tr>
      <td valign="top" style="background-color: #FFCC66";> </td>
      <td valign="top" style="background-color: #FFCC66";>Manage Requirements Traceability</td>
      <td valign="top" style="background-color: #FFCC66";>Traceability between requirements and business objectives</td>
	  <td valign="top" style="background-color: #FFFFFF";> </td>
      <td valign="top" style="background-color: #FFFF00";>Not formally defined</td>
    </tr>
    <tr>
      <td valign="top" style="background-color: #FFCC66";> </td>
      <td valign="top" style="background-color: #FFCC66";>Maintain Requirements for re-use</td>
      <td valign="top" style="background-color: #FFCC66";>Organisational Process Assets</td>
	  <td valign="top" style="background-color: #FFFFFF";> </td>
      <td valign="top" style="background-color: #FFFF00";>Not formally defined</td>
    </tr>
    <tr>
      <td valign="top" style="background-color: #FFCC66";> </td>
      <td valign="top" style="background-color: #FFCC66";>Prepare Requirements package</td>
      <td valign="top" style="background-color: #FFCC66";>BA Communication Plan</td>
	  <td valign="top" style="background-color: #FFFFFF";> </td>
      <td valign="top" style="background-color: #c2d69a";>A Communication plan is delivered at the end of the Phase A: Architecture Vision</td>
    </tr>
    <tr>
      <td valign="top" style="background-color: #FFCC66";> </td>
      <td valign="top" style="background-color: #FFCC66";> </td>
      <td valign="top" style="background-color: #FFCC66";>Organisational Process Assets</td>
	  <td valign="top" style="background-color: #FFFFFF";> </td>
      <td valign="top" style="background-color: #FFFF00";>Not formally defined</td>
    </tr>
    <tr>
      <td valign="top" style="background-color: #FFCC66";> </td>
      <td valign="top" style="background-color: #FFCC66";> </td>
      <td valign="top" style="background-color: #FFCC66";>Requirements</td>
	  <td valign="top" style="background-color: #FFFFFF";> </td>
      <td valign="top" style="background-color: #FFFF00";>There are no requirements packages and no templates</td>
    </tr>
    <tr>
      <td valign="top" style="background-color: #FFCC66";> </td>
      <td valign="top" style="background-color: #FFCC66";> </td>
      <td valign="top" style="background-color: #FFCC66";>Requirements Structure</td>
	  <td valign="top" style="background-color: #FFFFFF";> </td>
      <td valign="top" style="background-color: #FFFF00";>Not formally defined</td>
    </tr>
    <tr>
      <td valign="top" style="background-color: #FFCC66";> </td>
      <td valign="top" style="background-color: #FFCC66";>Communicate Requirements</td>
      <td valign="top" style="background-color: #FFCC66";>BA Communications Plan</td>
	  <td valign="top" style="background-color: #FFFFFF";> </td>
      <td valign="top" style="background-color: #c2d69a";>A communication plan is delivered at the end of the Phase A: Architecture Vision</td>
    </tr>
    <tr>
      <td valign="top" style="background-color: #FFCC66";> </td>
      <td valign="top" style="background-color: #FFCC66";> </td>
      <td valign="top" style="background-color: #FFCC66";> </td>
	  <td valign="top" style="background-color: #FFFFFF";> </td>
      <td valign="top" style="background-color: #FFFF00";>It does not formally specify requirements</td>
    </tr>
    <tr>
      <td valign="top" style="background-color: #FFCC66";> </td>
      <td valign="top" style="background-color: #FFCC66";> </td>
      <td valign="top" style="background-color: #FFCC66";>Requirements</td>
	  <td valign="top" style="background-color: #FFFFFF";> </td>
      <td valign="top" style="background-color: #c2d69a";>There are no requirements packages and no templates, however they are globally documented and probably validated at the end of the Architecture Vision's Phase</td>
    </tr>
    <tr>
      <td valign="top" style="background-color: #FFCC66";> </td>
      <td valign="top" style="background-color: #FFCC66";> </td>
      <td valign="top" style="background-color: #FFCC66";>Requirements package</td>
	  <td valign="top" style="background-color: #FFFFFF";> </td>
      <td valign="top" style="background-color: #FFFF00";>Not formally defined</td>
    </tr>
    <tr>
	  <td valign="top" border="0" style="border: none; background-color: #FFFF00";>Yellowboxes</td>
      <td valign="top"  border="0" style="border: none;">TOGAF as a framework is not prescriptive and as a result does not set out to define some of the parameters mentioned</td>
      <td valign="top" border="0" style="border: none;"> </td>
      <td valign="top" border="0" style="border: none;"> </td>
	  <td valign="top" border="0" style="border: none;"> </td>
    </tr>
    <tr>
      <td valign="top" border="0" style="border: none;"> </td>
	  <td valign="top" border="0" style="border: none;">Differences are in yellow</td>
      <td valign="top" border="0" style="border: none;"> </td>
      <td valign="top" border="0" style="border: none;"> </td>
      <td valign="top" border="0" style="border: none;"> </td>

    </tr>
  </table>
</div>
<br>
<p>BABOK  2.0 sets up a framework for the requirements development and management, which seems to appear as a standard used by many organizations around the world.  Between TOGAF 9 and BABOK 2.0, there is almost 1:1 correspondence but there may be more details and activities in the first one. TOGAF is a methodology whereas the BABOK is methodology agnostic, so it can be tricky to translate between the two but nothing prevents an Enterprise Architecture team to use this analogous technique.</p>
<p>If an organization follows the TOGAF methodology and Business Analysts usee BABOK, the latter will provide a lot of useful information, as a reference; BABOK won't give you direction for an Enterprise Architecture.</p>
<p>Sources: Chapter 4 IIBA’s  BABOK 2.0, TOGAF 9</p>
]]></description>
<link>http://www.architecting-the-enterprise.com/enterprise_architecture/articles/managing_requirements_from_a_business_analyst_or_an_enterprise_architect_perspective_using_babok_2.0_and_or_togaf_9.php</link>
<guid isPermaLink='true'>http://www.architecting-the-enterprise.com/enterprise_architecture/articles/managing_requirements_from_a_business_analyst_or_an_enterprise_architect_perspective_using_babok_2.0_and_or_togaf_9.php</guid>
<pubDate>Fri, 13 May 2011 09:51:52 GMT</pubDate>
</item>

<item>
<title>Leadership - How to get to the top</title>
<description><![CDATA[<p>In last month’s article, <a href="http://www.architecting-the-enterprise.com/enterprise_architecture/articles/leadership:_changing_the_dialogue.php" target="_blank">Leadership: Changing the Dialogue,</a> we explored the external challenges that CIO’s, IT managers and EA’s typically face when climbing the career ladder. Their experience, knowledge and skills acquired in the IT functional domain are not sufficient for a job at executive level anymore. Leadership across functional domains and across cultures requires strong leadership and deep business understanding.  Traditional business and industry boundaries start to disappear and new business eco-systems emerge. This requires an increased focus on strategic thinking and value creation.</p>
<p>The leadership landscape itself is changing as well. In this article we will explore the changing leadership landscape and what you can do to develop your leadership capability.</p>
<h2>The changing Leadership landscape</h2>
<p>My daughter was sitting on the sofa with her computer one day and told me “Daddy, I love my computer”. Excited about her interest in technology I responded “That’s great my dear, but why do you love your computer?”  She answered “Because all my friends are in it”. Although this was an isolated remark, it illustrates a key generational shift in the perception of technology. In my executive leadership development courses I see the same paradigm shift. New generations, such as the Generation Y and the Millennials, have a distinct different expectation from leadership than earlier generations.</p>
<p>Last year Baby Boomers (1946-1965) began reaching age 65 in the US. According to the U.S. Census Bureau, nearly 76 million people, one-fourth of all Americans, were born between 1946 and 1964. Never before in history have we seen such a generational transition. Worldwide, the population of 60 and over has increased by 10.4 million between 2007 and 2009. This is an average increase of 30,000 each day and this trend started to accelerate last year.</p>
<p>Generation X is about half the size of Baby Boomers and will never be able to fill the gap that the Baby Boomers will leave behind. This means that Generation Y has to accelerate their leadership development to backfill Generation X. Moreover, earlier generations will need to start managing Generation Y employees who, as I mentioned earlier, have distinct different expectations from their leadership.</p>
<p>The good news is that these changing demographics may accelerate your path to a leadership role but it will not come automatically, you will need to prepare for it.</p>
<h2>How to become a great leader</h2>
<p>Contradictory to many leadership books, not everybody will be able to become a great leader. Your personal predisposition for leadership determines for a large part whether you will make it or not. Capability can be changed through training and development but personality is not easy to change. It has been developed mostly in your early youth and when you grew up. With bad attitude, behaviour and character, leadership capability can even become very dangerous. Leadership is a life long journey through self-reflection, self-awareness, and self-discipline. It is as much about what you do every day as what you are. There is no quick fix.</p>
<p>So what can you do to become a better leader.</p>
<h2>Leadership by the book</h2>
<p>When you go for a long flight you can quickly go to the self-help section of the airport bookshop and pick up a book on how to become a great leader. This may provide some great knowledge and insights into leadership, and it definitely is a good start, but please don’t expect to be a great leader when you leave the plane at arrival. This would be the same as reading a book on weight loss and expecting to turn instantly into a needle. It often comes down to changing behaviour and habits, which, for many, can be very hard to achieve.</p>
<h2>Leadership by example</h2>
<p>Another approach to leadership development is to imitate others. Most of us have imitated our parents or care-givers when growing up so we have a natural tendency to imitate others. Leadership forums with living examples and leadership courses can provide good additional support above reading a book. However these forums and courses are often at arm’s-length. Short courses can provide a sense of achievement and comfort in the short term but often don’t provide the long term behavioural changes that are needed. Many people fall back into their old behaviour shortly after they have finished the course. It is not for nothing that one of the key leadership ingredients is “Tenacity”, something that you need plenty of to make this work.</p>
<h2>Interactive coaching experience</h2>
<p>The best way to develop your leadership capability is to learn from interactive coaching experiences. Sharing and analysing your own behaviour, and then working on an action plan to improve this has shown to be a very effective way to develop your leadership capability.  Moreover, a coach will not only provide strong motivation but will also provide a strong sense of accountability. Many great leaders of today have a coach in the background. You only have to think about tv programs, such as “The biggest loser” to appreciate the value of interactive coaching experiences. Many participants in this program have tried every weight-loss program under the sun without success.</p>
<h2>So what next?</h2>
<p>Leadership development is a deep journey into yourself. It is very hard work and a lifelong journey.  You have to make a conscious choice, take charge of your destiny and be self-accountable, it’s your life. If you don’t take charge, someone else will, or life will take charge of you.</p>]]></description>
<link>http://www.architecting-the-enterprise.com/enterprise_architecture/articles/leadership_-_how_to_get_to_the_top.php</link>
<guid isPermaLink='true'>http://www.architecting-the-enterprise.com/enterprise_architecture/articles/leadership_-_how_to_get_to_the_top.php</guid>
<pubDate>Wed, 20 Apr 2011 09:51:51 GMT</pubDate>
</item>

<item>
<title>Creation of a strategy for the consumption and management of Cloud Services in the TOGAF(R) Preliminary Phase</title>
<description><![CDATA[<p>In a previous article, <a href="http://www.architecting-the-enterprise.com/enterprise_architecture/articles/cloud_computing_requires_enterprise_architecture_and_togaf_9_can_show_the_way.php">Cloud Computing requires Enterprise Architecture and TOGAF® 9 can show the way</a> I described the need to define a strategy as an additional step in the TOGAF 9 Preliminary Phase. This article describes in more details what could be the content of such a document, specifically, what are the governance activities related to the Consumption and Management of Cloud Services.</p>
<br><div align="center"><img src="/images/articles/consumption_and_management_of_cloud_services.jpg" alt="Consumption and Management of Cloud Services"></div><br>
<p>Before deciding to switch over to Cloud Computing, companies should first fully understand the concepts and implications of an internal IT investment or buying this as a service. There are different approaches which may have to be considered from an enterprise level when Cloud computing is considered: Public Cloud vs. Private Clouds vs. Hybrid Clouds. Despite the fact that many people already know what the differences are, below are some summaries of the various models:</p>
<ul>
  <li>A public Cloud is one in which the consumer of Cloud services and the provider of Cloud services exist in separate enterprises. The ownership of the assets used to deliver cloud services remains with the provider</li>
  <li>A private Cloud is one in which both the consumer of Cloud services and the provider of those services exist within the same enterprise. The ownership of the Cloud assets resides within the same enterprise providing and consuming cloud services. It is really a description of a highly virtualized, on-premise data center that is behaving as if it were that of a public cloud provider</li>
  <li>A hybrid Cloud combines multiple elements of public and private cloud, including any combination of providers and consumers</li>
</ul>
<br><div align="center"><img src="/images/articles/a_hybrid_cloud.jpg" alt="A Hybrid Cloud"></div><br>
<p>Once the major Business stakeholders understand the concepts, some initial decisions may have to be made and included in that document. The same may also apply to the various Cloud Computing categorisations such as diagrammed below:</p>
<br><div align="center"><img src="/images/articles/cloud_computing_categorisations.jpg" alt="Cloud Computing Categorisations"></div><br>
<p>The categories the enterprise may be interested in related to existing problems can already be included as a section in the document.</p>
<h2>Quality Management</h2>
<p>There is need of a system for evaluating performance, whether in the delivery of Cloud services or the quality of products provided to consumers, or customers. This may include:</p>
<ul>
  <li>A test planning and a test asset management from Business requirements to defects</li>
  <li>A Project governance and release decisions based on some standards such as Prince 2/PMI and ITIL</li>
  <li>A Data quality control (all data uploaded to a Cloud computing service provider must ensure it fits the requirements of the provider). This should be detailed and provided by the provider</li>
  <li>Detailed and documented Business Processes as defined in ISO 9001:
    <ul>
      <li>Systematically defining the activities necessary to obtain a desired result</li>
      <li>Establishing clear responsibility and accountability for managing key activities</li>
      <li>Analyzing and measuring of the capability of key activities</li>
      <li>Identifying the interfaces of key activities within and between the functions of the organization</li>
      <li>Focusing on the factors such as resources, methods, and materials that will improve key activities of the organization</li>
      <li>Evaluating risks, consequences and impacts of activities on customers, suppliers and other interested parties</li>
    </ul>
  </li>
</ul>
<h2>Security Management</h2>
<p>This would address and document specific topics such as:</p>
<ul>
  <li>Eliminating the need to constantly reconfigure static security infrastructure for a dynamic computing environment</li>
  <li>Define how services are able to securely connect and reliably communicate with internal IT services and other public services</li>
  <li>Penetration security checks</li>
  <li>How a Security Management/System Management/Network Management teams monitor that security and the availability</li>
</ul>
<h2>Semantic Management</h2>
<p>The amount of unstructured electronic information in an enterprise environments is growing rapidly. Business people have to collaboratively realise the reconciliation of their heterogeneous metadata and consequently the application of the derived business semantic patterns to establish alignment between the underlying data structures. The way this will be handled may also be included.</p>
<h2>IT Service Management (ITIL)</h2>
<p>IT Service Management or IT Operations teams will have to address many new challenges due to the Cloud. This will need to be addressed for some specific processes such as:</p>
<ul>
  <li>Incident Management
    <ul>
      <li>The Cloud provider must ensure that all outages or exceptions to normal operations are resolved as quickly as possible while capturing all of the details for the actions that were taken and are communicated to the customer.</li>
    </ul>
  </li>
  <li>Change Management
    <ul>
      <li>Strict change management practices must be adhered to and all changes implemented during approved maintenance windows must be tracked, monitored, and validated.</li>
    </ul>
  </li>
  <li>Configuration Management (Service Asset and...)
    <ul>
      <li>Companies who have a CMDB must provide this to the Cloud providers with detailed descriptions of the relationships between configuration items (CI)</li>
      <li>CI relationships empowers change and incident managers need to determine that a modification to one service may impact several other related services and the components of those services</li>
      <li>This provides more visibility into the Cloud environment, allowing consumers and providers to make more informed decisions not only when preparing for a change but also when diagnosing incidents and problems</li>
    </ul>
  </li>
  <li>Problem Management
    <ul>
      <li>The Cloud provider needs to identify the root cause analysis in case ofr problems</li>
    </ul>
  </li>
</ul>
<br><div align="center"><img src="/images/articles/the_cloud_provider_needs_to_identify_the_root_cause_analysis.jpg" alt="The Cloud provider needs to identify the Root Cause Analysis"></div><br>
<ul>
  <li>Service Level Management
    <ul>
      <li>Service Level Agreements (or Underpinning contracts) must be transparent and accessible to the end users. The business representatives should be negotiating these agreements. They will need to effectively negotiate commercial, technical, and legal terms. It will be important to establish these concrete, measurable Service Level Agreements (SLAs). Without these, and an effective means for verifying compliance, the damage from poor service levels will only be exacerbated</li>
    </ul>
  </li>
  <li>Service Level Management
    <ul>
      <li>Relationship between a vendor and their customers changes</li>
      <li>Contractual arrangements</li>
    </ul>
  </li>
  <li>Capacity Management and Availability Management
    <ul>
      <li>Reporting on performance</li>
    </ul>
  </li>
</ul>
<p>Other activities must be documented such as:</p>
<h2>Monitoring</h2>
<ul>
  <li>Monitoring will be a very important activity and should be described in the Strategy document. The assets and infrastructure that make up the Cloud service is not within the enterprise. They are owned by the Cloud providers, which will most likely have a focus on maximizing their revenue, not necessarily optimizing the performance and availability of the enterprise’s services. Establishing sound monitoring practices for the cloud services from the outset will bring significant benefits in the long term. Outsourcing delivery of service does not necessarily imply that we can outsource the monitoring of that service. Besides, today very few cloud providers are offering any form of service level monitoring to their customers. Quite often, they are providing the Cloud service but not proving that they are providing that service</li>
  <li>The resource usage and consumption must be monitored and managed in order to support strategic decision making</li>
  <li>Whenever possible, the Cloud providers should furnish the relevant tools for management and reporting and take away the onerous tasks of patch management, version upgrades, high availability, disaster recovery and the like. This obviously will impact IT Service Continuity for the enterprise</li>
  <li>Service Measurement, Service Reporting and Service Improvement processes must be considered</li>
</ul>
<h2>Consumption and costs</h2>
<br><div align="center"><img src="/images/articles/return_on_investment_for_cloud_computing_initiatives.jpg" alt="Return on Investment for Cloud Computing Initiatives"></div><br>
<h2>Risk Management</h2>
<p>The TOGAF 9 risk management method should be considered to address the various risks associated such as:</p>
<ul>
  <li>Ownership, Cost, Scope, Provider relationship, Complexity, Contractual, Client acceptance, etc</li>
  <li>Other risks should also be considered such as : Usability, Security (obviously...) and Interoperability</li>
</ul>
<h2>Asset Management and License Management</h2>
<p>When various cloud approaches are considered (services on-premise via the Cloud), hardware and software license management should be defined to ensure companies can meet their governance and contractual requirements</p>
<h2>Transactions</h2>
<p>Ensuring the safety of confidential data is a mission critical aspect of the business. Cloud computing gives them concerns over the lack of control that they will have over company data, and does not enable them to monitor the processes used to organize the information.</p>
<p>Being able to manage the transactions in the Cloud is vital and Business transaction safety should be considered (recording, tracking, alerts, electronic signatures, etc...).</p>
<p>There may be other aspects which should be integrated in this Strategy document that may vary according to the level of maturity of the enterprise or existing best practices in use.</p>
<p>When considering Cloud computing, the Preliminary phase will include in the definition of the Architecture Governance Framework most of the touch points with other processes as described above. At completion, touch-points and impacts should be clearly understood and agreed by all relevant stakeholders.</p>]]></description>
<link>http://www.architecting-the-enterprise.com/enterprise_architecture/articles/creation_of_a_strategy_for_the_consumption_and_management_of_cloud_services_in_the_togaf_preliminary_phase.php</link>
<guid isPermaLink='true'>http://www.architecting-the-enterprise.com/enterprise_architecture/articles/creation_of_a_strategy_for_the_consumption_and_management_of_cloud_services_in_the_togaf_preliminary_phase.php</guid>
<pubDate>Tue, 22 Mar 2011 09:51:50 GMT</pubDate>
</item>

<item>
<title>Leadership - Changing the dialogue</title>
<description><![CDATA[<p>Many CIO’s, IT Managers, and Enterprise Architects started their career in information technology. Some of you may have spent years at university learning the ins and outs of information science. Others may have picked it up along the way in the form of experience. In both cases you have developed a way to communicate effectively and efficiently with others in the same discipline. Whether you communicate with ER-diagrams, class-diagrams, use-cases or other tools, your language was clear in the IT discipline. This common “language” not only contains cognitive structures, concepts, methods, models and tools, but also cultural elements that provide members with a “sense of belonging”. </p>
<p>This article describes the external challenges that IT people typically face when climbing the career ladder and moving beyond the IT discipline into a management or leadership position.</p>
<h2>Different disciplines, different languages</h2>
<p>Not all people in an organisation speak the same “language”. As an IT’er you may look at an organisation from a “Systems” perspective. You want to make sure that all systems across the enterprise fit well together and match the demands of the business environment. Some may be convinced that IT is the most important discipline because IT is very pervasive and without system support the organisation would not be able to operate.</p>
<p>While this may be true for you, the CFO may not agree with you. Her domain is finance and she may be convinced that “money” is the key component of the business. Without money, she would argue, you would not even have a budget to do IT at all! Finance uses it’s own language to communicate. Finance uses models, such as a chart of accounts, balance sheet, income statement and cash flow statement to manage the business from a financial point of view. This information is distilled into the end of year accounts that provide a window through which financial analysts can determine how well a company is managed. Again, finance is very pervasive and without money the company would be out of business very quickly.</p>
<p>The HRO (Human Resource Officer) may also disagree with you. She may see “people” as the key ingredient of the business. In fact, that’s why we put people together in organisations in the first place, so that organisations can achieve goals that are far beyond the powers of individuals. In the same way as IT, HR uses its own concepts, methods, models, and tools to manage the performance of “people” across the enterprise. HR uses its own optimised “language” to do this very effectively and efficiently. HR may argue that without people it would not be possible to do business … even IT and finance need people!</p>
<br><div align="center"><img src="/images/articles/Business_disciplines_picture.png" alt="Business Disciplines" width="500px" height="173px"></div><br>
<p>Other disciplines, such as marketing, sales, procurement and operations, will also have their own “language” optimised for their field of expertise. This provides some key advantages, such as high efficiency within the disciplines and the ability to develop deep levels of expertise within each discipline. However, this inherently poses some challenges for leaders who climb up the value chain and have to manage across these disciplines. Deep knowledge and experience in one discipline is not a guarantee for success across disciplines.</p>
<h2>Leadership in a complex environment</h2>
<p>Forrester did some research in March 2007 on the response to technology oriented communication at various levels in the business. The findings showed that business, finance and procurement executives had a “Strongly Negative” response to technology oriented messaging. So technically, the information technology “language” did not do the job here. This is one of the reasons why there is often a lack of Business/IT alignment, a recurring issue on the agenda of CIO’s.</p>
<p>You may be lucky and able to put a team together with business analysts who have deep knowledge of the various disciplines and know the “language”, such as finance, HR and production. They should be able to extract the key information out of the disciplines to provide the right systems support. Problem solved! Well … not really. The various disciplines are not independent of each other and do have a high level of dependency that changes continuously. Each discipline is interwoven into the fabric of the business, which makes the picture very complex to manage.</p>
<p>It becomes even more complex when you work for an international organisation. Suddenly you have to deal with management across cultures, not only national cultures, but also corporate cultures, especially in organisations that are a result of mergers and acquisitions. You may even discover that within disciplines, such as IT, people use a different “language” in different locations.</p>
<h2>Political and cultural challenges</h2>
<p>But as good “left brainers”, with a strength in logic, science, facts and strategy, you manage to create a crystal clear picture of what the organisation needs. Industry standards, such as TOGAF and industry frameworks, provide you with excellent guidance to accelerate this process. Very proud to have mapped such a complex environment into a clear enterprise-wide system blueprint, you are ready to go.</p>
<p>But again, there are additional challenges. People who are not under your direct control are undermining your best of efforts. You discover very quickly that it takes a lot of effort to affect the behaviour of these people, which brings serious political difficulties with it. Politics has to do with power and some people have more power than others. To be successful as a leader you have to identify power in your organisation and establish collaborative relationships with and amongst people in your networks.</p>
<p>Managing across diversities, such as countries, languages, gender, ethnicity, religions and social classes, adds another layer of complexity to collaboration. Cultural differences are challenging and more often a source of conflict than of synergy. Basic cross-cultural etiquettes, such as greeting, body contact, eye contact, display of emotions, eating manners, punctuality and gift giving, are very different.</p>
<h2>Leadership</h2>
<p>As a new leader you may not appreciate the complexity and breadth of your new role. Academics have produced huge amounts of publications on management and leadership. They all agree that the managerial role is complex and demanding. You now have to figure out what to do and how to act in this field of apparent chaos, great uncertainty, diversity, and interdependence.</p>]]></description>
<link>http://www.architecting-the-enterprise.com/enterprise_architecture/articles/leadership_-_changing_the_dialogue.php</link>
<guid isPermaLink='true'>http://www.architecting-the-enterprise.com/enterprise_architecture/articles/leadership_-_changing_the_dialogue.php</guid>
<pubDate>Thu, 17 Mar 2011 09:51:49 GMT</pubDate>
</item>

<item>
<title>Enterprise Architecture Professional Development Program - Soft Skills for Enterprise Architects</title>
<description><![CDATA[<p>Constant transformation is a business imperative as globalisation, innovation and economic conditions drive the pace of change in markets worldwide. Moreover, IT is now central to business success and provides the central nervous system which supports effective decision making, as well as streamlining and automating business processes to achieve more with less resource. However, the track record of failure in business transformation programmes and complex IT projects is well documented.</p>
<p>Enterprise Architecture (EA) is a structured, systematic and integrated approach to aligning business and IT transformation, which optimises costs, maximises business value and manages associated risks (e.g. TOGAF, Zachman).</p>

<div align="center">
  <img src="http://www.architecting-the-enterprise.com/images/kotters_8_step.jpg" alt="Kotter's 8 step framework for leading organisation change">
  <p>Figure 1 – Kotter’s 8 step framework for leading organisation change</p>
</div>

<p>However, the successful use of an Enterprise Architecture framework is dependent not just on the logic of the approach but also requires motivation of appropriate human behaviour in using it to accomplishing necessary organisation change.</p>
<p>JP Kotter in his book, ‘Leading Change’ (1995), identifies 8 steps to successful organisation change based on observations of where companies repeatedly fail to meet their aspirations.</p>
<p>These 8 steps are described in figure 1 alongside some of key recommendations from EA best practice (e.g. TOGAF). Both of these frameworks highlight the need for soft skills around:</p>
<ul>
  <li>Leadership – understanding the motivations of stakeholders in order to create a vision that inspires change</li>
  <li>Communication – making sure that stakeholders are properly informed, understand the need for change and what they must do</li>
  <li>Empowerment – introducing formal models and best practices to ensure that change is managed effectively</li>
</ul>
<p>Each of these areas are interrelated but focus on different aspects of soft skills in relation to Enterprise Architecture and business transformation (Figure 2).</p>

<div align="center">
  <img src="http://www.architecting-the-enterprise.com/images/softskillsforarchitects.jpg" alt="Enterprise Architecture, change management and soft skills are interlinked">
  <p>Figure 2 – Enterprise Architecture, change management and soft skills are interlinked</p>
</div>

<p>Architecting the Enterprise offers a training course and optional workshops to develop and apply soft skills for enterprise architects. Customers can choose from the following formats:</p>

<ol>
  <li>Executive overview – a half day presentation to senior leaders to explain the benefits of Enterprise Architecture and the role of soft skills</li>
  <li>2 day core soft skills training for EA practitioners</li>
  <li>4 day applied course for a specific organisation – includes the 2 day core soft skills training plus 2 days of workshops around vision and strategy, and the use of soft skills with the TOGAF Enterprise Architecture framework to create a transformation plan</li>
</ol>

<p>Architecting the Enterprise's <strong>SSFEA</strong> course is designed for a range of professionals wishing to develop their business soft skills in order to function at a higher enterprise level within their chosen Industry. It is designed with the EA/IT professional in-mind, so that they may understand business thought processes in order to communicate effectively with and influence key stakeholders when making recommendations for change or implementation.</p>

<p>To find out more please visit the <a href="http://www.architecting-the-enterprise.com/training/soft_skills_for_enterprise_architects.php">Soft Skills for Enterprise Architects training page</a> or call +44 (0) 2081 229 150.</p>]]></description>
<link>http://www.architecting-the-enterprise.com/enterprise_architecture/articles/enterprise_architecture_professional_development_program_-_soft_skills_for_enterprise_architects.php</link>
<guid isPermaLink='true'>http://www.architecting-the-enterprise.com/enterprise_architecture/articles/enterprise_architecture_professional_development_program_-_soft_skills_for_enterprise_architects.php</guid>
<pubDate>Thu, 17 Feb 2011 09:51:48 GMT</pubDate>
</item>

<item>
<title>Cloud Computing requires Enterprise Architecture and TOGAF(R) 9 can show the way</title>
<description><![CDATA[<p>Enterprise Architecture is necessary regardless of changes to underlying technologies. If managed properly, Enterprise Architecture will iterate and adjust to the winds of change. Client/server, SOA, RFID, Cloud, and other technology developments should be considered as styles, but Enterprise Architecture is at the heart of change.  Cloud computing should have little impact on Enterprise Architecture.</p>
<p>It is the role of the Enterprise Architecture team to:</p>
<ul>
  <li>Investigate if any style is simply hype or whether it holds real business value</li>
  <li>Understand the benefits and risks of a specific style</li>
  <li>Communicate these to Business and IT</li>
  <li>Develop an adequate governance framework</li>
  <li>Align the “style” with business requirements</li>
  <li>Give guidance for sustainable innovation</li>
</ul>
<p>If Cloud computing does not take Enterprise Architecture into consideration, it will result in “spaghetti clouds” (aligned with “spaghetti architectures”).</p>
<p>Cloud computing is often characterised by: virtualised computing resources, seemingly limitless capacity and scalability, dynamic provisioning, multi-tenancy, self-service and pay-for-use pricing. Enterprise Architecture can help make the shift to cloud computing smooth.</p>
<br><div align="center"><img src="http://www.architecting-the-enterprise.com/images/creating_a_foundation_for_business_execution.jpg" alt="Creating a Foundation for business execution"></div><br>
<p>For organisations focusing more on Technology Architecture, cloud computing could be a “big hit”. But for businesses that want to successfully adopt cloud computing in a way that aligns to their business strategy, Enterprise Architecture is imperative (refer to above diagram).</p>
<p>Cloud computing may be a fit when the core of internal Enterprise Architecture is mature. This means:</p>
<ul>
  <li>As recommended in TOGAF well defined and layered:
  <ul>
    <li>Business Architecture</li>
    <li>Application Architecture</li>
    <li>Data Architecture</li>
    <li>Technology Architecture</li>
  </ul>
  <li>Well defined interoperability  (ADM Guidelines and Techniques)</li>
  <li>Low level of security agreed (during the Architecture Vision)</li>
  <li>Web as a target</li>
  <li>Costs issues </li>
  <li>New products and services</li>
</ul>
<p>Cloud computing may not be a fit when the core of internal Enterprise Architecture is immature. This means:</p>
<ul>
  <li>Business, Application and Data architectures are tightly coupled</li>
  <li>Low level of interoperability defined</li>
  <li>High level of security required</li>
  <li>When applications have IPAs (Information Provider Applications) with only proprietary interfaces</li>
  <li>When solutions are legacy</li>
</ul>
<p>Where there could be a good fit, a TOGAF iteration should then be “Cloud Architecture aware”. The Enterprise Architecture team drives the programme and works collaboratively with both the business and the IT department.</p>
<br><div align="center"><img src="http://www.architecting-the-enterprise.com/images/cloud_architecture_aware.jpg" alt="Cloud Architecture aware"></div><br>
<p>In the <b><u>Preliminary Phase</u></b> we should consider the addition of a step related to the <b>creation of a strategy for the consumption and management of cloud services</b> (public/private clouds, semantic management, security, transactions). The governance framework also needs to include the processes, roles and responsibilities related to cloud services and operations. At this stage, we need to identify who in the business owns the cloud from both a user and service provider management perspective.   New principles may be created referring to the Cloud when the organisation has a fairly mature Enterprise Architecture (maturity model) in order to fully take advantage of the Cloud.</p>
<p>During <b><u>Phase A</u></b>, you may use a Business Scenario where you would identify in a workshop what are the business problems, business Requirements and identify a potential business solution. Stakeholders in this workshop may come from Business and IT Operations, Procurement, PMO, Data Center, Development, COO/CIO/CTO. Interoperability will be an important element of the phase. The Enterprise Architecture team will collaborate with the business to understand and scope the needs; align them with the Strategic Enterprise Architecture (bringing to bear the existing technological capabilities that can satisfy those needs thereby promoting sharing, reusing or building new ones if needed). Given the relatively low barrier to entry, in the scenarios where the Business is not sure of the viability of their proposal, they could go straight to the Cloud instead of "experimenting" before solidifying their requirements. The result of this is that the business may embark on a path of no return. To avoid this, make sure that the Business Scenario is complete, only refer to business solutions without referring to any architecture style (as this will be discussed during Phase E) and signed off.</p>
<p>Start the architecture considering <b>Phase B, C and D</b>.</p>
<p>At that stage, it is be recommended that you consider a Cloud Reference Model. This is a description of the appropriate Cloud industry standards, the dimensions of the Cloud problem space, and the decisions and choices that apply to a Cloud computing for an organisation. A  Cloud reference model, reference architecture and reference implementation approach is an accepted approach for planning and implementing Cloud computing. Different Cloud Reference Models can be considered such as those published by</p>
<ul>
  <li>The Open Cloud Consortium</li>
  <li>The Cloud Security Alliance</li>
  <li>The Cloud Computing Reference Model (CC-RM) and Reference Architecture framework from AgilePath</li>
  <li>The Accenture Cloud Reference Model for Application Architecture with its 7-layers. Like the OSI Model for networks, this Cloud Model is layered to separate concerns and abstract details</li>
</ul>
<br><div align="center"><img src="http://www.architecting-the-enterprise.com/images/cloud_reference_model.jpg" alt="Cloud Reference Model"></div><br>
<p>There is also an on-going initiative by The Open Group to deliver a Cloud Reference Model.</p>
<p>The Security activities from TOGAF will have to be applied to all phases taking into account the company’s Security strategy. The TRM should be extended with cloud services.</p>
<p>In <b><u>Phase C: Data Architecture</u></b>, Data integration, in particular may be an issue for cloud computing as it pushes information back into siloes, that IT may not have direct access to.  It is also recommended to determine Data and privacy classification and to prioritise the risk criteria of what goes in the cloud and what stays on-premise.</p>
<p>During <b><u>Phase E and F</u></b> there is a need to understand the Cloud resources which may exist or not. A new step will also be dedicated to <b>identify candidates’ services in the Cloud</b>.</p>
<p>Instead of now having to provide standardized ROI or cost-benefit analysis justifying the products that need to be bought or charge-backs that need to be agreed upon upfront for shared assets, the Business can provide operational expenditure outlines and may go out to the Cloud to source their requirements. No surprises with CapEx, decreased new product introduction training line item expenditures (many products are “standards “which means, lots of documentation and books available, e-learning, etc.), different charge-back agreements between Finance and Business Units (the organisation may have accesses to the service independently from his internal structure), in short, no need to conform to existing enterprise-wide Reference Architectures to meet individual project needs.  In relation to this, the recent Open Group white paper “<a href="http://www.opengroup.org/bookstore/catalog/w104.htm">Building Return on Investment from Cloud Computing</a>” is a valuable source of information.</p>
<p>During <b><u>Phase G</u></b>, activities may also include the relocation of:</p>
<ul>
  <li><b>Business processes (Process-as-a-Service)</b></li>
  <li><b>Applications (Application-as-a-Service)</b></li>
  <li><b>Data (Information-as-a-Service and Database-as-a-Service)</b></li>
  <li><b>Technical services (Storage-as-a-Service and Infrastructure-as-a-Service)</b></li>
  <li>Security and operations implementation will have to be taken into consideration during the relocation. Security can also be considered as <b>Security-as-a-Service</b></li>
</ul>
<p>The following diagram summarises the additional activities or concerns which should be considered in the ADM:</p>
<br><div align="center"><img src="http://www.architecting-the-enterprise.com/images/cloud_considerations_to_the_adm.jpg" alt="Cloud considerations to the ADM"></div><br>
<p>Below is a diagram which maps the various Cloud services to the TOGAF Metamodel.</p>
<br><div align="center"><img src="http://www.architecting-the-enterprise.com/images/cloud_services_to_the_togaf_metamodel.jpg" alt="Cloud services to the TOGAF Metamodel"></div><br>
<p>The development and deployment teams would now be sourcing from and conforming to the Cloud API and services, without the Enterprise Architecture team becoming policeman, enforcing the reference architectures or corporate standards at various checkpoints (compliance and dispensation activities will remain for internal new systems). With overarching cross-project oversight not relevant anymore, each project would tend to work in its own Cloud development sandbox, party engendered by the partitioning paradigm of the Cloud itself.</p>
<p>Barring some exceptions, traditionally the Enterprise Architecture team has not been relevant to the Operation side of the organisation, but with the Cloud, even that seems to be disappearing. The Cloud providers will furnish the relevant tools for management and reporting and take away the onerous tasks of patch management, version upgrades, high availability, disaster recovery and the like.</p>
<p>New technologies styles are exciting, but using technology styles just for the sake of technology does not bring a real value. Technology use should be driven not by its "coolness factor", but rather by business requirements and an underlying Enterprise Architecture such as TOGAF. Moving some applications to the Cloud can make some infrastructures go away, but badly designed solutions won’t be improved by relocating to the Cloud.</p>
]]></description>
<link>http://www.architecting-the-enterprise.com/enterprise_architecture/articles/cloud_computing_requires_enterprise_architecture_and_togaf_9_can_show_the_way.php</link>
<guid isPermaLink='true'>http://www.architecting-the-enterprise.com/enterprise_architecture/articles/cloud_computing_requires_enterprise_architecture_and_togaf_9_can_show_the_way.php</guid>
<pubDate>Thu, 04 Nov 2010 09:51:48 GMT</pubDate>
</item>

<item>
<title>The value of Enterprise Architecture training to Business</title>
<description><![CDATA[<p>Enterprise Architecture is more than the aggregation and the interrelationships of various architectures such as Business, Application, Data and Technology. It is a conceptual approach that assists organisations with the understanding of their own structures and the way they work. It provides a map of the enterprise and is a route planner for business and technology changes.</p>
<p>Most companies have enterprise wide concerns such as:</p>
<ul>
<li>Better alignment between IT and Business</li>
<li>Enable business transformation</li>
<li>Identification of Business needs and requirements</li>
<li>Proactive stakeholders management</li>
<li>Improved quality of services</li>
<li>Optimize the created value</li>
<li>Reducing costs and profit increases</li>
<li>Reducing duplication of information systems and operational processes</li>
<li>Seamless integration and interoperability</li>
<li>Security and availability of services</li>
<li>Integrity of the information</li>
<li>Focus on what is reusable or what can be shared</li>
<li>Better return on existing investment, reduced risk for future investment</li>
<li>A more efficient IT operation</li>
<li>Faster, simpler and cheaper procurement</li>
</ul>
<p>As a result, Enterprise Architecture can be used as a blueprint for an existing/target business capabilities gap analysis and as an approach for strategic, acquisition, and capital investment planning. Architecting the Enterprise training is focused on the essential elements required for developing results-driven Enterprise Architecture programs that are designed to meet these business requirements.</p>
<p>Architecting the Enterprise courses clearly explain Enterprise Architecture’s vital role in enabling or constraining the execution of business strategy.  Our training provides clear explanations on the use of Enterprise Architecture, through real –life examples and interactive exercises, and a proven-effective structured process for designing and implementing effective Enterprise Architectures based on TOGAF.</p>
<p>Accordingly, Architecting the Enterprise’s experienced instructors work with you. Our training provides practical ways on how you can maintain your valuable customer base, win repeat business, whilst measuring your organization's ability to meet customer expectations.</p>
<p>At the end of our training, you will be able to:</p>
<ul>
<li>Understand the concepts related to Enterprise Architecture  and TOGAF</li>
<li>Identify  the benefits and the added value of Enterprise Architecture</li>
<li>Understand why and how to build an Enterprise Architecture based on TOGAF</li>
<li>Identify the  challenges of implementing an  Enterprise Architecture , including the organizational and technical issues</li> 
<li>Identify, organise and develop the elements of an Enterprise Architecture program using TOGAF</li>
<li>Identify the steps to create and improve an Enterprise Architecture practice</li>
<li>Understand typical symptoms of an Enterprise Architecture  dysfunctions and how to avoid them</li>
</ul>]]></description>
<link>http://www.architecting-the-enterprise.com/enterprise_architecture/articles/the_value_of_enterprise_architecture_training_to_business.php</link>
<guid isPermaLink='true'>http://www.architecting-the-enterprise.com/enterprise_architecture/articles/the_value_of_enterprise_architecture_training_to_business.php</guid>
<pubDate>Wed, 22 Sep 2010 09:51:47 GMT</pubDate>
</item>

<item>
<title>What is Enterprise Analysis: does it differ from Enterprise Architecture</title>
<description><![CDATA[<p>Enterprise Analysis is a knowledge area which describes the Business analysis activities that take place for an enterprise to identify business opportunities, build a Business Architecture, determine the optimum project investment path for that enterprise and finally, implement new business and technical solutions. The question you may ask: Does this really differs from Enterprise Architecture, and if so, how?</p>

<p>At first sight, business opportunities are not always considered as being part of an Enterprise Architecture initiative, more as an activity which should be considered as an input. Let’s look at this in more detail by way of mapping the activities between BABOK v2* and the TOGAF 9 Framework*.</p>
<p>BABOK is the collection of knowledge within the profession of business analysis and reflects generally accepted practices. It describes business analysis areas of knowledge, their associated activities and tasks and the skills necessary to be effective in the execution:</p>

 <table border="1" cellspacing="0" cellpadding="0">
  <tr>
    <td width="115" valign="top"><p>BABOK v2    Knowledge Area</p>
        <p>Activity    in Enterprise Analysis</p></td>
    <td width="204" valign="top"><p>Definition</p></td>
    <td width="142" valign="top"><p>Enterprise    Architecture (e.g TOGAF 9)</p></td>
    <td width="155" valign="top"><p>Differences,    observations</p></td>
  </tr>
  <tr>
    <td width="115" valign="top"><p>Requirements    Elicitation</p></td>
    <td width="204" valign="top"><p>This    describes the interview and research process-how to best extract needs from    stakeholders (and even how to recognize needs they don't know they    have).Elements such as metrics (tracking the amount of time spent eliciting    requirements) and elicitation techniques (prototyping and brainstorming are    just a couple) among the topics covered</p></td>
    <td width="142" valign="top"><p>Phase A:    Architecture Vision is the initial phase of an architecture development    cycle.  It includes information about    scope, the key steps, methods, information requirements and obtaining    approval for the architecture development cycle to proceed</p></td>
    <td width="155" valign="top"><p>Business    scenarios are a useful technique to articulate an Architecture Vision.</p>
        <p>A Business Scenario    describes, a business process, an application or set of applications enabled    by the proposed solution , the business and technology environment, the    people and computing components (called “actors”) who execute it,  the desired outcome of proper execution</p>
      <p>To build    such a Business Scenario, workshops with business users (stakeholders) would    be organized</p></td>
  </tr>
  <tr>
    <td width="115" valign="top"><p>Business<br />
      Requirements    Analysis</p></td>
    <td width="204" valign="top"><p>This describes    how to write/state requirements that will meet business needs. Key objectives    include methods for prioritizing and organizing requirements, as well as the    most beneficial techniques for requirements presentation (including state    diagrams, prototyping, data flow diagrams, and process modeling, and more).</p>
        <p>Business    Requirements for future project investments are identified and documented. </p>
      <p>They are    defined at a high level, and include goals, objectives, and needs are    identified</p></td>
    <td width="142" valign="top"><p>Business    Requirements are collected from business people during the Architecture    Vision’s phase using the technique called Business Scenario (as mentioned    above).</p>
        <p>That    document identifies what will be the business solutions in generic terms</p></td>
    <td width="155" valign="top"><p>The    Enterprise Architects will define the Architecture Vision phase based on the    goals, and objectives of the enterprise gathered from the business. </p>
        <p>There are    two steps: </p>
      <p>1.    Business people will have defined the goals     and the objectives of the enterprise independently from the Enterprise    Architecture team</p>
      <p>2. The    Enterprise Architecture team which include business people gather the    requirements based on the previous activity</p></td>
  </tr>
  <tr>
    <td width="115" rowspan="12" valign="top"><p>Enterprise    Analysis</p></td>
    <td width="204" valign="top"><p>Begins after a Business executive    team develops strategic plans and goals</p>
        <p>This outlines the crucial (and    sometimes political) process of keeping everyone in the loop and on the same    page regarding project's direction and progress. This activity delves into    such details as the requirements review and approval processes (including    record-keeping).<br />
        </p></td>
    <td width="142" valign="top"><p>Most of these activities are taken    into account in doing Enterprise Architecture or done directly by the    Business executive team before starting an new Enterprise Architecture    project</p></td>
    <td width="155" valign="top"><p> </p></td>
  </tr>
  <tr>
    <td width="204" valign="top"><p>Strategic plan development</p></td>
    <td width="142" valign="top"><p> </p></td>
    <td width="155" valign="top"><p>Done    outside of the Enterprise Architecture process by business people but is a    key source of information</p></td>
  </tr>
  <tr>
    <td width="204" valign="top"><p>Strategic goal development</p></td>
    <td width="142" valign="top"><p> </p></td>
    <td width="155" valign="top"><p>This is    done outside of the Enterprise Architecture initiative by business people but    is a key source of information</p></td>
  </tr>
  <tr>
    <td width="204" valign="top"><p>Business Architecture development</p></td>
    <td width="142" valign="top"><p> </p></td>
    <td width="155" valign="top"><p>Done    during Phase B:Business Architecture, looking at the baseline and target    architecture, delivering a gap analysis, a plan and a roadmap</p></td>
  </tr>
  <tr>
    <td width="204" valign="top"><p>Feasibility Studies</p></td>
    <td width="142" valign="top"><p> </p></td>
    <td width="155" valign="top"><p>Done    during Phase A: Architecture Vision (with a Business Scenario)</p></td>
  </tr>
  <tr>
    <td width="204" valign="top"><p>Business Case Development</p></td>
    <td width="142" valign="top"><p> </p></td>
    <td width="155" valign="top"><p>Done    during Phase A: Architecture Vision (with a Business Scenario)</p></td>
  </tr>
  <tr>
    <td width="204" valign="top"><p>New Project Proposal</p></td>
    <td width="142" valign="top"><p> </p></td>
    <td width="155" valign="top"><p>This is    done in two steps: during the Phase A where we identify a Business solution    and during Phase F; Migration Planning</p></td>
  </tr>
  <tr>
    <td width="204" valign="top"><p>Selecting    and Prioritizing New Projects</p></td>
    <td width="142" valign="top"><p> </p></td>
    <td width="155" valign="top"><p>This is    done in two steps: during the Phase A where we identify a Business solution    and during Phase F; Migration Planning</p></td>
  </tr>
  <tr>
    <td width="204" valign="top"><p>Business    Opportunities</p></td>
    <td width="142" valign="top"><p> </p></td>
    <td width="155" valign="top"><p>This is    done during the Phase A: Architecture Vision and the Phase E: Opportunities    and Solutions</p></td>
  </tr>
  <tr>
    <td width="204" valign="top"><p>Launching New Projects</p></td>
    <td width="142" valign="top"><p> </p></td>
    <td width="155" valign="top"><p>This is    done during Phase F: Migration Planning</p></td>
  </tr>
  <tr>
    <td width="204" valign="top"><p>Managing Projects for Value</p></td>
    <td width="142" valign="top"><p> </p></td>
    <td width="155" valign="top"><p>This is    done during Phase F: Migration Planning</p></td>
  </tr>
  <tr>
    <td width="204" valign="top"><p>Tracking Project Benefits</p></td>
    <td width="142" valign="top"><p> </p></td>
    <td width="155" valign="top"><p>Once the    project is in production, it is no longer part of the Enterprise Initiative</p></td>
  </tr>
  <tr>
    <td width="115" valign="top"><p>Solution    Assessment and Validation</p></td>
    <td width="204" valign="top"><p>Details    how to choose the best solutions for specific business needs (as well as    assessing how well the chosen solution worked after its implementation).This    should also cover risks, dependencies, and limitations that must be    identified before proposing any solution</p></td>
    <td width="142" valign="top"><p>Solutions    are identified during Phase E.: Opportunities and Solutions. </p>
        <p>This phase    is directly concerned with implementation, identifying major work packages to    be undertaken and creating a migration strategy.</p>
      <p>Risk    management, dependencies are taken into consideration.</p></td>
    <td width="155" valign="top"><p> </p></td>
  </tr>
  <tr>
    <td width="115" valign="top"><p>Business    Analysis Planning and Monitoring</p></td>
    <td width="204" valign="top"><p>Explains    how to decide what you need to do to complete an "analyst effort"    (in other words, how to plan a project). This     helps intelligently decide which stakeholders, tools, tasks and    techniques we will need to get the job done</p></td>
    <td width="142" valign="top"><p>Covered    mostly in the Architecture Vision phase, then in the Business Architecture    Phase </p></td>
    <td width="155" valign="top"><p>Stakeholder    management techniques are used within TOGAF, tools and techniques are    identified in the Business Architecture phase (modelling, reference models,    viewpoints)</p></td>
  </tr>
  <tr>
    <td width="115" valign="top"><p>Requirements    Management  and Communication</p></td>
    <td width="204" valign="top"><p>Describes    how to identify business needs (the why of the project; whereas requirements    are the how) and state the scope of their solutions. This is a crucial piece    of the analyst's work. SMART criteria of measurement,  SWOT analysis and other measurement factors    that make identifying this root cause data objective and tangible are used</p></td>
    <td width="142" valign="top"><p>Business    Requirements are collected with the business people during the Architecture    Vision’s phase using the technique called Business Scenario (as mentioned    above).</p></td>
    <td width="155" valign="top"><p>SMART    techniques are equally used.</p>
        <p>Communication    plans are defined.</p></td>
  </tr>
</table>
<br><br>
<p>The diagram below is a draft mapping between BABOK® and TOGAF 9, more work is required on this.</p>

<div align="center"><img src="http://www.architecting-the-enterprise.com/images/babok.jpg" alt="BABOK v2 Knowledge Areas to TOGAF 9 ADM"></div>
<br>
<h2>Observations</h2>
<p>There are obviously overlaps between Enterprise Analysis and Enterprise Architecture, but activities are not always done in the same sequence. </p>
<ul>
  <li>Enterprise Analysis is more a business initiative than an Enterprise Architecture which includes both business and IT people</li>
  <li>Enterprise Analysis provides the context in which an Enterprise Architecture  should be conducted</li>
  <li>Enterprise Analysis is about defining the strategic goals and the strategic planning taking into account the environment and market trends, identify business issues, focus on remaining competitive, profitable, efficient. Enterprise Architecture is reusing all this information.</li>
  <li>Enterprise Analysis is only covering the initial activities of Enterprise Architecture but does not address other Enterprise Architecture activities such as: - Application Architecture, Data Architecture, Technology Architecture (and Solution Architecture).</li>
  <li>Enterprise Analysis does not include all aspects related to governance such as the IT Governance and the Enterprise Architecture Governance Framework. Touch points with other frameworks are not addressed.</li>
  <li>Enterprise Analysis may not completely address the need of working with other parts of the enterprise such as IT, PMO, development teams, IT partners.</li>
  <li>Enterprise Architecture suggest a Preliminary phase which is about defining "where, what, why, who, and how" Enterprise Architecture will be done, establishing the business context, customizing the framework, defining the architecture principles, establishing the Architecture Governance structure.</li>
</ul>
<p>Enterprise Analysis complements Enterprise Architecture but also overlaps in some areas. Organization looking into Enterprise Architecture and specifically TOGAF 9 may consider adopting a Business Analysis framework such as BABOK and integrate them in the Preliminary Phase. If both approaches exist in a company, this would be a great opportunity for optimizing the alignment between Business and IT, and to run an Enterprise Architecture program from a complete business perspective.</p>

<p>About Business Analysis Body of Knowledge® (BABOK®)</p>
<p>The Business Analysis Body of Knowledge® (BABOK®) is the collection of knowledge within the profession of Business Analysis and reflects current generally accepted practices. As with other professions, the body of knowledge is defined and enhanced by the Business Analysis professionals who apply it in their daily work role. The BABOK® Guide describes Business Analysis areas of knowledge, their associated activities and the tasks and skills necessary to be effective in their execution. The BABOK® Guide is a reference for professional knowledge for Business Analysis and provides the basis for the Certified Business Analysis Professional™ (CBAP®) Certification.</p>
<p>BABOK® Guide 2.0 represents the development of a common framework to understand and define the practice of business analysis.</p>
<p><a href="http://www.theiiba.org/am/">http://www.theiiba.org/am/</a></p>]]></description>
<link>http://www.architecting-the-enterprise.com/enterprise_architecture/articles/what_is_enterprise_analysis:_does_it_differ_from_enterprise_architecture.php</link>
<guid isPermaLink='true'>http://www.architecting-the-enterprise.com/enterprise_architecture/articles/what_is_enterprise_analysis:_does_it_differ_from_enterprise_architecture.php</guid>
<pubDate>Wed, 28 Apr 2010 09:51:46 GMT</pubDate>
</item>



</channel>
</rss>

