Search Results for: methodology

Managing transformation: principles or methodology first?

by

Having previously worked for a global tier-1 business/IT consulting firm, one of the practices I have taken pride in is the prevalence of “best practice” frameworks and methodologies for solving common problems. Doing enterprise transformation? Fine, let’s apply our architecture framework. In need of a different technology strategy? We have a nice digital strategy framework […]

When methodology is diverted

by

Methodology is a set of methods and procedures describing how to reach a result. Every enterprise developing products or services makes use of various development methodologies [1] but they are sometimes diverted from their original intent, for example for project management [2] purposes. As for projects, the application of methodology produces “deliverables” [3], for example […]

Collaborative Planning Methodology (CPM)

by

I think most can agree that enterprise architects have been getting more and more narrow in terms of the scope of planning that they touch.  In reality, executives and decision makers need a single complete plan of action.  They ask, “what do I need to do, how do I secure it, how much will it cost, and when can it be done?”  As enterprise architects have drifted away from solution […]

Zachman Certified™ – Methodology

by

Zachman Certified Methodology

The Zachman Certified™ – Methodology designation is based upon a mapping of the metamodel of the Methodology to the meta model of The Zachman Framework™, essentially answering the following questions:

  • Does the Methodology produce primitive models that conform to The Framework metamodel from which the methodological composite implementations are derived?
  • Which primitive models (Cells) does the Methodology produce?
  • Which horizontal integrations are supported in the creation of the implementation composites?
  • Which vertical transformations are supported in the realization of the instantiations?
  • Does the Methodology infer diagonal composites from horizontally and vertically integrated primitives?

Certification fees are assessed per cell.

There are two parts to this certification. In the first part, the requester identifies which cells are to be considered for certification. The cells considered are evaluated and objectively given a numerical rating (Coverage Index) based on the primitive models and the components in relation to the entire Framework set. If a cell wins the designation as “Zachman Certified™ it will be so marked. If only some portion of the cell is formalized, the cell may be considered “authorized” and a portion of the certification fees assessed proportionately.

Zachman International is responsible for the second part. Additionally, as part of the certification process and fees, we will then perform an analysis on the capacity and robustness of the integrations across each row and transformations down each column for each “certified” cell. An objective, numerical rating will be assigned based upon the percentage of the total possible integrations and transformations (Capacity Index) and their degree of association (Robustness Index) which will be reported and posted on the Zachman.com site.

The important thing about the Methodology Certification is that it confirms that Enterprise Engineering work is being accomplished as opposed to merely Systems Building work. The evaluation of the quality or appropriateness of the Methodology should be based upon the Enterprise Engineering design objectives… which Primitives does the Enterprise need to get under control and from which “architected” Primitives must the Enterprise’s implementations and realizations be composed.

To submit your methodology for review, please contact our Standards Department.

Zachman: Not a Point of Departure for an Enterprise Methodology

by

I have spent the last few days reviewing the most contemporary Enterprise Architecture (EA) frameworks. As I am trying to establish a common description of the methodology behind EA, my goal is to sketch the intersection of methodological assumptions these framework impose on organisations. However, the analysis is still on a very high level of abstraction as my goal is a cross-framework conceptualisation. Of course, every framework has its own domain of application, knowledge, and assumptions, and the analysis is fully aware of that.

People usually refer to the Zachman Framework when addressing EA’s point of departure. John Zachman published his famous first words on enterprise integration in the IBM Systems Journal publication A Framework for Information Systems Architecture in 1987, and he is still regarded by many academics and practitioners as the father of the discipline itself. In 2009 I even had the pleasure of following John Zachman presenting an updated version of his framework, and it was definitely inspiring and valuable. Besides being the first to propose an important quantum leap in the integration of business and technology, Zachman is also an excellent speaker and entertainer.

However, my analysis does not depart from Zachman’s original writings, and that is with a specific reason. Zachman has continuously emphasised that his framework concerns structure and taxonomy, and in general not process or methodology. The Zachman Framework is specifically focused on representing a static state, taxonomy, or blueprint of an enterprise, but not how the enterprise has grown the architecture over time — no development methodology is prescribed. It is merely a snapshot or slice of the enterprise at a certain point in time. As Zachman puts it: “The Zachman Framework is a schema. […] More specifically the Zachman Framework is an ontology […] The Zachman Framework is not a methodology.” Zachman’s classification structure is very useful for systematically classifying and describing the current state (or future state) or an architecture, but in my opinion he poses some fundamental erroneous assumptions about methodology and ontology — and manages to represent it in a misleading way:

– The definition of an ontology is (according to Wikipedia): “the philosophical study of the nature of being, existence or reality in general, as well as the basic categories of being and their relations.” Let us for a moment assume that it is the second sentence that Zachman focused on when using the word ontology in his writings. Ontology is in the first place quite a big word (or efficient discourse) to use when describing one out of many frameworks, and I agree with Dave Snowden when he postulates that the word taxonomy is a much better concept in the context of enterprises.

– Given that ontology concerns the “basic categories of being and their relations”, Zachman must assume that a being is already in place, and that this being is involved in the creation of the relations. Being assumes a process, the creation of something — taking part in the world — or maybe less dramatic: the organisational field — over time. But if Zachman’s schema only concerns the organisation at a single point in time, how can it truly represent the inherent causality between the objects it claims to classify in an efficient way? A complete description of the objects and their interdependencies within an enterprise must assume a certain level of context within time and space. A snapshot for putting the enterprise in a context is simply not enough. And as ontology assumes both causality and being, Zachman’s framework simply is not an ontology. Similarly, Mendeljev’s periodic table (which Zachman often uses as an powerful analogy to his own concepts) not only describes the static composition of atoms (implies structure), but also how atoms evolve over time (implies process) as they wobble between a stable and unstable state. Again, Zachman’s use of the term ontology is insufficient.

In short: the word ontology is simply too strong a discourse for a classification system, and a snapshot classification is again not sufficient for efficiently describing an organisation without loosing important information. How and why the organisation is in its current state are in my opinion two major prerequisites that need to be determined before we can describe an optimal future state, and the Zachman Framework is in a conscious manner sawing off the branch that its own reality check with methodology sits on.

In my search of enterprise methodologies, I have decided to take GERAM – The Generalised Enterprise Reference Architecture and Methodology — as my point of departure. Peter Bernus, one of the authors behind the framework — presents it as a meta methodology for describing reference architectures: “Potentially, all proposed reference architectures and methodologies could be characterized in GERAM”— whilst emphasising the framework’s ultimate purpose of methodological unification:

“GERAM is intended to facilitate the unification of methods of several disciplines used in the change process, such as methods of industrial engineering, management science, control engineering, communication and information technology, i.e. to allow their combined use, as opposed to segregated application.”

The IFIP-IFAC task force certainly created the first real stepping stones towards a true ontology and methodology for formally characterising and representing an enterprise in context. After all, that requires an inclusion of both structure and process, and these cannot be separated without leaving out important knowledge about the enterprise itself.