Search Results for: archimate

<p style=”line-height: 18.99147605895996px;”><span style=”font-size: 11px; line-height: 19px;”>This is the fifth posting in our “EA Roadmap for success” series. In this posting we zoom in on the use of an </span><em style=”font-size: 11px; line-height: 19px;”>Open</em><span style=”font-size: 11px; line-height: 19px;”> approach to enterprise architecture.</span></p><p style=”line-height: 18.99147605895996px;”> </p><div class=”captionImage left” style=”width: 600px;”><img class=”left” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/_resampled/resizedimage600375-Enterprise-architecture-roadmap.png” alt=”Enterprise Architecture Roadmap” title=”Enterprise Architecture Roadmap” width=”600″ height=”375″/><p class=”caption”>Enterprise Architecture Roadmap</p></div><h2>Frameworks and approaches?</h2><p style=”line-height: 18.99147605895996px;”>One of the key challenges of getting started with enterprise architecture (EA) is to agree on goals for the EA practice, and subsequently to find and agree on a framework / approach / method that helps the organization to realize those goals.</p><p style=”line-height: 18.99147605895996px;”>In the early days of EA (1990’s and the early 2000’s), we saw many organizations growing their own approaches and frameworks. By working with business sponsors, architects experimented with different processes for EA, frameworks to structure EA products, modeling languages and notation and so on.</p><p style=”line-height: 18.99147605895996px;”>While this worked well in the ‘old days’, many best practices have emerged and ultimately led to the major frameworks / approaches / methods we see today: ArchiMate, TOGAF, IAF, Zachman, DYA, and so on.  Some of these are ‘general purpose’, while others (e.g. MODAF/DODAF) appear to be particularly useful in a single branch.</p><h2>Build or Adopt? Open or closed?</h2><p style=”line-height: 18.99147605895996px;”>While organizations in theory face a choice of ‘build or adopt’ where it comes to frameworks, we see that many chose the latter. With all the experiences and best practices that have been developed, most organizations realize that there is little point in re-inventing the wheel all over again.</p><p style=”line-height: 18.99147605895996px;”>The question that remains, then, is this: do we adopt an open approach, or a proprietary / closed approach?</p><p style=”line-height: 18.99147605895996px;”>This question can be answered on many different levels. One could argue that “open vs closed” doesn’t really matter, as long as the selected framework does what it is supposed to do. While this may seem true at first glance, we do believe that there is a lot to be said about principally going for an open approach. The main advantages here are as follows:</p><ul><li>Know what you will get: all details about open frameworks tend to be available in the public domain.</li><li>Choose your partners: because the frameworks are in the public domain, you’ll often be able to select which vendor can help you get started – if needed at all. Along the same lines: if the vendor doesn’t deliver what was requested, switching is easier.</li><li>Get involved: perhaps most importantly, if the framework is lacking in certain areas, organizations can often join and publish their own best practices, furthering the framework for all other users.</li></ul><h2>Adopt as-is, or tailor to specific needs?</h2><p style=”line-height: 18.99147605895996px;”>To conclude this posting: there is one more choice that organizations have to make when adopting a framework, be it an open or a closed/ proprietary one: should we adopt the framework as is, or tailor it to our needs?</p><p style=”line-height: 18.99147605895996px;”> </p><div class=”captionImage left” style=”width: 348px;”><img class=”left” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/Enterprise-architecture-framework.png” alt=”Enterprise Architecture Framework” title=”Enterprise Architecture Framework” width=”348″ height=”400″/><p class=”caption”>Enterprise Architecture Framework</p></div><p style=”line-height: 18.99147605895996px;”>The best practice here is simple: pick and choose! Most approaches explicitly recommend users to tailor the framework to organizational needs. In TOGAF this is being done as part of the <em>preliminary phase</em>.  While TOGAF recommends that certain parts <em>not</em> to be skipped, it is of course entirely up to the individual organization to decide what is useful and what is not!</p><h2>Next posting</h2><p style=”line-height: 18.99147605895996px;”>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:s.vandijk@bizzdesign.com”>s.vandijk@bizzdesign.com</a>, or leave a comment. The next post in this series covers project based implementation of EA. It is scheduled to be posted on January 29. </p>