Search Results for: business model

I want to continue to build on the theme of Information Architecture which is being talked about a great deal at the Open Group Conference in Newport Beach. In my post, "A Quick Look At The Importance Of Information Architecture"…

<p>This is the sixth posting in our “Enterprise Architecture Roadmap for success” series. In this posting we zoom in on the <strong>implementation and embedding</strong> of an enterprise architecture practice in an organization.</p><p> </p><div class=”captionImage left” style=”width: 600px;”><div class=”captionImage left” style=”width: 600px;”><img class=”left” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/_resampled/resizedimage600376-Enterprise-Architecture-Roadmap-for-success-project-based-implementation.png” alt=”Enterprise-Architecture-Roadmap-for-success-project-based-implementation” title=”Enterprise-Architecture-Roadmap-for-success-project-based-implementation” width=”600″ height=”376″/><p class=”caption”>Enterprise Architecture Project based implementation</p></div><p class=”caption”> </p></div><div class=”captionImage left” style=”width: 600px;”><h2>Enterprise Architecture is everywhere</h2><p>In one of our discussions during a client engagement we came across the following remark by one of the <span style=”font-size: 10.909090995788574px;”>Enterprise Architecture</span>’s in the organization: “<span style=”font-size: 10.909090995788574px;”>Enterprise Architecture </span>is about everything the organization is and does”. This remark supports our experience, and is one of the reasons that many companies struggle to effectively adopt and embed <span style=”font-size: 10.909090995788574px;”>Enterprise Architecture</span> in their organization. Enterprise Architecture has many stakeholders and, depending on the approach taken i.e. top-down or bottom-up, from various levels of the organization.</p><p><span style=”font-size: 10.909090995788574px;”>Enterprise Architecture</span> touches on many aspects of the organization such as business and IT alignment, strategic portfolio management, project management, and risk management. Enterprise Architecture is by definition about cooperation and therefore it is impossible to operate in isolation. Successful embedding of Enterprise Architecture in the organization is typically approached as a project: with clearly defined goals, metrics, stakeholders, and appropriate governance, accountability, and with assigned responsibilities in place.</p><h2>Evolution rather than revolution</h2><p>From our experience, the road to a strong, effective, and mature <span style=”font-size: 10.909090995788574px;”>Enterprise Architecture</span> capability should be broken down into manageable pieces. We favor evolution, rather than revolution. Too many times we have seen initiatives fail due to the sky high expectations to be delivered within unrealistic time frames. <strong>Implementing </strong><span style=”font-size: 10.909090995788574px;”>Enterprise Architecture</span> is a change initiative that besides processes, tools and other hard and tangible artifacts includes many “soft aspects”. These soft aspects need to be managed as such, involving mainly frequent, clear and honest communication with feedback and iteration.</p><h2>Where to start?</h2><p>The first step is to decide on the ultimate goal for the Enterprise Architecture function: where is the <span style=”font-size: 10.909090995788574px;”>Enterprise Architecture</span> organization positioned, who are the most important customers of <span style=”font-size: 10.909090995788574px;”>Enterprise Architecture</span>, and how does <span style=”font-size: 10.909090995788574px;”>Enterprise Architecture</span> deliver value to its customers? In the first postings of this series, the ones in the “aiming” category, we covered a number of important choices for the organization to take: are we following a bottom-up, or rather a top-down approach? How does <span style=”font-size: 10.909090995788574px;”>Enterprise Architecture</span> tie into strategy, project management, the corporate governance framework, and security?</p><p>Depending on the approach chosen, the next thing to do is to establish a project team that will be tasked with drafting high level plans for the <strong>implementation and embedding</strong> of the <span style=”font-size: 10.909090995788574px;”>Enterprise Architecture</span> capability in the organization. The plans should describe a long-term (say 3-4 year) strategic vision for the <span style=”font-size: 10.909090995788574px;”>Enterprise Architecture</span> capability, as well as a plan outlining the concrete initiatives for the short-term (say the first year).</p><p>It is one of the important tasks for the Architecture Board to provide input for the strategic vision for the architecture function, and then select the right members for the project team (see also the previous posting on “<a title=”the role of the enterprise architecture board” href=”http://blog/ea-roadmap-for-success-the-architecture-board/”>the role of the architecture board</a>”). The team should reflect the various areas and domains of the architecture, and the members should be able to look at the organization on a higher level, above the individual silos. The project team should interact with the AB frequently to make sure the efforts of the team keep aligned with the envisioned direction. In the next posting we will delve into more details around the <span style=”font-size: 10.909090995788574px;”>Enterprise Architecture</span> project team.</p><h2>Kicking off the project</h2><p>Once the team and high level plans are in place, it is time to kick off the project. The team will take the high-level plans and preliminary decisions, such as the proposed architecture framework as a starting point, and from there make more detailed plans and start identifying and prioritizing a number of initiatives. These first initiatives should not be seen as “architecture” projects per se, but rather pertain to the question: “how do we do architecture”. Or, according to TOGAF9: “where, what, why, who, and how we do architecture”.</p><p>Aspects in this context that need to be determined and confirmed in the first phase are (not complete!):</p><ul><li>Scope</li><li>Stakeholders</li><li>Requirements</li><li>Relationship between management frameworks</li><li>Maturity assessment of required capability</li></ul><p>As mentioned before, these aspects should be considered both from a strategic, long-term perspective, as well as from a short-term perspective. This, together with the general approach for <span style=”font-size: 10.909090995788574px;”>Enterprise Architecture</span> chosen (e.g. bottom-up, or top-down) determines priorities and thus the order in which things should be done. For example, detailing and determining interaction of EA with other management frameworks should be done for the project management framework earlier and in more detail if a bottom-up approach is followed.</p><p>The exercise of determining scope and assessing current and desired maturity leads to a roadmap for the development of the architecture capability. With the order of activity based on various indicators such as approach chosen, prioritization, organization culture, sponsorship, etc. This road map guides the <span style=”font-size: 10.909090995788574px;”>Enterprise Architecture</span> project team in their day-to-day activities. It is a task of the AB to make sure that the road map remains accurate and aligned with business strategy. The road map should be assessed frequently, say each half year, and necessary changes should be made accordingly.</p><h2>Using the TOGAF ADM to develop an Enterprise Architecture capability</h2><p>To conclude this posting we would like to point <span style=”font-size: 10.909090995788574px;”>Enterprise Architecture</span> project teams, especially in organizations that chose to adopt the TOGAF to an interesting section in the standard. In chapter 46, TOGAF describes how the ADM (Architecture Development Method) can be used as a tool to <strong>implement </strong>an Architecture Capability. In this approach, the “business architecture” of the <span style=”font-size: 10.909090995788574px;”>Enterprise Architecture</span> capability involves the organizational structure of the <span style=”font-size: 10.909090995788574px;”>Enterprise Architecture</span> capability, and architecture processes such as governance. The “data architecture” pertains to the meta model, and the Architecture repository that the <span style=”font-size: 10.909090995788574px;”>Enterprise Architecture</span> capability uses to describe architecture, and store architectural artifacts. The “application architecture” and the “technology architecture” describe functionality and the tools (modeling tools, document management systems, etc.) that need to be deployed to support the architecture capability. Using a structured approach as suggested in the TOGAF standard helps an architecture team to draft complete and clear plans. A number of iterations of the ADM can be defined to evolve the maturity of an EA capability.</p><h2>Next posting</h2><p>If you’d like to know more, please contact the authors directly at <a title=”b.vangils@bizzdesign.com” href=”mailto:b.vangils@bizzdesign.com”>b.vangils@bizzdesign.com</a> / <a title=”s.vandijk@bizzdesign.com” href=”mailto:b.vangils@bizzdesign.com”>s.vandijk@bizzdesign.com</a>, or leave a comment. The next post in this series covers the establishment of an EA team. It is scheduled to be posted between february 11th and february 15th. </p></div>