<p>In this 10th posting we will cover the topic of using <em>architecture principles</em> and <em>architecture models </em>in tandem. Both focus on different aspects of Enterprise Architecture work / documentation and complement each other as we will see shortly.</p><p> </p><div class=”captionImage left” style=”width: 600px;”><img class=”left” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/_resampled/resizedimage600375-Roadmap-for-success-architecture-principles-and-models.png” alt=”Principles and Models Enterprise Architecture” title=”10th posting in the Roadmap for sucess series” width=”600″ height=”375″/><p class=”caption”>The 10th posting in the series Roadmap for success</p></div><p> </p><h2>EA manifestations</h2><p>There are many definitions of architecture around, all focusing on different aspects: ontological definition, process, framework, language and so on. In our opinion, the ANSI/IEC/IEEE 42010 standard does a good job of explaining what architecture really <em>is</em>. In order to <em>know</em> what the architecture (of a system) is, we need to answer two questions:</p><ul><li>What is its fundamental organization?</li><li>What are the principles guiding its design and evolution?</li></ul><p>These questions not only give insight in how to <em>document</em> architecture (models for fundamental organization, principles for principles guiding design and evolution), they also give insight in how the instruments of Enterprise Architecture can be used to add value to the organization: gain insight in the fundamental organization of the enterprise at a high(er) level of abstraction, and develop a road map to help steer the organization to where it wants to be.</p><p>In this posting we zoom in on the two manifestations of Enterprise Architecture: models and principles. There is of course a lot more to be considered in the context of an Enterprise Architecture practice (governance logs, design decisions, exceptions granted, strategies, road maps and so on), but those are outside the scope of this blog post.</p><h2>Models</h2><p>The first type of architecture documentation to be considered is the use of <em>models</em>. A wide range of models have been proposed and used successfully over the last few decades. Some more formal, other informal (PowerPoint still seems to be a popular modeling tool). A lot can be said about the merits of a formal or informal approach. The figure below lists a few:</p><p> </p><div class=”captionImage left” style=”width: 600px;”><img class=”left” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/_resampled/resizedimage600577-Enterprise-architecture-formal-vs-informal.png” alt=”Enterprise architecture models” title=”Formal and informal enterprise architecture models” width=”600″ height=”577″/><p class=”caption”>Enterprise Architecture models: formal and informal models</p></div><p>In our experience, the combination of formal models with flexible visualization mechanisms tends to work best in practice. As such, <a title=”Open modeling language for architects to model and communicate Enterprise Architecture” href=”http://www.bizzdesign.com/consultancy/enterprise-architecture-management/archimate/#ArchiMate”>ArchiMate</a>® is a good candidate as the language was specifically designed to cater for various different stakeholders. Also, with good tool support it is also possible to generate tables, change the graphic shape of concepts and relations and so on: anything to improve the communication about the fundamental organization of a system with various stakeholders.</p><h2>Principles</h2><p>Some claim that architecture (of a system) <em>is</em> a set of principles. While we agree that the use of principles is key to a solid architecture approach, we feel that this may be one step too far.</p><p>Principles in the context of architecture work are <em>normative statements of direction</em>; they guide the design and evolution of a system. As such they tend to take the form of a ‘regulation’, an ‘abstract rule’ which may or may not be SMART. The typical template for principles includes such things as meta-data (who wrote it, when, what was the revision history and so on), a brief statement of the principle itself, a rationale or explanation, and a section that discusses its implications (for architecture designs).</p><p>Various templates have been proposed (e.g., TOGAF™), and many books have been written (we recommend the book by Proper and Greefhorst).</p><p>Regardless of form and template: principles guide the design of an architecture. To see why, consider the situation where two systems are designed that (functionally) solve the same problem, but adhering to a completely different set of principles! For example, a portal solution for an informational problem may adhere to the principle that all systems must be customer facing, whereas a call center solution for the same informational problem may adhere to the principle that customer-contact is always through human interaction.</p><h2>ArchiMate</h2><p>The ArchiMate® language has been around for a while now, and is widely used to model various aspects of (enterprise) architectures. Since its second edition – in which the language is better aligned with the TOGAF™ framework – it also includes a motivation extension which has the <em>principle</em> concept. This concept can be linked to any core concept using the <em>realization relation</em>, to indicate concepts in the architecture where this principle manifests itself. This <em>good practice</em> is highly recommended!</p><h2>Next posting</h2><p>If you’d like to know more, please contact the authors directly at <a title=”E-mail Bas van gils” href=”mailto:b.vangils@bizzdesign.com”>b.vangils@bizzdesign.com</a> / <a title=”E-mail Sven van Dijk” href=”mailto:s.vandijk@bizzdesign.com”>s.vandijk@bizzdesign.com</a>, or leave a comment. The next post in this series is about governing projects. It is scheduled to be posted between 8<sup>th</sup> and 12<sup>th</sup> of April. </p>
