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

December 10, 2010

Cloud Services - Design Considerations

By Brahma Acharya

We all realize that SOA and Cloud computing go hand in hand and are complementary in nature. After all we talk, about everything as a service (XaaS) in the Cloud world. So the immediate question that comes to mind is, would the service that has been designed to be consumed in-house would serve equally well if it were hosted on the cloud? The answer apparently is "Not really". Services designed as per SOA principles (clear contract, standalone functionality) would probably be much easier to migrate to Cloud, but there certainly is a need to re-look at some of the design patterns that will be crucial in cloud orienting the services. Let's identify some of the crucial ones.

Continue reading "Cloud Services - Design Considerations" »

November 17, 2010

SOA Appliance - Opportunities and Barriers

by Infosys SOA Architect Community

One of the biggest concerns that our clients highlight to us in any large scale SOA implementation is performance. "Will my application meet the NFRs? Will it scale up as I have more and more service consumers?". These are the most commonly asked question from our clients. And there is a reason for that. Web services technology have become the de-facto standard to create and expose services. Web services, be it SOAP based or REST based rely heavily on XML suite of technologies. XML is notoriously bulky and is slow to process (yes..there are optimization but that is another story) thereby making SOA applications slow performing. And Performance is something nobody wants to compromise on. Then there are concerns of security and complex deployment process which are more pronounced in a SOA based application.

Continue reading "SOA Appliance - Opportunities and Barriers" »

November 11, 2010

To ESB or Not to ESB

by Infosys SOA Architect Community

ESB has become the de-facto architectural standard in any large scale SOA implementation and with good reason. But does that entitle the usage of ESB for all and sundry? Is the usage of ESB actually detrimental to the very concept of SOA in the long run? Here is a thought provoking article by Michael Poulin on the subject:


An ESB provides the VETRO capabilities on the messages which means an ESB can
- Validate the message for authenticity and correctness
- Enhance the message if necessary
- Transform the message if the service provider and service consumer differ
- Route messages to the appropriate service providing virtualization
- Orchestrate services and provide a new set of services

Continue reading "To ESB or Not to ESB" »

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

March 19, 2010

Architects are Right-Brain Thinkers

- Jerry Larivee

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.

Continue reading "Architects are Right-Brain Thinkers" »

March 11, 2010

5 Questions for IT Organizations to worry about

Changes are taking shape. Some are evident, many are like undercurrents, yet not prominently visible but slowly moving the needle, like global warming. I'm talking about the changes in the industry with respect to future of IT and IT organizations. Where businesses stand today and what they need in future, how much ready are IT organizations to make it happen for them?

Continue reading "5 Questions for IT Organizations to worry about" »

February 27, 2010

“Information as service” is a strategic enterprise level initiative in service orientation journey

By Murteza Salemi

Information in SOA world is often considered only within the context of specific services and processes whilst the most awaited gains and benefits of SOA investment is business information availability throughout the organization and to its partners and regulators. When an organization embarks on SOA and integrates its internal systems across LOB’s it will soon discover that there are inconsistencies in its information that was not visible before as it was hidden within various silo applications and data sources.

Continue reading "“Information as service” is a strategic enterprise level initiative in service orientation journey" »

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