In the recent Garner report “Ten Criteria for Choosing an External Service Provider for Your EA Effort", 3 of the 10 criteria related directly to the architects from the External Service Provider (ESP):

6.5 Does the ESP Have a Standard Approach for Identifying and Developing Architects Within Its Pool of Consultants?

6.6 Does the ESP Have a Standard Way of Describing Architects' Levels of Competence?

6.7 Does the ESP Have a Consistent Way of Staffing the Right Architect With the Right Skills on the Right Project?

Gartner is quite right to include these in their criteria.  No issue has nagged the Architecture profession in general and the Enterprise Architecture discipline in particular as the challenge of identifying and developing architects.

I’ve often said that we play a cruel joke on most architects at some point in their career.  Since most architects start as developers they spend years learning to take large problems and efficiently break them down into smaller and smaller pieces until finally they get to a level of detail that they can readily translate into code.  Then after having proved their analysis skills sufficiently they are promoted to architect and told to do everything they used to do except backwards.

The programmer’s skill is analysis, but the core architect’s skill is synthesis.  This is not to say that architecture doesn’t require a great deal of analysis, but the critical step in architecture is often re-assembling the pieces into new higher-level constructs in order to get to that which is “architecturally significant”.  This is synthesis.

In his book “A Whole New Mind: Why Right Brainers will Rule the Future” Daniel Pink points out that analysis is a left-brain-directed skill, but synthesis is a right-brain-directed skill.

Yesterday I had jury duty; one of only two civic duties enumerated in the US Constitution – the other being voting (ok paying taxes might count as three, but let’s not go there).  Anyway, several hours of sitting in a court house did get me thinking about the “rules of evidence” for architecture.

A common pitfall that IT organizations fall into when trying to formalize the practice of architecture is to setup an architecture review broad (ARB) without proper foundation; specifically without setting down the rules of evidence for architecture.  In ancient times the village elders or some monarch dispensed justice without formal legal structure, but I’ve yet to see an ARB that wielded this kind of absolute authority over IT projects.

So just as modern courts are governed by rules of evidence, the ARB must define what is to be presented as part of an architecture review and what criteria is to be used to judge the fitness of what’s presented.  TOGAF™ provides a succinct description of the function of an “Architecture Board” without trying to define any strict formula for an ARB to follow.  Nor will I try.  Instead I’ll just focus on some of the basics.

Justice Potter Stewart said that he couldn’t define pornography, but “I know it when I see it”.  I often feel the same about the term “enterprise transformation”.  Not that there haven’t been many attempts at defining transformation; I just feel that most fall short of addressing the vernacular use of the word.  Particular they don’t address just what is it about transformational projects that make them harder than any other large project.  Nor do they help identify when “transformation” is required.

So let me posit a different term: inertia.  Often when we use the term “transformation” what we are really talking about is significant or sudden change in inertia.  Consequently the role of Enterprise Architecture can be defined in terms of how it is used to manage inertia in an enterprise.

In the following, I try to evaluate the semantic dimensions of “architecture” compounds – as a framework for structuring discussions, and facilitating communication. Subsequent postings will evaluate divergent interpretations of terms commonly used in the context of enterprise architecture, and provide recommendations how to handle these interpretations in interactions between architects.

Please contribute your own views on how the word architecture is used. It will be extremely interesting to gather additional aspects of the term.

Kind Regards

Thomas Obitz - Principal Architect

Composing “Architecture”

Within the IT community, the term “architecture” traditionally is used in one of three ways: One is as a characterization of an object (the “architecture” of a cathedral), the second is to describe the process of designing these architectures[2].  The third meaning – the profession of the architect – today is derived from the second[3].

In the characterizing context, an XYZ architecture can be (without claiming completeness)
·         the architecture of an XYZ (Enterprise Architecture - Architecture of an Enterprise)
·         an architecture for an XYZ (Enterprise Architecture - Architecture for an Enterprise)
·         an architecture describing the XYZ aspects of something (Information Architecture - Architecture describing the information assets of an Enterprise)
·         an architecture describing the aspects of “something” which are relevant for (constructing) an XYZ (Information System Architecture)
·         an architecture consisting of XYZs (Process Architecture - Architectural description consisting of process models)
·         an architecture in the state XYZ (Target Architecture)
As an art, we find “XYZ architecture” as
·         architecture using an XYZ approach (Enterprise Architecture – doing architecture using Enterprise Architectual approaches, even for a smaller unit than an enterprise, or for a government)

Architecture of an XYZ (constitutional)

 ISO 1471 talks about the “architecture of software intensive systems”, which was usually abreviated into “software architecture”. This straightforward interpretation has been transferred to the field of Enterprise Architecture only recently. The “Architecture of an Enterprise” therefore may describe the relevant aspects of an enterprise, the way an organization is structured, how its departments interact, and how they generate value.

Architecture for an XYZ (demarcational)

 The terms “Enterprise Architecture”, “Departmental Architecture” or “Line of Business Architecture” can be used to describe the scope an architecture is relevant to. An “industry architecture” is an architecture not of, but relevant to a specific industry. If used in this way, “Enterprise Architecture” does not explain what aspects it describes, but just that it applies to the enterprise as a whole. This missing description, however, can be inserted between the two terms: An Enterprise IT architecture describes the IT landscape for the enterprise, an Enterprise Data Architecture its data assets.

Architecture describing the XYZ aspects of something (projective)

 “Enterprise Business Architecture” can be used to describe the business aspects of an organization, i.e. the aspects related to achiving its vision and purpose. Enterprise Information Architecture describes the information related aspects of an organization, including their relationship to other architectures.
This use of XYZ architecture focuses on the aspects of architecture related to a specific concern. It therefore comprises the projection of architecture to a viewpoint or set of viewpoints, and hence is highly dependent on stakeholder concerns.

Architecture describing the aspects of “something” which are relevant for (constructing) an XYZ (contextualized)

 When John Zachman wrote his famous paper “A framework for Information Systems Architecture”[4], he spoke about much more than just information systems. His framework considers the context in which an organization builds such systems, and which influence their gestalt.
It is common to perform such contextualization in many compositions of the term architecture, and this approach can be considered as an extension of the constitutional use of the compound.

Architecture consisting of XYZs (compositional)

 When talking about “Process Architecture”, we are by and large talking about a documentation set composed of process documents. A similar thinking is behind the (outdated) perception of data architecture as a corporate data model.

Architecture in the state XYZ (state)

 Using the terms “as is” or “target” architecture describes a state in the development of architecture.

Architecture using an XYZ approach (method)

Architecture organized in an XYZ fashion (organizational setup)

Federated architecture is a way of performing architecture activities in a specific organizational setup. It can be used both for architectural deliverables (where deliverables of a higher level are detailed at the next level) as well as for a way of doing architecture (with a defined distribution of responsibilities between layers).

“Identify 10-12 [application] ‘architectures’ that are standard.  The challenge is to build a decision tree to drive the ideal architecture.

Q1: Are there any defined set of enterprise architectures?
Q2: Are there any decision analysis mechanism (like that for determining architecturally significant requirements in ATAM) already available?”

I’ve seen a few companies attempt to do similar although not quite this ambitiously.  Most organizations have started by identifying common architects that are already in use within the organization and generalizing them.  This has the decided benefit that the architects represent technology components already known to the organization and have proven implementations against use cases relevant to the organization.  I fear any effort to define a standard set of architectures outside the context of a well define problem domain (i.e. the environment of a given enterprise) would be too abstract to be practically applied within any given IT organization.

I have been consulting with a client’s Enterprise Architecture team and got around to reflect on questions that I have been asked in other contexts: Who are SAP Enterprise Architects? What (if anything) is different about Enterprise Architecture in a product/ERP landscape?

The client, lets call it MyCorp, is a multi-billion dollar global manufacturing company with a few core lines of businesses. The business and IT operations are managed by geographic units for Latin America, North America, Europe and Rest of the World. MyCorp`s IT is supported by a federated team of Enterprise Architects . As with most multinationals, MyCorp has several “key” ongoing technology and transformational initiatives that the Enterprise Architects are supporting. So what is unique about MyCorp`s Enterprise Architecture focus? Besides the fact that every organization is “unique,” this happens to be a “SAP Shop.” Which is to say the IT application landscape is predominantly a mix of SAP tools and technologies and in pockets where it is not, there is a roadmap to move towards this direction.

In my previous EA blog entry, I had written about contextualizing Infosys’ Enterprise Architecture survey findings. Since then I had an opportunity to observe and reflect on an aspect of the survey: adoption – and challenges - of Enterprise Architecture Tool at a Global 500 enterprise. To set the context for the discussion, a brief extract from the survey report as it pertains to adoption of EA tools:

• There is an increased adoption of EA tools, but there is no product which has managed to dominate the market
• The EA tools market is fragmented with the vast majority of respondents claiming to use general office and collaboration tools and drawing tools (e.g. Microsoft Visio) for Enterprise Architecture Modeling

This should not surprise many of us in the industry!

######

Dear All
Some of you may have participated in the Infosys’ Enterprise Architecture Survey 2008/2009. Attached is a soft-copy of the survey findings.

One of the key findings is that participants of the survey saw Enterprise Architecture as a capability that was core to their business and inherently part of their organization's crown jewels. However, given the daunting set of activities that most Enterprise Architecture functions have to execute today, the opportunity to work with ESPs and enlist them to execute some of these activities is real. In other words, some activities (the more tactical ones), can be outsourced to a strategic vendor partner.

Form an Architecture Governance Team
 

• A central team constituted with representation from stakeholders across the organization, should govern the planning, evolution and implementation of an Enterprise Architecture framework
   
• Architecture should be well thought through to meet the common goals of all stakeholders.
   
• The central team also should play a key role in establishing products, design and technology standards
  

During the past few weeks I got involved in an interesting activity: analysis and review of responses to the 2008 Enterprise Architecture survey that Infosys has been conducting annually for the past few years.
 
This year, we invited technology leaders from our client base and the global IT community to participate. 207 respondents from a cross-section of industry verticals, geographies and organizational sizes completed a web questionnaire of 24 detailed questions.  A preliminary analysis of the results indicates a few trends, including:

• Enterprise Architecture is enabling business transformation [Does this surprise me?]
• EA practices continue to mature with increasing use of metrics and processes [Again no surprises on this front]
• Outsourcing of activities focused at Enterprise Architecture is an opportunity that most EA teams have not seriously considered [Now, this is interesting]