Humility and the Art of Enterprise Architecture

As a lot, Enterprise Architects are not terribly humble people.  We name frameworks after ourselves, and sometimes go to great lengths to correct the “misinterpretations” of others who describe our work in a way that we don’t agree with. 

Yet, recognizing that the field is young requires that we should be willing to change as the field of EA changes; that we should be willing to look back on our models, developed in the past, and admit that we missed a few steps that we wouldn’t miss today.

I recently had the opportunity to discuss, on LinkedIn, a blog post that I made five years ago.  I look back on that blog post and must admit that my opinions are a bit different now than they were five years ago.  I still agree with my post, but I would certainly use different words today than I used in the past.  I am more than willing to admit it. 

I also look at the efforts of Alexander Osterwalder whose Business Model Canvas has proved both practical and flawed.  He missed the fact that he needed to create a differentiation between the customer’s needs and the value proposition of the business offering to fill some of those needs.  Did he go back and create an updated canvas?  Nope.  He created a new canvas to describe demand as though it fits with his older one (hint: it’s a mess). 

The venerable John Zachman, probably one of the most humble men I’ve met, also made this same mistake.  While his original model was only a couple of columns, and was updated only a few years later into the table we see today, the field of EA has changed.  The table is no longer representative of companies with multiple business models (most of them) and the lack of a “customer” row simply relegates his “ontological table” to the dust bin. 

Neither man will change.  They have “legacy” models, with their names attached.  To paraphrase Forrest Gump, humble is as humble does.

I would like to think that my willingness to upend my EBMM and replace it periodically with new versions shows my willingness to admit that (a) I’m often wrong, and (b) I’d rather learn than become stale.  That said, I’m no paradigm of humility, myself. 

After all, a truly humble EA would not have written this blog post. 

(As my teenage daughter would say: Oh snap, you pwned yourself!)

#InfoArch – Post 2. The starting point

As often, we needed to start somewhere. The main idea here was about “marking the starting point” and formalize it, in order to be able to come back and measure what has been achieved later on during the journey. So, as a starting point, we performed a survey, involving stakeholders across every different main organizations […]

#InfoArch – Master Data – Short definition

Master Data is the core information, that is needed, to Manage and Operate the Company businesses. Master Data is a Core asset for Enterprise/Company. As such, it has to be Governed and Managed properly. Customer, Product, Supplier and Financial information entities are typical examples of some very essential Master Data. They need to have a […]

Take Every Opportunity to Document

I am always surprised (and I really shouldn’t be) that we do a great job of responding to critical incidents but almost always fail to document what we did so it can be referenced in the future. As IT leaders we need to proactively document the impacts of planned and unplanned changes.  Whethere it is […]

The post Take Every Opportunity to Document appeared first on Enterprise Architecture in Higher Education.

The Open Group works with Microsoft to create Open Management Infrastructure

OMI is a highly portable, easy to implement, high performance CIM/WS-Management Object Manager in OMI, designed specifically to implement the DMTF standards. OMI is written to be easy to implement in Linux and UNIX® systems. It will empower datacenter device vendors to compile and implement a standards-based management service into any device or platform in a clear and consistent way. The Open Group has made the source code for OMI available under an Apache 2 license. Continue reading

Turning around the Team

Without doubt the biggest contributing factor to success on projects where I’ve been engaged as an Enterprise Architect is the human dimension. Bringing a method that people can buy into, in a language that they understand and then reinforcing this wit…

Turning around the Team

Without doubt the biggest contributing factor to success on projects where I’ve been engaged as an Enterprise Architect is the human dimension. Bringing a method that people can buy into, in a language that they understand and then reinforcing this wit…

Categories Uncategorized

Enterprise Architecture Roadmap for success: Tooling

<p><span style=”color: #505050; font-size: 11px; line-height: 19px;”>In this eighth posting we will cover the topic of <a title=”BiZZdesign Architect” href=”http://tools/bizzdesign-architect/”>Enterprise Architecture Tooling</a>. First we will explore the question what capabilities effective Enterprise Architecture teams need from tools, and list some characteristics that tools need to have in order to efficiently support Enterprise Architects. In the second portion of this blog we will address best practices that Enterprise Architecture teams can use to fully leverage the power of Enterprise Architecture tools.</span></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/resizedimage600375-Enterprise-Architecture-Tooling.png” alt=”Enterprise Architecture Roadmap for Success Contents” title=”Enterprise Architecture Roadmap for Success:” width=”600″ height=”375″/><p class=”caption”>Enterprise Architecture Roadmap for Success: part eight; Tooling</p></div></div><h2>Many Enterprise Architecture aspects</h2><p>From <a title=”Blogs by Sven van Dijk and Bas van Gils” href=”http://www.bizzdesign.com/blog/posts/bas-van-gils-and-sven-van-dijk”>previous postings</a> in this series it has become clear that Enterprise Architecture has many aspects, and that the specific set of aspects to focus on greatly depends on the approach that an organization takes with respect to Enterprise Architecture. For example more strategic aspects in a top-down approach and more operational aspects in a bottom up approach.</p><p>But in general we could state that Enterprise Architecture is always about knowledge and communication. Enterprise Architecture brings together various perspectives, enabling integrated analysis on the current and future state of the architecture of the enterprise. This results in valuable knowledge that greatly enhances decision making, whether on a strategic or more operational level. This knowledge not only needs to be efficiently managed and maintained, it also needs to be communicated to the right stakeholder at the right time, and even more importantly: in the right format. An essential aspect in Enterprise Architecture is stakeholder communication. Enterprise Architecture has a diverse audience including business and technical backgrounds, and each of the stakeholders needs to be addressed in a language that is clearly understood.</p><p>This gives us directly a number of essential qualifications for Enterprise Architecture tools: rigidity when it comes to the management and maintenance of knowledge, and flexibility when it comes to the analysis (ad-hoc, what-if, etc.), presentation and communication of the knowledge to diverse audiences.</p><p>So what you are looking for is a tool with solid repository capabilities, and flexible modeling and analysis functionality:</p><ul><li>Options to create manageable partitions of Enterprise Architecture knowledge such as models. Definition of these partitions should be flexible and fully customizable, while the tool offers functionality to make sure that integrity of the data over the various partitions is not compromised;</li><li>Management of versions, including life cycle (draft, approved, etc.), but also versions in time (current state, future state, etc.);</li><li>A metamodel that possesses just enough formality to model all aspects of the enterprise  (business, people, processes, technology) in a coherent and meaningful way, but is on the other hand flexible enough to customize and tailor to cover capturing organization specific information;</li><li>Flexible and ad-hoc modeling and analysis functionality is essential to deal with the various questions and concerns that stakeholders have regarding the Enterprise Architecture;</li><li>Reporting and communication features capable of slicing and dicing the knowledge in any way, and little restrictions on the format in which the knowledge can be presented to various audiences;</li></ul><h2>A single Enterprise Architecture tool or a set of tools that supports Enterprise Architecture?</h2><p>In the tooling business there are many vendors, some of them claiming to offer one-stop-shop Enterprise Architecture solutions. Given the diverse functionality that Enterprise Architecture needs, and the myriad of approaches organizations take on Enterprise Architecture based on their priorities, a one-size-fits-all solution does not often seem the best choice.</p><p>Take for example document management capabilities to support Enterprise Architecture governance on the one hand side, and multi-faceted ad-hoc model querying to support complex design decision making on the other hand. When trying to cover both in one tool you don’t usually get the best of the both worlds.</p><p>Often it is better to select a small number of specialized tools that can be aligned so that together they support the full spectrum of capabilities that Enterprise Architecture needs. This can sometimes be found in a “tool suite” from one vendor. But if the organization wants more flexibility to choose the best tool, they usually end up with tools that support open standards so that they can be easily aligned with other components in the organization specific Enterprise Architecture tool set.</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/resizedimage600498-Enterprise-Architecture-Repository.png” alt=”Enterprise Architecture Repository” title=”Enterprise Repository, Architecture Repository” width=”600″ height=”498″/><p class=”caption”>Enterprise Architecture Repository</p></div></div><p><a title=”TOGAF®, The Open Group Architecture Framework, is a proven, comprehensive and generic methodology and framework.” href=”http://consultancy/enterprise-architecture-management/togaf/”>TOGAF’s </a>description and depiction of the architecture repository gives a good overview of what the architecture content is that needs to be created, managed and maintained in an enterprise architecture environment. The architecture landscape often consists of descriptions using models to express the architecture on various levels: strategic, segment, and capability. Other model content includes solution architectures in terms of building blocks, and a library with reference models. The models are based on the organization specific meta model. Other types of data in the architecture repository include architecture requirements, a library of standards, governance data and data describing the architecture capability itself.</p><p>The architecture repository is often a conceptual thing rather than a physical implementation on a single database. Often, a set of tools are in use in an organization to support various processes and management of various types of data. The tools are aligned, e.g. based on the structure suggested by TOGAF, so that together they form a complete solution supporting the Enterprise Architecture capability.</p><h2>A fool with a tool…</h2><p>In this final part of this posting we want to address the actual use of Enterprise Architecture tools. In our practice we sometimes see organizations looking for off-the-shelve solutions that “do” Enterprise Architecture for them. It may sound as an open door, but in our opinion a tool should support enterprise architects so that they don’t have to bother about simple, straightforward, and activities with an administrative character. In that way, they can focus on the real design challenges that the organization faces: the activities with which Enterprise Architecture actually adds value to the organization. Talented and intelligent enterprise architects are those who ask the right questions, and who can reduce complexity with smart models. Tools should make the life of these architects easier by being flexible, supportive, and not imposing all kinds of cumbersome activities for simple tasks. Some Enterprise Architecture tools claim to automate the intelligent design work, and that Enterprise Architecture automatically “happens” once installed on the companies’ servers. In practice this is rarely the case. Effective architecture is all about the right architect using the right tool in the right way, or as we sometimes say: a fool with a tool is a still a fool making faster disaster.</p><p> </p><div class=”captionImage left” style=”width: 301px;”><img class=”left” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/Fool-with-a-Enterprise-Architecture-Tool-.png” alt=”Enterprise Architecture Fool with a Tool” title=”Enterprise Architecture Tooling” width=”301″ height=”222″/><p class=”caption”>Enterprise Architecture Fool with a Tool</p></div><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 using consultants for building Enterprise Architecture practices. It is scheduled to be posted between 11<sup>th</sup> and 15<sup>th</sup> of March.  </p>

Categories Uncategorized

Understanding the Strategy Diffusion Problem

“Everyone is trying to do their best but they don’t fully understand our strategy. As a consequence, we are getting better and better at things that don’t matter.” Senior Business Manager While most leaders have a good idea of what they want their organizations to do, they struggle to translate their vision into focused and […]