Using Enterprise Architecture to achieve competitive advantage through IT. Are you successful?

Main

March 28, 2010

Use of Agile in Enterprise Architecture

- Jerry Larivee

At this risk of sounding like a management, motivational speaker there is one consistent piece of advice that I give to IT organizations over and over and over again when undertaking large initiatives: start small and build in incremental steps.  This is particularly true for Enterprise Architecture groups.  It is in this spirit that I recommend the adoption of agile methods within the Enterprise Architecture groups, even if agile is not used within the application development groups of the organization.

Agile methods can be successfully applied to all sorts of Enterprise Architecture activities, but to illustrate its applicability let’s look at how agile applies to the development of a standard technology platform for application development.  What I mean by a technology platform is a set of standard technology components and reference architectures that can be used by application development projects within the organization, such as a platform for e-commerce applications, or a platform for Java-based, web development, etc.

While we’re on the subject of using agile development, I’ll also cover what considerations one might take into account while defining a technology platform to maximize the benefits of agile methods in application development.

First let me level-set with quick a definition of agile.

Continue reading "Use of Agile in Enterprise Architecture" »

February 2, 2010

Rules of Evidence for Architecture

- Jerry Larivee

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.

Continue reading "Rules of Evidence for Architecture" »

January 28, 2010

Transformation, Inertia and Enterprise Architecture

- Jerry Larivee 

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.

Continue reading "Transformation, Inertia and Enterprise Architecture" »

January 15, 2010

On the intricacies of composing the word “Architecture”

As a participant of many discussions on Enterprise Architecture – the most insightful I had the opportunity to take part in as a member of the Open Group Architecture Forum – I found that attempting  to define terms like “Enterprise Architecture” or “Business Architecture” tends not to result in conclusion. While part of these divergencies are due to different contexts of the participants, most of them seem to stem from the ambiguous semantics associated both with the construct of a compound in English language, as well as with the ambiguous use of the word “architecture”[1].

Hence, I thought it would be helpful to describe these uses of the composite “XYZ architecture” in the context of the Enterprise Architecture discipline. This should facilitate communication between Enterprise Architects by raising awareness for these diverging connotations. It by no means suggests favouring either of these semantics.

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 using a specific approach, or a specific framework (TOGAF architecture)

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



[1] This paper assumes that the meaning of he compound “XYZ architecture“ actually can be analysed as a specialization of the meaning of “architecture” by the term “XYZ”. This is not self-evident. Linguistically, we assume that XYZ architecture is an endocentric compound with the head “architecture”.  Its semantics could be structured in a completely different way: An exocentric compound has a meaning which relates to another, elided term (a redhead is not a head, but a red-headed person). And even interpreted formally as an endocentic compound, the combination of two words can attract a meaning over time which is detached from its constituents – a “blackboard” is not just a board which is black, it is a thing with a special purpose (and actually tends to be green). For a long time, “Enterprise Architecture” has been used in a way which was rather defined by its use in the IT and IT analyst community, than influenced by its constituent terms. For details on the semantics of composition, refer to http://en.wikipedia.org/wiki/Compound_(linguistics).
[2] This paper will not try to define the term architecture to any further extent, nor will it try to define any of the terms architecture is composed with, as such definitions do not further the understanding of the challenges resulting from their composition.

[3] In the IT space, everybody who claims to do “architecture” – whatever he defines it to be – is considered an architect. In traditional “building” architecture, the profession comprises of aspects like specific business models, codified education, professional bodies, and a legal framework to enforce these structures.

[4] John A. Zachman, A framework for Information Systems Architecture, IBM Systems Journal Vol 26 Issue 3 pp276-292, 1987

January 11, 2010

Creating Practical Standard Architectures

A colleague posed this problem statement recently:

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

Continue reading "Creating Practical Standard Architectures" »

April 29, 2009

Demystifying Enterprise Architecture in an ERP landscape: Who are SAP Enterprise Architects?*

Mohan Babu K 

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.

Continue reading "Demystifying Enterprise Architecture in an ERP landscape: Who are SAP Enterprise Architects?*" »

December 15, 2008

Role of an Architect: Lessons from the movies - Part 8

- Amit Jnagal, Senior Technical Architect, Infosys

In my last post, I talked about the movie My Cousin Vinny and the lessons it held for Architects about sticking to the basics, understanding your customers and understanding yourself.
In this post, I am going to look at The Pursuit of Happyness (Year of Release: .2006; Director: Gabriele Muccino; Our Architect: Chris Gardner played by Will Smith; Architect's Character: Sales Man turned stock broker who know how to dream big and keep it going).

‘The pursuit of happyness’ tells the story of the trials and tribulations of semi-successful sales man for whom every day is a struggle. The essence of this movie is how to dream big and manage it along with the daily struggle. We usually get too involved in the tasks that are assigned to us and find very little or no time for stuff that matters outside assignments. Very few other industries, other than ours, have employees who are up to speed with the usage of the term ‘work life balance’ and how it affects them.

Continue reading "Role of an Architect: Lessons from the movies - Part 8" »

November 7, 2008

Enterprise Architecture Enabling Strategies

EA enabling strategies and principles should be specific to each enterprise; And is governed by its business strategy by a large extent.  In recent times, some common EA enabling strategies, in one way or the other, have influenced EA more than the others. This entry is an attempt to identify some of those more ubiquitous and important ones, that may further be elaborated on case to case basis.

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

Continue reading "Enterprise Architecture Enabling Strategies" »

August 1, 2008

Reason, Stakeholder Engagement / Management and EA

Current issue of the New Scientist magazine has a very interesting cover story on “Seven reasons why people hate reason”.  Now, that is a guide I would have loved to have alongside during some rather difficult stakeholder engagements, when I couldn’t stop thinking “If only they could be reasonable…”.

Continue reading "Reason, Stakeholder Engagement / Management and EA" »

July 31, 2008

The most important considerations for Enterprise Architecture projects

As part of a proposal, a prospect asked us to provide the 10 most important pieces of advice for an EA team. Wow, I thought, that’s a really good question. And short of being able to do an awful lot of literature research (I am still on this assignment in the Middle East, and my library is at home back in Frankfurt), I just took a shot.

I did not manage to get together 10 guidelines, but have a look at these 4 – and please feel free to fill in with your own experience.

Continue reading "The most important considerations for Enterprise Architecture projects" »