Search Results for: zachman

Humility and the Art of Enterprise Architecture

by

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!)

Addressing the Multi-Dimensionality Challenge on Thinking of The Enterprise as a System

by

Last week I had the pleasure of attending and presenting at the Open Group conference in Newport Beach, California.  I find these conferences enlightening as I enjoyed the dialog with fellow professions who share similar point of views on the&nbsp…

Addressing the Multi-Dimensionality Challenge on Thinking of The Enterprise as a System

by

Last week I had the pleasure of attending and presenting at the Open Group conference in Newport Beach, California.  I find these conferences enlightening as I enjoyed the dialog with fellow professions who share similar point of views on the discipline of Enterprise Architecture.   I have made the following observations: We have a huge challenge in…

Open Work: first notes

by

Open Work


image

An initial sketch of ideas around the concept of ‘Open work’, a developing idea for a manifesto for a new way of working that leverages concepts around openness and technology that enables openness to enable us all to work better, together.

Other than this preamble this is a straight dump of notes i’ve been jotting down, just thought i’d get it out there on the blog as a vehicle for making myself think more deeply about what i want to achieve. My plan is to start fleshing these notes out, into principles (hey i’m an architect!) and trace these concepts to some reality. When I first started thinking about these ideas I happened upon david cushman’s great writing (http://fasterfuture.blogspot.co.uk/2012/07/the-10-principles-of-open-business.html) on the area of ‘open business’, so i’m mindful not to re-hash or at worst plagiarise David’s thoughts (you’ll notice some of my headings map to some of david’s principles.

So my plans consist of trying to frame some interesting and hopefully original thinking, whether this ends up as a post on my blog an ebook, or whatever, i’m not really sure, I’ve just got fed up of thinking things through, so thought its about time I should start, er, writing them through.

concepts/principles

-Context
-radical sharing/shariarchy
-discovery
-foster emergence
-Social architecture: (thinking stack/zachman etc)
-connectedness (connectivity and psychological sense by what? shared vision?
-finding
-serendipity
-ego-less
-embrace criticism but by embracing criticism how to avoid paralysis (too many arguments)
-Clear threshold for decision making – stops paralysis
-radical un-secrecy
-Virtual Structures
-Now-ness – relate to the when/tenses of sharing future, past, present
-Presence
– Energy

Current State:

-No opportunity for serendepity
-Closed networks
-Entropy

Trends:

-Privacy as commodity
-Hyper sharing
-High bandwidth communication/consumption

Thoughts:

There is no reason not to share
There is no impediment to sharing

Categories Uncategorized

Enterprise Architecture Roadmap for success: Adopting an open approach to Enterprise Architecture

by

<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>

Categories Uncategorized

Enterprise Architecture – A Perfect Tool for Operating Model Management

by
On this blog I have covered the discipline of Enterprise Architecture from a number of perspectives. Enterprise Architecture (EA) can be effectively leveraged as a foundation for Industry Reference Architectures e.g. The Retail Reference Architecture. Equally effectively EA can also be leveraged as the mechanism for Business and Technology Governance as well as Technology Performance Monitoring. In this article I would like to propose that Enterprise Architecture is also an effective tool for the Operating Model management, both for the definition as well as the ongoing lifecycle management. 
It may be worthwhile visiting some industry definitions for Operating Model before we explore how Enterprise Architecture can be effective here. The definition of Operating Model varies based on the Organisational and Operational context in which it is applied and hence probably one definition may not fit all Operating Model scenarios. However if I had to choose one definition, I would like to refer to the IBM’s definition of the Operating Model (see the picture below)
IBM Target Operating Model (TOM)

IBM proposes that a Target Operating Model (TOM) helps determine the best design and deployment of resources to achieve an organization’s business goals. It provides current operational maturity assessment and roadmap to defining and/or improving organisation’s Operations Strategy. Key deliverable include business review, current operating model assessment, desired future state and change management plan roadmap.
The TOM essentially is seen here as the mechanism to link the business goals and strategy of the organisation with the roadmap for change to achieve those goals. TOM then holds together various organisation concerns such as processes, technology, capabilities, customer view, governance and partners in a single cohesive fashion.
 
Now that we have briefly summarised an illustrative Operating Model definition, let us explore how Enterprise Architecture as a discipline or practice can be leveraged as a tool for its management. There are a number of good Enterprise Architecture Frameworks available for this purpose and recent revisions of certain frameworks have further established them as leading candidates for this purpose. I do not advocate or support a specific Enterprise Architecture Framework on this blog however for illustration purposes I am going to be using the TOGAF 9 as the tool for Operating Model Management. I would like to also mention the Zachman EA framework as the other leading framework which may be equally effective or in some application scenarios it may be a better fit. 
The purpose of this article is not to explain or define the TOGAF 9 and I would highly recommend visiting the OpenGroup website for relevant documentation. However for the ease of reference, I am going to share the TOGAF ADM which is the process for Enterprise Architecture Management in TOGAF. 
The process links the Vision and Strategy of the Organisation and its business / functions with a portfolio of change programs which realises this Strategy. TOGAF uses various architecture disciplines such as Business Architecture, Information Architecture (Data and Application) and Technology Architecture as mechanism for linking the Strategy with Implementation and Governance of Change programs to deliver on the Strategy. 
The central argument which I am now going to make is that such a process of Enterprise Architecture can be seamlessly deployed and leveraged to manage the Organisation Operating Model. A number of Enterprise Architecture Frameworks and especially Zachman categorically state that the application of Enterprise Architecture should not be restricted or limited to the Information Technology systems. It is a true framework for organisation and business management. For instance applying the TOGAF to manage the IBM TOM will result in following steps / mapping. The key here is to use tools, processes, approach, templates and constructs from each of the TOGAF ADM stage to define and develop the TOM stages as seen in figure – 1. 
  1. The business goals and strategy can be defined by the Preliminary phase while the vision underpinning this is defined in Phase A. Architecture Vision
  2. The Assets and the Locations of the TOM along with key processes can be captured and defined during the Phase B. Business Architecture
  3. Certain aspects of skills, capabilities, culture and processes too can be captured in Phase B
  4. The Technology, Processes, Performance Metrics can be captured through phases C and D while defining the Information and the Technology Architecture.
  5. The sourcing options and alliances can be identified and shortlisted in phase E. Opportunities and Solutions
  6. The phase F of migration planning can be used to identify the roadmap for change through what TOGAF calls as transition architectures
  7. Finally culture which is central to TOM needs to be constantly be a driving force as well as the recipient for the requirements for change
I would like to again highlight that this is simply an illustration of managing a view of Operating Model with a particular EA approach. However a number of other variations can be equally effectively managed by similar approach. It will probably make sense to present an illustration and mapping using other EA framework such as Zachman…may be a topic for next post on this blog!

References:

Strategy and transformation for a complex world, IBM Global Services, Mar 2011

The TOGAF Architecture Development Method (ADM)

The Zachman Framework

Enterprise Architecture – A Perfect Tool for Operating Model Management

by
On this blog I have covered the discipline of Enterprise Architecture from a number of perspectives. Enterprise Architecture (EA) can be effectively leveraged as a foundation for Industry Reference Architectures e.g. The Retail Reference Architecture. Equally effectively EA can also be leveraged as the mechanism for Business and Technology Governance as well as Technology Performance Monitoring. In this article I would like to propose that Enterprise Architecture is also an effective tool for the Operating Model management, both for the definition as well as the ongoing lifecycle management. 

It may be worthwhile visiting some industry definitions for Operating Model before we explore how Enterprise Architecture can be effective here. The definition of Operating Model varies based on the Organisational and Operational context in which it is applied and hence probably one definition may not fit all Operating Model scenarios. However if I had to choose one definition, I would like to refer to the IBM’s definition of the Operating Model (see the picture below)
IBM Target Operating Model (TOM)

IBM proposes that a Target Operating Model (TOM) helps determine the best design and deployment of resources to achieve an organization’s business goals. It provides current operational maturity assessment and roadmap to defining and/or improving organisation’s Operations Strategy. Key deliverable include business review, current operating model assessment, desired future state and change management plan roadmap.
The TOM essentially is seen here as the mechanism to link the business goals and strategy of the organisation with the roadmap for change to achieve those goals. TOM then holds together various organisation concerns such as processes, technology, capabilities, customer view, governance and partners in a single cohesive fashion.
 
Now that we have briefly summarised an illustrative Operating Model definition, let us explore how Enterprise Architecture as a discipline or practice can be leveraged as a tool for its management. There are a number of good Enterprise Architecture Frameworks available for this purpose and recent revisions of certain frameworks have further established them as leading candidates for this purpose. I do not advocate or support a specific Enterprise Architecture Framework on this blog however for illustration purposes I am going to be using the TOGAF 9 as the tool for Operating Model Management. I would like to also mention the Zachman EA framework as the other leading framework which may be equally effective or in some application scenarios it may be a better fit. 


The purpose of this article is not to explain or define the TOGAF 9 and I would highly recommend visiting the OpenGroup website for relevant documentation. However for the ease of reference, I am going to share the TOGAF ADM which is the process for Enterprise Architecture Management in TOGAF. 
The process links the Vision and Strategy of the Organisation and its business / functions with a portfolio of change programs which realises this Strategy. TOGAF uses various architecture disciplines such as Business Architecture, Information Architecture (Data and Application) and Technology Architecture as mechanism for linking the Strategy with Implementation and Governance of Change programs to deliver on the Strategy. 
The central argument which I am now going to make is that such a process of Enterprise Architecture can be seamlessly deployed and leveraged to manage the Organisation Operating Model. A number of Enterprise Architecture Frameworks and especially Zachman categorically state that the application of Enterprise Architecture should not be restricted or limited to the Information Technology systems. It is a true framework for organisation and business management. For instance applying the TOGAF to manage the IBM TOM will result in following steps / mapping. The key here is to use tools, processes, approach, templates and constructs from each of the TOGAF ADM stage to define and develop the TOM stages as seen in figure – 1. 
  1. The business goals and strategy can be defined by the Preliminary phase while the vision underpinning this is defined in Phase A. Architecture Vision
  2. The Assets and the Locations of the TOM along with key processes can be captured and defined during the Phase B. Business Architecture
  3. Certain aspects of skills, capabilities, culture and processes too can be captured in Phase B
  4. The Technology, Processes, Performance Metrics can be captured through phases C and D while defining the Information and the Technology Architecture.
  5. The sourcing options and alliances can be identified and shortlisted in phase E. Opportunities and Solutions
  6. The phase F of migration planning can be used to identify the roadmap for change through what TOGAF calls as transition architectures
  7. Finally culture which is central to TOM needs to be constantly be a driving force as well as the recipient for the requirements for change
I would like to again highlight that this is simply an illustration of managing a view of Operating Model with a particular EA approach. However a number of other variations can be equally effectively managed by similar approach. It will probably make sense to present an illustration and mapping using other EA framework such as Zachman…may be a topic for next post on this blog!

References:

Strategy and transformation for a complex world, IBM Global Services, Mar 2011

The TOGAF Architecture Development Method (ADM)

The Zachman Framework

Metaframeworks in practice, Part 5: Enterprise Canvas

by

What frameworks do we need, to link across all domains and layers of the enterprise-architecture space? How can we create such frameworks? This is the fifth and final item in this series of worked-examples of metaframeworks in practice – on how to…