7 years, 11 months ago

Why I’m Excited About the iPad

While my iPad will arrive in “late April,” I’ve been following all the buzz this week, reading reviews, checking out the app store, etc. Late April can’t get here soon enough in my opinion. Here’s what has me so excited about it. I’ve always preferred taking notes electronically, but in the past three or fours, […]

7 years, 11 months ago

Distortions leads to Cancerous Growth within Enterprise

Programmed Cell Death is very important function to understand to gain insight into the way Transformation need to occur. When distortions occur in Enterprise Engineering, then this leads into obvious cancerous growth, which does not have easy remedy. …

7 years, 11 months ago

Enterprise Architecture IS (should not be) Arbitrary

I took a look at a blog entry today by Jordan Braunstein where he comments on another blog entry titled “Yes, “Enterprise Architecture is Relative BUT it is not Arbitrary.”  The blog makes some good points such as the following: Lock 10 archite…

7 years, 11 months ago

Coherency Management in Carlsberg

Mikkel Mertz, Morten Gryning and Ambreen Khan have allowed me to share their masters thesis about Coherency Management in Carlsberg. I warmly recommend it! Abstract Even though the amounts of information in enterprises are rapidly increasing, it does not directly provide the organizations with competitive advantages. A paradox of the Information Age is that while

7 years, 11 months ago

Service Provider Paradigm Shift for Enterprise Architecture Teams

I recently had the opportunity to share an idea with a group of enterprise-level Architects and received a healthy bit of positive feedback on the idea. So, I think its worthy to share more broadly.

Most, if not all, Enterprise Architects have witnessed challenges delivering a successful Enterprise Architecture Team. I certainly have observed failings and I’ve been involved in failures directly. My Enterprise Architecture team has tried something a bit different that seems to be working and I’d like to share it with you.

The basic premise is that traditional Enterprise Architecture teams tend to lean toward delivering things like:

  • Conceptual Information Models
  • ‘Stick’ Governance Models
  • Principles and Standards
  • Position Whitepapers
  • Architecture Review Board Sessions
  • Consultative-only advice

While all of these are nice to have, by themselves I believe they lead to the Ivory Tower. It’s no wonder why Enterprise Architecture teams that only do the above also tend to have the following challenges:

  • Struggle to prove valuable
  • Struggle to be influential
  • Struggle to be relevant
  • Struggle to be enterprise-wide

About a year ago, my team was engaged on an enterprise problem commonly known as Enterprise Strategic Planning, which for us was about addressing three CIO concerns for the purpose of portfolio management/funding allocation of project dollars. The portfolio managers need to know:

  1. IT and Business Alignment
  2. Gaps and Overlaps
  3. Technology Investments

At this point, we could have participated to support the Enterprise Strategic Planning effort by delivering things noted above as a traditional Enterprise Architecture would. Instead, we decided to take a different approach. We decided to adopt the Service Provider business model equipped with Service Offerings. We call it Enterprise Strategic Planning (ESP) Service and our Service Offerings include; ESP Collaborative Process, Roadmaps, Analysis, IT Proposals, Standards Alignment, and Enterprise Model/Taxonomy Maintenance. All of these are geared to delivering direct value to IT organization’s planning needs.

Mind you, we use Conceptual Information Models, principles and standards, etc but this is primarily behind the scenes and they often don’t surface in discussion unless one of our stakeholders asks a probing question of our service offerings. This is important, I’m not suggesting to ignore delivering traditional EA artifacts like CIM, position whitepapers, etc. We deliberately use them to ensure our offerings are of high quality and fidelity. High quality and fidelity are important characteristics of our brand we must manage carefully.

The paradigm shift is moving from a traditional Enterprise Architecture team to a Service Provider. We manage the ESP Service as a product line with offerings, we have a business plan, we have a strategy, we have a market with competition, we have a balanced scorecard to monitor our success to our strategy…just like any well-managed business.

A couple of interesting outcomes that are largely due to this shift:

  • We no longer have the challenges mentioned above. We deliver value with explicit associations to enterprise problems. We are more influential than ever because we have voting-rights on enterprise decisions, We are highly relevant to important decisions as evident by our engagement with our company’s top brass. We are only engaged on enterprise-level problem areas.
  • I don’t have the additional problem of having to sell Enterprise Architects. Previously, I would have to take time to explain how an Enterprise Information/Business/Infrastructure Architect is relevant to problems and decision making. Now, I simply deliver an offering that is required for a decision affecting our enterprise to occur. I hire Enterprise Information/Business/Infrastructure Architects to deliver the offering.
  • I don’t have to ask to be influential. Our offerings are a requirement. Our deliverables are not an option. Because they implicitly have our thinking built-in, they influence our organization implicitly without having to spend a tremendous amount of effort winning relationships. Btw, I’m not saying we don’t require unbelievably strong relationship skills (aka emotional intelligence), we do.

My suggestion to you all is “Don’t build Enterprise Architecture teams/functions to have Architecture. Instead, solve enterprise problems with Enterprise Architects.”

Categories Uncategorized
7 years, 11 months ago

Enterprise Architect: Advisor versus Gatekeeper

A recent conversation with a colleague delved into the complicated world of new technology decisions. At every organization I’ve been at, this has been a source of contention between four major groups: Enterprise Architects, Domain Architects, Development Teams, and Engineering Teams. I specifically listed Enterprise and Domain Architects separately, because I’ve seen contention between those […]

7 years, 11 months ago

SOA Checklist

In a recent meeting, the customer brought up a valid question: “How do I know if a problem/system is a good candidate for using SOA (vs. using old but trusted techniques).  I put this checklist together.  If you can answer yes to 2 or more of these…

8 years, 1 day ago

Zachman: Not a Point of Departure for an Enterprise Methodology

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.