TOGAF 9.1 Released – What does it mean to you?

If you are planning to take up TOGAF certification examination, you would definitely want to know how the release of TOGAF 9.1 impacts you. You would want to which version you need to study.

Here is the simple guideline. If you are planning to appear for the exam…

  1. …before June 2012 the you should study TOGAF 9
  2. …between June 2012 and May 2013 then you can study either TOGAF 9 of 9.1
  3. …after June 2013 it is only TOGAF 9.1

In a nutshell, if you have already done most of the studying using TOGAF 9.0 then you have slightly more than a year to clear the exam. However, if you have yet to begin the study you better start with 9.1.

What are the main differences between TOGAF 9 and 9.1?

The Open Group has published a presentation in the form of a PDF which provides an overview of the differences – here is the link.

If you would prefer to have a look at the difference as a two pager then I recommend that you go through this post of Mike Walker.

However, I think the biggest difference between the two is how the objectives of each of the ADM phase are written. The latest version seems to be significant improvement. This is also the most important change for those of you who want to appear for the foundation level exam.

You may also need to go through Phase E and F more carefully as they have been reworked.

Comparison of ADM Objectives – TOGAF 9 vs. TOGAF 9.1

Phase Objective as per TOGAF 9 Objective as per TOGAF 9.1
Preliminary
  • To review the organizational context for conducting enterprise architecture
  • To identify the sponsor stakeholder(s) and other major stakeholders impacted by the business directive to create an enterprise architecture and determine their requirements and priorities from the enterprise, their relationships with the enterprise, and required working behaviors with each other
  • To ensure that everyone who will be involved in, or benefit from, this approach is committed to the success of the architectural process
  • To enable the architecture sponsor to create requirements for work across the affected business areas
  • To identify and scope the elements of the enterprise organizations affected by the business directive and define the constraints and assumptions (particularly in a federated architecture environment)
  • To define the ‘‘architecture footprint’’ for the organization — the people responsible for performing architecture work, where they are located, and their responsibilities
  • To define the framework and detailed methodologies that are going to be used to develop enterprise architectures in the organization concerned (typically, an adaptation of the generic ADM)
  • To confirm a governance and support framework that will provide business process and resources for architecture governance through the ADM cycle; these will confirm the fitness-for-purpose of the Target Architecture and measure its ongoing effectiveness (normally includes a pilot project)
  • To select and implement supporting tools and other infrastructure to support the architecture activity
  • To define the architecture principles that will form part of the constraints on any architecture work
  1. Determine the Architecture Capability desired by the organization:
    • Review the organizational context for conducting enterprise architecture
    • Identify and scope the elements of the enterprise organizations affected by the Architecture Capability
    • Identify the established frameworks, methods, and processes that intersect with the Architecture Capability
    • Establish Capability Maturity target
  2. Establish the Architecture Capability:
    • Define and establish the Organizational Model for Enterprise Architecture
    • Define and establish the detailed process and resources for architecture governance
    • Select and implement tools that support the Architecture Capability
    • Define the Architecture Principles
Phase A
  • To ensure that this evolution of the architecture development cycle has proper recognition and endorsement from the corporate management of the enterprise, and the support and commitment of the necessary line management
  • To define and organize an architecture development cycle within the overall context of the architecture framework, as established in the Preliminary phase
  • To validate the business principles, business goals, and strategic business drivers of the organization and the enterprise architecture Key Performance Indicators (KPIs)
  • To define the scope of, and to identify and prioritize the components of, the Baseline Architecture effort
  • To define the relevant stakeholders, and their concerns and objectives
  • To define the key business requirements to be addressed in this architecture effort, and the constraints that must be dealt with
  • To articulate an Architecture Vision and formalize the value proposition that demonstrates a response to those requirements and constraints
  • To create a comprehensive plan that addresses scheduling, resourcing, financing, communication, risks, constraints, assumptions, and dependencies, in line with the project management frameworks adopted by the enterprise (such as PRINCE2 or PMBOK)
  • To secure formal approval to proceed
  • To understand the impact on, and of, other enterprise architecture development cycles ongoing in parallel
  1. Develop a high-level aspirational vision of the capabilities and business value to be delivered as a result of the proposed enterprise architecture
  2. Obtain approval for a Statement of Architecture Work that defines a program of works to develop and deploy the architecture outlined in the Architecture Vision

 

Phase B
  • To describe the Baseline Business Architecture
  • To develop a Target Business Architecture, describing the product and/or service strategy, and the organizational, functional, process, information, and geographic aspects of the business environment, based on the business principles, business goals, and strategic drivers
  • To analyze the gaps between the Baseline and Target Business Architectures
  • To select and develop the relevant architecture viewpoints that will enable the architect to demonstrate how the stakeholder concerns are addressed in the Business Architecture
  • To select the relevant tools and techniques to be used in association with the selected viewpoints
  1. Develop the Target Business Architecture that describes how the enterprise needs to operate to achieve the business goals, and respond to the strategic drivers set out in the Architecture Vision, in a way that addresses the Request for Architecture Work and stakeholder concerns
  2. Identify candidate Architecture Roadmap components based upon gaps between the Baseline and Target Business Architectures

 

Phase C The objective of Phase C is to develop Target Architectures covering either or both (depending on project scope) of the data and application systems domains.Information Systems Architecture focuses on identifying and defining the applications and data considerations that support an enterprise’s Business Architecture; for example, by defining views that relate to information, knowledge, application services, etc.
  1. Develop the Target Information Systems (Data and Application) Architecture, describing how the enterprise’s Information Systems Architecture will enable the Business Architecture and the Architecture Vision, in a way that addresses the Request for Architecture Work and stakeholder concerns
  2. Identify candidate Architecture Roadmap components based upon gaps between the Baseline and Target Information Systems (Data and Application) Architectures

 

Phase D The Technology Architecture phase seeks to map application components defined in the Application Architecture phase into a set of technology components, which represent software and hardware components, available from the market or configured within the organization into technology platforms.As Technology Architecture defines the physical realization of an architectural solution, it has strong links to implementation and migration planning.Technology Architecture will define baseline (i.e., current) and target views of the technology portfolio, detailing the roadmap towards the Target Architecture, and to identify key work packages in the roadmap. Technology Architecture completes the set of architectural information and therefore supports cost assessment for particular migration scenarios. 
  1. Develop the Target Technology Architecture that enables the logical and physical application and data components and the Architecture Vision, addressing the Request for Architecture Work and stakeholder concerns
  2. Identify candidate Architecture Roadmap components based upon gaps between the Baseline and Target Technology Architectures

 

Phase E
  • To review the target business objectives and capabilities, consolidate the gaps from Phases B to D, and then organize groups of building blocks to address these capabilities
  • To review and confirm the enterprise’s current parameters for and ability to absorb change
  • To derive a series of Transition Architectures that deliver continuous business value (e.g., capability increments) through the exploitation of opportunities to realize the building blocks
  • To generate and gain consensus on an outline Implementation and Migration Strategy
  1. Generate the initial complete version of the Architecture Roadmap, based upon the gap analysis and candidate Architecture Roadmap components from Phases B, C, and D
  2. Deter mine whether an incremental approach is required, and if so identify Transition Architectures that will deliver continuous business value

 

Phase F
  • To ensure that the Implementation and Migration Plan is coordinated with the various management frameworks in use within the enterprise
  • To prioritize all work packages, projects, and building blocks by assigning business value to each and conducting a cost/business analysis
  • To finalize the Architecture Vision and Architecture Definition Documents, in line with the agreed implementation approach
  • To confirm the Transition Architectures defined in Phase E with relevant stakeholders
  • To create, evolve, and monitor the detailed Implementation and Migration Plan providing necessary resources to enable the realization of the Transition Architectures, as defined in Phase E
  1. Finalize the Architecture Roadmap and the supporting Implementation and Migration Plan
  2. Ensure that the Implementation and Migration Plan is coordinated with the enterprise’s approach to managing and implementing change in the enterprise’s overall change portfolio
  3. Ensure that the business value and cost of work packages and Transition Architectures is understood by key stakeholders

 

Phase G
  • To formulate recommendations for each implementation project
  • To govern and manage an Architecture Contract covering the overall implementation and deployment process
  • To perform appropriate governance functions while the solution is being implemented and deployed
  • To ensure conformance with the defined architecture by implementation projects and other projects
  • To ensure that the program of solutions is deployed successfully, as a planned program of work
  • To ensure conformance of the deployed solution with the Target Architecture
  • To mobilize supporting operations that will underpin the future working lifetime of the deployed solution
  1. Ensure conformance with the Target Architecture by implementation projects
  2. Perform appropriate Architecture Governance functions for the solution and any implementation-driven architecture Change Requests

 

Phase H
  • To ensure that baseline architectures continue to be fit-for-purpose
  • To assess the performance of the architecture and make recommendations for change
  • To assess changes to the framework and principles set up in previous phases
  • To establish an architecture change management process for the new enterprise architecture baseline that is achieved with completion of Phase G
  • To maximize the business value from the architecture and ongoing operations
  • To operate the Governance Framework
  1. Ensure that the architecture lifecycle is maintained
  2. Ensure that the Architecture Governance Framework is executed
  3. Ensure that the enterprise Architecture Capability meets current requirements

 

Here are the links to the material from The Open Group

Advertisements

Architecture Governance – In TOGAF what does it mean

If you are clear about what governance means then you can skip the next section. However, if you have heard the term – Corporate Governance, SOA Governance, IT Governance – but you are not exactly sure about what it really means, then here is an explanation.

Suppose you are interested that an entity works in a way you want it to work. If you are managing the entity then you have the necessity authority to ensure it. However, you don’t manage the entity directly then what do you do? To do anything you need to have some authority or influence over the entity. You can discuss with the management team of the entity and come to an agreement on what needs to be done. Then you also come to an agreement on how to ensure that what you have agreed is followed.

In other words, you lay down a governance framework. Let us look at an example.

Government wants the corporate to follow certain guidelines – some dos and don’ts. But, government do not and cannot manage each and every corporate directly. So, they have in place Sarbanes–Oxley Act or SOX which is also known as ‘Public Company Accounting Reform and Investor Protection Act’ or ‘Corporate and Auditing Accountability and Responsibility Act’. This is corporate governance. Similarly, you also have Basel II for banks, which try to ensure that banks don’t take too much risk with money invested with them.

To put governance in place you need to have:

  1. Discipline = Commitment to adhere to procedures, processes, and authority structures
  2. Transparency = Actions and decision support available for inspection
  3. Independence = Mechanisms to minimize or avoid potential conflicts of interest
  4. Accountability = Groups who take actions or make decisions are authorized and accountable
  5. Responsibility = Contracted party to act responsibly
  6. Fairness = No unfair advantage to any one particular party


How does TOGAF Define Architecture Governance?

If you had gone through my earlier posts (What is TOGAF?, Defining Requirement and Planning a project) you would realize that TOGAF is not about solution design or application development. It provides a set of guidelines of what the final solution should adhere to. That is what the Architecture Governance all about. It talks about:

  • Control: Implementing a system of controls over the creation and monitoring of all architectural components and activities, to ensure the effective introduction, implementation, and evolution of architectures within the organization
  • Compliance: Implementing a system to ensure compliance with internal and external standards and regulatory obligations
  • Management: Establishing processes that support effective management of the above processes within agreed parameters
  • Accountability: Developing practices that ensure accountability to a clearly identified stakeholder community, both inside and outside the organization

How do you enforce the governance?

TOGAF will normally be initiated by CIO, but for it to succeed broad support from the rest of the organization is needed.

So the aim is to get the authority from top management in the Preliminary Phase. To ensure that the authority is recognized by the rest of the organization an “Architecture Board” in constituted. TOGAF recommends that the board should 4 to 5 permanent members, the upper limit being 10. The important point is to include all the important people in the organization.

TOGAF also recommends that there is an “Architecture Contract” for all the work that needs to be executed. Architecture Contracts are joint agreements between development partners and sponsors on the deliverables, quality, and fitness-for-purpose.

What does the Architecture Board do?

It acts as the approving and controlling authority for the following:

  • Consistency between sub-architectures
  • Identifying re-usable components
  • Flexibility of enterprise architecture; to meet business needs and utilize new technologies
  • Enforcement of Architecture Compliance
  • Improving the maturity level of architecture discipline within the organization
  • Ensuring that the discipline of architecture-based development is adopted
  • Providing the basis for all decision-making with regard to changes to the architectures
  • Supporting a visible escalation capability for out-of-bounds decisions

The Meaning of Architecture Compliance

Finally, I find the following representation of “what different types of compliance are” to quiet nice:

Irrelevant

No relation between Standard & Implementation

Consistent

There is overlap between Standard & Implementation properly

Compliant

Implementation is a subset of Standard and is done properly

Conformant

Standard only covers part of implementation but that part is done properly

Fully Compliant

Implementation is exactly as per Standard

Non-Conformant

The square indicates that overlap has deviation

Defining Requirement – the TOGAF way

If you are new to TOGAF, you may be wondering how this process is different from what you do in a typical “Requirement Analysis” phase of software development. Once I tell you that the many of the techniques recommended in TOGAF are what you are already using, like UML modeling techniques like Activity Models, Use-Case Models and Class Models, you may think why bother with TOGAF?

What you really do differently in TOGAF is that you take a much wider perspective of the requirement. There are three important things that you need to do:

  1. Explicitly document the current state, the expected future state and identify the gap
  2. Assess impact of the change on other projects and other organizational initiatives
  3. State the change from the perspective (viewpoint) of different stakeholders and get their buy in

While doing this, you need to keep in mind the following:

  1. Are you adhering to all the relevant organizational standards & guidelines?
  2. Have you made an explicit attempt of reuse?

Steps for Defining the Requirement

We had discussed the following lists (without the 3 steps in “Define Requirement”) in my earlier posts –
What is TOGAF? & Planning a project.

  1. Tailor TOGAF to suit your need
  2. Define scope of work and prepare plan for rollout
    1. Define the scope and get approval from the sponsor
    2. Define requirement in terms of how the business process will change, what data, application and technical infrastructure is required for accomplishing the work
      1. What should the new business process be?
      2. What application & data do we need to support the changed process?
      3. What technology infrastructure do we require to implement the change?
    3. Select a suitable solution and make the implementation plan
  3. Oversee development and implementation
  4. Manage post-implementation change

Here are some of the terminologies used in TOGAF and their meaning as used in TOGAF.

View & Viewpoint

  • View = What you see or what a stakeholder sees
  • Viewpoint = Model or description of the information contained in a view

Baseline, Target & Gap

  • Baseline = Where you are now
  • Target = Where you want to be
  • Gap = What needs to change

Deliverable & Artifact

  • Deliverable = Contractually specified document – formally reviewed, agreed, and signed off by the stakeholders
  • Artifact = Architecture from a specific viewpoint – can be a Catalog, a Matrix or a Diagram

What artifacts do you may produce? 

Catalog Matrix Diagram
Business Architecture
  • Organization/Actor catalog
  • Driver/Goal/Objective catalog
  • Role catalog
  • Business Service/Function catalog
  • Location catalog
  • Process/Event/Control/Product catalog
  • Contract/Measure catalog
  • Business Interaction matrix
  • Actor/Role matrix
  • Business Footprint diagram
  • Business Service/Information diagram
  • Functional Decomposition diagram
  • Product Lifecycle diagram
  • Goal/Objective/Service diagram
  • Use-Case diagram
  • Organization Decomposition diagram
  • Process Flow diagram
  • Event diagram
Data Architecture
  • Data Entity/Data Component catalog
  • Data Entity/Business Function matrix
  • System/Data matrix
  • Class diagram
  • Data Dissemination diagram
  • Data Lifecycle diagram
  • Data Security diagram
  • Data Migration diagram
  • Class Hierarchy diagram
Application Architecture
  • Application Portfolio catalog
  • Interface catalog
  • System/Organization matrix
  • Role/System matrix
  • Application Interaction matrix
  • System/Function matrix
  • Application Communication diagram
  • Application and User Location diagram
  • System Use-Case diagram
  • Enterprise Manageability diagram
  • Process/System Realization diagram
  • Software Engineering diagram
  • Application Migration diagram
  • Software Distribution diagram
Technology Architecture
  • Technology Standards catalog
  • Technology Portfolio catalog
  • System/Technology matrix
  • Environments and Locations diagram
  • Platform Decomposition diagram
  • Processing diagram
  • Networked Computing/Hardware diagram
  • Communications Engineering diagram

What is TOGAF – without jargon

Yes, TOGAF is an EA (Enterprise Architecture) framework – but what is that suppose to mean?

Imagine that you have to oversee the IT integration of 2 companies which has merged and they have different ERP, CRM, billing system and the customer facing process are different. The merged entity needs to rationalize the product offering and needs to project a uniform and integrated face to the customer. Obviously, this is going to be a big challenge – technological, people, process and change-management. How would you go about this complex transition? You can do a ground up thinking and make a plan or you can take the help on an EA framework like TOGAF and tailor it to your specific needs.

However, the important point that needs to be kept in mind is that TOGAF is NOT a methodology for managing software development. It will help you to identify what software to build – what need the software should satisfy – if you are planning to outsource the work, what should go into an RFP – even how to monitor the development and implementation.

ADM = Architecture Development Methodology

If you look around a little you will realize that the core element of TOGAF is ADM. Important point to remember is the “A” in ADM is ARCHITECTURE and not application.

[BTW: TOGAF = The Open Group Architecture Framework and the current version is 9]

You will also come across this diagram either in the Wikipedia page on TOGAF or on the Introduction to ADM page on the TOGAF site. I won’t blame you if you find the content in these pages to be too confusing. However, the annotated diagram on the left should be able to give you an overview.

Though the diagram has 10 circles, ADM is essentially a 4 step process.

  1. Tailor TOGAF to suit your need: this is a onetime activity to be done before you start adopting TOGAF for your organization
  2. Define scope of work and prepare plan for rollout: this activity is made of six distinct steps – we will get into the details in a later post
  3. Oversee development and implementation: how the actual development and implementation is done is not within the scope of TOGAF
  4. Manage post-implementation change: Any major change will trigger off another cycle of ADM

You may have multiple ADM cycles simultaneously running for different projects running within your organization. These projects need not be in sync.

Requirement Management = Central knowledge repository

The circle at the centre represents a knowledge repository. TOGAF was specific recommendations on how to organize the repository. We will see more about this in a later post.

I will also not get into the detail of what Enterprise Continuum is. If you had tried skimming through the TOGAF material, you surely would have encountered this term. It is a way of classifying item in the knowledge repository. On one dimension is to separate architecture and solution. On this other dimension is about moving from more generic to more specific (foundation, common system, industry, organization specific). Again, this requires more detailed discussion and we will do it in a later post.

Architecture as defined in TOGAF

The architecture is used in TOGAF in ways you would not normally use. You need some time to get used to it. The TOGAF study guide explicitly states that…

…”architecture” has two meanings depending upon the context:

  1. A formal description of a system, or a detailed plan of the system at a component level to guide its implementation
  2. The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time

At this stage I will not analyze this definition but draw your attention to 2 phrases – “detailed plan … to guide its implementation” and “evolution over time”. Do you find this different or confusing? You better get used to it.

If you come across the term Architecture Work, it means the work that needs to be done to move from baseline (current) architecture to target (desired) architecture. In simple term it means scope of work.

In the next post I will elaborate the 6 steps for defining scope of work and preparation of plan for rollout.

Posted in TOGAF. Tags: , , . 12 Comments »

Is Enterprise Architecture Dying

Zachman wrote “This is what is killing Enterprise Architecture…” and Sunil starter a discussion on it in Linked iCMG group. The result – 604 comments and counting. It is a lively discussion and could not resist the temptation to summarize it. Though it is a tough ask to summarize 35 pages of heated discussions into one blog post, I am going to be brave enough to try it.

The starting point of the discussion

There is a dilution in the meaning of Enterprise Architecture. The term is loosely used for many IT related activities. Because of this dilution EA is losing its importance and dying.

There was NO disagreement about the proposition that “Enterprise Architecture IS dying”. There was no agreement on any other points. I have picked up points that I thought were most interesting.

  1. EA vs. E (IS) A vs. E (IT) A
  2. Has the term EA been hijacked – if so then should you care?
  3. Did ZF framework originate as Information System framework?
  4. Is TOGAF an EA framework?
  5. Can the market forces redefine the meaning of EA?
  6. Can somebody external to the enterprise play the role of EA?
  7. How to measure success of EA initiative – Are there enough success stories of EA?

Here are the details – what people have said on these points:

1. EA vs. E (IS) A vs. E (IT) A

Kirk Rheinlander: Enterprise architecture has little to do specifically with information technology

“… An Enterprise may elect to use information technology as an implementation option but the Enterprise can also be implemented with pencils, paper and file cabinets…”

“…the purpose of EA is to provide a governance mechanism for executive insight supporting decision making…”

“…What I DISAGREE with is the notion of enterprise architecture as the same thing as this IT architecture role…”

Deepak Berwal: EA definition

“…is the art and science of enterprise design…”

“…the hope for enterprise architecture is that applying systematic rational methods to the design of an enterprise will produce one that more effectively and efficiently pursues its purposes…”

John Gardner, CMC: Goal of EA

“…as per Zachman – the goal of enterprise architecture is to engineer the enterprise so it is as lean as possible and … can dynamically handle the demands upon it…”

Ron Segal: Enterprise Architecture is Enterprise Information System Architecture

“…we get in trouble with ‘Enterprise Architecture’, because this is commonly taken to mean Enterprise IT Architecture…
If he’d referred to Enterprise Architecture, as Enterprise Information Systems Architecture, it would have been a more accurate description of the design focus…”

“…in my book ‘information systems’ isn’t the same as information technology…”

Nya Alison Murray: Reverse technical snobbery 

“…the concept that there is no need for any technical knowledge of IT to provide enterprise architecture… I think it is disrespect for technical and analytical knowledge of any kind… Do we really have to pretend we are ignorant of all IT disciplines to be respected in business circles…”

 

2. Has the term EA been hijacked – if so then should you care?

Kirk Rheinlander: Lack of understanding of what EA is

“…if you look at 100 EA jobs on any job board, 99 of them will be IT architects of one flavor or another… this makes it extremely tough for those that have been doing EA for 25+ years to find work, when their job title has been co-opted by techies…”

“…I wonder what a true enterprise architect does to find work…”

“…almost universal lack of understanding of 25 years of EA history (except for a select few EA evangelists that get it) and benefits, are what is killing EA as a profession. EA today, as typically practiced is a pale facsimile of what EA was designed and practiced as….”

“…Most of the people that I know they do EA work that spans the enterprise, and not IT focused, have struggled to find work in recent years…”

Isaka Traore: Enterprise Architecture misperceptions

“…confusion tends to be created by those who use or misuse concepts and frameworks… Zachman … TOGAF and various others give us prescriptive ways of addressing architectural concerns…”

“…the practice largely originated from work and musings by IT minded folks…”

Roy Bynum: Role of IT vendor in this confusion

“… it is the so called IT vendors that have messed up the concept of enterprise level architecture…”

David V. Corbin: Hijacking of the job title

“…do I really care if (the term) EA is hijacked? A resounding YES!…”

“…Titles in (most) other professions [and the debate is still open on if EA is/should be a true “profession”] are very well defined. One cannot simply claim to be an MD, Lawyer, etc…”

David Winders: Hijacking of the job title

“…it causes the meaning of EA to be diluted and misrepresented when people are trying to work towards understanding what it is and to communicating it correctly…”

Jayesh Nazre: Hijacking of the job title

“…is it does not bother me if the Technical Architect title is used by certain individuals who really are product specialist and not Technical Architects…”

 

3. Did ZF framework originate as Information System framework?

Kirk Rheinlander: Origin of the term EA

“…Zachman coined the term Enterprise Architecture in a published paper in 1987, although I believe Banning was already using that term inside GE prior to that point…”

Graham Berrisford: Origin of the term EA

“…For many years, John Zachman said his framework was for Information Systems Architecture. The framework has changed little since then – even though John Zachman later coined the term Enterprise Architecture – probably after the Clinger Cohen Act (1996) – which refers only to IT Architecture – does not mention Enterprise Architecture at all…”

“…The paper you quote is on the internet – A framework for information systems architecture, IBM SYSTEMS JOURNAL, VOL 26. NO 3. 1987. The abstract says “This paper defines information systems architecture by creating a descriptive framework. Please read the paper and tell me where it mentions enterprise architecture…” 

“…There is a lot of wishful thinking in this discussion. Whether you like it or not – out there in the market place – EA remains rooted in thinking about IS and IT – because that is where it (mostly) started. Let’s get our facts straight. Today’s best-known EA frameworks did not start out as EA frameworks. They have their roots in thinking about Information Systems – rather than Information Technologies…”

Alan Dyer: Origin of the term EA

“…Zachman used the term EA in relation to the ZF around 1996 in a series of three papers…”

Nic Harvard: BPR and EA

“…BPR was not a world away from what we now term EA, and a lot of people in these forums have seen great concepts crash and burn by being hijacked in various ways…”

“…Speak to any 55-year old+ CIO / CFO / CEO about BPR however, and he will have security escort you out the building in 5 minutes flat…”

 

4. Is TOGAF an EA framework?

Ron Segal: NO

“…TOGAF’s pedigree is technical architecture, it has shifted towards a more modern, business driven approach, but the whole thrust remains IT architecture…”

Kirk Rheinlander: NO

“…TOGAF is IT architecture, not Enterprise Architecture – they got it wrong, and they continue to perpetuate the myth…”

Bran Kop, BSEE MSCS: YES

“…TOGAF is a comprehensive framework for enterprise architecture, i.e. it is NOT only Information System Architecture… The artifacts produced so far in TOGAF belong to first four rows of Zachman EA classification framework…”

Van Luu: YES

“…all the questions raised here have associated answers in TOGAF…”

 

5. Can the market forces redefine the meaning of EA?

Kirk Rheinlander: IT folks messed it up

“…we already HAD the EA demand and market well defined, until the IT and software people decided that they could abscond with the title, probably out of ignorance…”

Jayesh Nazre: Market will drive the demand

“…The market will drive the demand and the need. That’s why you see 99% of the jobs with IT as a focus…”

Donald Tiffany Jr.: Who defines the term?

“…the truth is that Oracle (Sun, BEA etc), Microsoft, and IBM along with government bureaucracies and other large contractors will define EA, are defining it…”

“…the market is not demanding the chief architect of architects, the CEO’s right hand man above all his VPs, it is a fantasy…”

Sanjib Talukdar: Understanding need for EA

“…As long as the business side of an enterprise does not realize that a UNIFIED long term view [including business strategy and IT strategy] of the Enterprise should be defined and then enforced through flexible governance, Enterprise Architecture will always be a mirage…”

Mark Brennan: Need to evolve

“…A discipline always needs to steer a good course between evolved theory, where ideal scenarios play out to a best case ROI, and the real world constraints of time, budget, competing imperatives…”

“…The end product – though forever evolving and iterative – must be perceived as effective, fluid, intuitive and “made for humans”…”

 

6. Can somebody external to the enterprise play the role of EA?

Roy Bynum: Skill vs. Talent

“…Whether Enterprise Architect refers to a Business process architect, or an Information process is somewhat irrelevant if your target customer base does not understand that what he is looking for is talent and not necessarily someone who knows a methodology…”

Donald Tiffany Jr.: Skill vs. Talent

“…Individuals that fill these roles well don’t really fit into the mold of one discipline… most only fill these roles at a single organization for a temporary period…”

Donald Tiffany Jr.: Enterprise Architects within the business

“…instead of trying to have the Enterprise Architect supplant existing enterprise roles that already hold the types of responsibilities that many here assign to Enterprise Architect in its broadest definition, we should instead try to incorporate these high level approaches and principles into those other disciplines from which those other roles spring…”

“…The CEOs and Board of Directors out there, I don’t think want to or feel the need to be replaced by EAs and their formal systematic approaches. That is one of the reasons why I think EA has been redefined over the years…”

 

7. How to measure success of EA initiative – Are there enough success stories of EA?

Kirk Rheinlander: Yes, it has worked in the past

“…There is no role in a corporation that has nearly the impact of the EA – not even the President. An effective EA influences everything, changes everything, and, in the end, makes a major difference. I do love it, and miss the role dearly, but in the end, the overwhelming IT bastardization of the term, won out. Eating became more important than my ideals, however noble…”

Donald Tiffany Jr.: If EA was so successful then why no demand?

“…If EAs were so successful at improving enterprises in their roles at the highest levels with the broadest scope in terms of their responsibility, then why are they not hired for this purpose as a first matter of course by every enterprise in existence…”

Ron Segal: Lack of measure

“…what is the definition of a – successfully implemented enterprise architecture – How do you recognize one…”

David V. Corbin: Measurability

“…lack of measurability and metrics is major issue…”

“…it is very difficult to establish something that applies well to an automated manufacturing facility for retail products (hundreds of products/customers, very little innovation) and also applies to something extremely specialized such as development of space borne systems (single product/customer, very little “off-the-shelf”)…”

Mark Brennan: 2.0 Enterprise

“…I provide my customers verifiable goals, metrics and milestones in the evolution toward a 2.0 enterprise, capable of covering so much more ground with the same number of people, than a traditional legacy enterprise. 
If my stuff only runs on diagrams, it’s a FAIL. My stuff runs in the real world, and it is judged daily by some very hands-on business leaders…”

Steve Towers : Sustainable results

“…If we all focus on sustainable results we will justify the investment and help move EA to a new level…”