martes, 30 de diciembre de 2014

Best Practices for Driving Business Change through Technology (I)

What is Enterprise Architecture?

I define an enterprise's architecture as the structure of its data (both computerized and not), the structure of its processes (both computerized and not), and the interactions between the two, informed by the enterprise's goals and objectives.

I define the EA's job as creating (for start-ups only), documenting, rationalizing, optimizing, educating about, evangelizing about, and consulting about that architecture. The EA should also have authority and responsibility for architectural oversight of all creation of, and changes to, the enterprise's data and processes -- the "bones" of its architecture -- to ensure that those data and processes stay consistent with the enterprise's architecture, or that the architecture is adapted to accommodate them. But the EA should not be responsible for those changes (except to the enterprise's architecture); that's for solution architects (both computerized and not). The EA should, however, be a valued consultant in the process, due to his/her holistic view of the enterprise from an architectural point of view. Note that none of the above is specific to IT.

I have identified three major EA killers -- conflating EA with IT, with "transformation", and with the entire enterprise including its strategy.

Stephen F. Heffner

President at XTRAN, LLC

jueves, 18 de diciembre de 2014

How COBIT® 5 & BiSL® address Governance and Management of Information

Agile Enterprise Architecture, TOGAF and Kanban boards

Agile Enterprise Architecture: What is it?


Taming Big Balls of Mud with Diligence, Agile Practices, and Hard Work

domingo, 14 de diciembre de 2014

DevOps Video

DevOps: The Big Picture

DevOps Course

Seven Tips for the Successful Improvement of GEIT

4 Steps to Integrate IT and Corporate Governance

Devops Course

Agile Courses

sábado, 13 de diciembre de 2014

Gap Analysis Template: The 3 Key Elements of Effective Gap Analysis

The Business Architect as Strategist

Achieve GRC in three easy steps!

EA is Transformation

Where Does Business Analysis Fit into TOGAF?

EA Software

domingo, 30 de noviembre de 2014

Estudiando TOGAF 9 con Rachel Harrison

CyberSecurity Program Reference Model

CyberSecurity Program Reference Model

Kanban ppt


Social, Mobile, Analytics & Cloud (SMAC): A Unique Business Framework

Business Model Canvas Links

sábado, 29 de noviembre de 2014

EA Quick Start Guide (Part 1): How to Set Up an EA Practice

Lean & Enterprise Architecture: Opposites Attrac


Lean & Enterprise Architecture: Enterprise Architecture for Lean Business Processes


Enterprise Architecture and Business Transformation


The Value of Architecture and TOGAF as a guiding light

Is TOGAF incomplete, complex and sucks? Second installment

Building an Enterprise Architecture value proposition using TOGAF® 9.1. and ArchiMate 2.0 -

EA Frameworks

Zachman -
SABSA -®-sabsa®-secure-architecture-methodology
COBIT - Part 1: Part 2:
TMForum Framworx -®-and-frameworx/
C4ISR Architecture Framework -
Enterprise Architecture Planning (EAP) -
Federal Enterprise Architecture: Practical Guide -
ISO/IEC TR 14252 (IEEE Std 1003.0) -
NCR Enterprise Architecture Framework -
SPIRIT Platform Blueprint Issue 3.0 -
TEAF - - See more at:


How to build a Roadmap

A SOA Journey Using the TOGAF ADM

TOGAF Views and Viewpoints

TOGAF Quizlet

TOGAF Presentations

BTEP Templates


business case and so on

Business Transformation Enablement Program

jueves, 27 de noviembre de 2014




There are many different maturity models that can be applied to evaluate your enterprise architecture practice. Most of them make some attempt to measure the quality of your artifacts, the thoroughness of your enterprise modelling, and the rigour of your architectural processes. For educational purposes, we can simplify the maturity models a little bit. At Web Age, we've come to divide the journey into three stages that cover the beginnings of a workable architecture practice. These stages are essentially enabling stages: They let you get going with architecture, but then you need to practice architecture in your particular organization to further develop your architectural maturity. These are the phases where generalized training is useful. Put another way, you first need to have generalized capabilities (which can be taught with generalized training), and then you can develop capabilities that are specific to your organization (which would typically need to be propagated within the organization through customised training).

The generic stages are:

  • Just getting started.
  • Equipping Domain Architects
  • Establishing a Community of Practice

Let's have a look at each of these stages in turn...

Just Getting Started

To understand this stage, it's useful to remember that the drive to create an Enterprise Architecture practice usually arises out of dissatisfaction. When we ask people "Why are you interested in EA?", the answers usually boil down to "we have a lot of systems that don't work well together (or aren't maintainable, or are obsolete, or don't meet the users' needs, etc), and we wish we'd done things differently so we didn't end up in this situation. We have a feeling that Enterprise Architecture would change things".

At this stage, we need to help people understand what Enterprise Architecture is, and how it can help move us from the status quo to a more favourable "to-be" state. Usually the "to-be" state can be described as "we have a functioning business supported by appropriate software systems". We also need to define and communicate the relationships between Enterprise Architecture (EA), Solution Architecture (SA), and Technical Architecture (TA).

Generic courses at this stage will have titles like "Architectural Thinking", " Architecture Foundation", "Introduction to Enterprise Architecture", and "Introduction to Solution and Technical Architecture"

Equipping Domain Architects

Once we have a handle on just what EA means, we can start equipping architects to execute an EA program. In the same way that physical architecture (i.e. of buildings) is decomposed into Mechanical and Electrical Engineering specialties, Enterprise Architecture is often decomposed in more specialized areas, or "Domains". The most popular classification system divides EA into "Business Architecture", "Data Architecture", "Application Architecture", and "Technology Architecture".

Business Architecture and Data Architecture are self-contained domains, and training will be focused on these domains in a stand-alone way. Course tiles here would be things like "Introduction to Business Architecture", "Logical Data Modeling", and perhaps "Introduction to Big Data" or "Introduction to Data Science".

Application Architecture and Technology architecture are naturally slanted more towards particular solution architecture styles and technologies. So the training would be chosen from various areas including "Service Oriented Architecture", "Master Data Management", "Business Process Management", and "Message Oriented Middleware", as well as technology-specific areas like "Java Enterprise Edition", or "Introduction to AngularJS".

Also, if you've chosen a particular EA framework, like The Open Group Architecture Framework (TOGAF), you will want to provide the appropriate training to practitioners.

Establishing a Community of Practice

With core skills established, the EA group can now begin to practice EA and promote EA outside the EA group. In other, words, EA needs to engage the business.

Recalling that EA grows out of dissatisfaction with the current state of business and technology convergence, one might imagine that the business would embrace EA whole-heartedly. One would be wrong. Inevitably, the status quo is a result of ingrained practices and attitudes. While it's usually true that one or more executives or business managers "gets" EA and wants to embrace it, the early vanguard needs to sell EA to the rest of the organization.

We recommend a three-pronged approach:

First, training courses like "Architecture for Executives" and "Architecture for Managers" can be used to educate people outside the EA group. In addtion to the plain training value, an outside instructor can bring "expert power" that lends credibility to the Enterprise Architecture practice.

Second, architects should engage the business one-on-one and in groups. Courses like "Architecture Soft Skills" can equip architects with the selling, negotiation and persuasion skills that are needed to promote an integrated approach to EA.

Third, EA needs to be successful, and to encourage, demonstrate and document that success through an adequate governance program. A course like "Architecture Governance" can illustrate how to design an appropriate governance system and promote EA throughout the organization.


Once you've covered these generic education phases, you'll be in a position where your EA practitioners are developing governance, instituting processes and procedures, and actively engaging the business organization, as well as the broader Information Technology (IT) organization. You can think of the business, development community, and solution architecture community as "clients" of Enterprise Architecture.

Now your training needs will be two-fold: You need to develop organization-specific training to promote specific EA programs, and you need to continue promoting and propagating general knowledge and acceptance of EA.

Depending on the size and capabilities of your EA group, you might choose to develop the organization-specific training in-house, or engage a service provider like Web Age Solutions to develop and customize your in-house training program. In addition, short overview courses like "EA for Managers" or "Introduction to EA" can be offered to EA's clients.

One interesting aspect of this stage is that the size of audience increases, while the level of direct interest decreases. As such, the educational approach can be less contact-intensive. In particular, this is a perfect opportunity to use tools like self-paced e-learning. For bespoke training, you can make a single, manageable investment in training materials and then use those materials throughout the organization. For more generic topics, you can invest in tools like Web Age's "Architecture Fundamentals" On-Demand video series, which EA's clients can view at their own pace, and as frequently as needed.


A successful Enterprise Architecture program engages stakeholders and architects in a process that moves the organization from an "as-is" state (that is considered unacceptable or unsustainable for a variety of reasons) to an improved "to-be" state (that usually involves "a funtioning business supported by appropriate software systems").

Enterprise Architecture needs to be supported with training programs that are geared to the initial stages of maturity - "Just getting started", "Equipping Domain Architects", and "Building a Community of Practice". These initial training programs are often done in small groups, led by an instructor, who brings an outside perspective and lends credibility to the EA program.

Once the initial stages are accomplished, the focus shifts to promoting and practicing EA. In these later stages, a combination of in-house development and bespoke training materials may be needed, along with more scalable (if lower-touch) programs like e-learning and self-paced video training.


domingo, 23 de noviembre de 2014

Is TOGAF Certification Worth It?

Capabilities vs Processes



The Architecture Manager – the Forgotten Enterprise Architecture Role

Unicom 2014 - Staying relevant in the digital ecomony

Enterprise Architecture and Innovation: A Cultural Change

Change Management for Architects

CGEIT 2014/2015 WBT Exam Preparation Slides and Exam Review questions


Governance over IT Service Management Processes using COBIT 5.0

50 Competitive Intelligence Analysis Techniques

COBIT Courses


domingo, 16 de noviembre de 2014

Modelio Software

TOGAF Resources and Templates

Alignment & Unity Reference Content

Alignment & Unity Reference Content - Alignment & Unity Model

Positioning Enterprise Canvas in enterprise-architecture work

From Dread to Delight – Taking a Human Centred Approach to TOGAF®

Certification in Risk Management Assurance (CRMA)

IT Control Objectives for Sarbanes-Oxley Using COBIT 5, 3rd Edition

Clasificación de servicios

lunes, 10 de noviembre de 2014

The enterprise architecture code of ethics dilemma

TOGAF Introducction

Video Series – TOGAF ADM: Preliminary Phase



The Open Group IT4IT

Arquitectura empresarial y de software version final

Effective Use of Business Architecture

Top 5 Takeaways from our 'Drive Strategic Performance' Report

Secrets to Architecting an Innovation Culture

The business within the business

Business Area WorkFit for your business capabilities

Agile Architecture Abstract

Tres estrategias de cambio en procesos


What is Enterprise Architecture?

Why Enterprise Architecture stirs debates and sometimes, adversity

Enterprise Architects as Strategists

What’s a Business Architecture?

viernes, 7 de noviembre de 2014

APQC Website

10 Tests of Strategy

To help avoid falling foul of this common pitfall, consider the 10 tests below from McKinsey.

  1. Will our strategy beat the market?
  2. Have we translated our strategy into an action plan?
  3. Is our strategy granular about where to compete?
  4. Is our strategy contaminated by bias?
  5. Does our strategy put us ahead of trends?
  6. Does our strategy rest on privileged insights?
  7. Does our strategy embrace uncertainty?
  8. Does our strategy tap a true source of advantage?
  9. Does our strategy balance commitment and flexibility?
  10. Is there conviction to act on our strategy?

martes, 4 de noviembre de 2014

Spot the difference

GRC Definition

GRC is a capability to reliably achieve objectives [GOVERNANCE] while addressing uncertainty [RISK MANAGEMENT] and acting with integrity [COMPLIANCE].[1] Successful GRC strategies deliver the ability to effectively mitigate risk, meet requirements, satisfy auditors, achieve human and financial efficiency, and meet the demands of a changing business environment. GRC solutions should achieve stronger processes that utilize accurate and reliable information. This enables a better performing, less costly, and more flexible business environment.
GRC 20/20 measures the value of GRC initiatives around the elements of efficiency, effectiveness and agility. Organizations looking to achieve GRC value will find that the results are:

  • GRC Efficiency. GRC provides efficiency and savings in human and financial capital resources by reduction in operational costs through automating processes, particularly those that take a lot of time consolidating and reconciling information in order to manage and mitigate risk and meet compliance requirements. GRC efficiency is achieved when there is a measurable reduction in human and financial capital resources needed to address GRC in the context of business operations.
  • GRC Effectiveness. GRC achieves effectiveness in risk, control, compliance, IT, audit, and other GRC processes. This is delivered through greater assurance of the design and operational effectiveness of GRC processes to mitigate risk, protect integrity of the organization, and meet regulatory requirements. GRC effectiveness is validated when business processes are operating within the controls and policies set by the organization and provide greater reliability of information to auditors and regulators.
  • GRC Agility. GRC delivers business agility when organizations are able to rapidly respond to changes in the internal business environment (e.g. employees, business relationships, operational risks, mergers, and acquisitions) as well as the external environment (e.g. external risks, industry developments, market and economic factors, and changing laws and regulations). GRC agility is also achieved when organizations can identify and react quickly to issues, failures, non-compliance, and adverse events in a timely manner so that action can be taken to contain these and keep them from growing.

GRC 20/20 Research is happy to announce the recipients of the second annual GRC Value Awards. The 2014 GRC Value Awards honors twelve leaders in GRC for real-world implementations of Governance, Risk Management and Compliance programs and processes that have returned significant and measurable value to an organization. Nominations from GRC programs within organizations were evaluated and vetted. Nominations were evaluated for depth of quantitative facts and each final selection was validated by GRC 20/20 and the specific implementation to attest to accuracy. Nominations were scored on both quantitative (hard objective facts and figures) and qualitative (soft subjective opinions and experience) measures of GRC value as they pertain to the benefits they received. Twelve are recognized across the following categories (in alphabetical order of company that received the value) .

CACS 2014 Presentations

A Conversation on Blue Ocean Leadership

Better Together: Information Architecture and Information Management

Mike Walker Blog: Information Architecture on the Strategy to Execution

Is IT Benchmarking valuable or a Waste?

Enterprise Desging

lunes, 3 de noviembre de 2014

Enterprise Architecture: A Practitioner View

GRC en Español

The Decision Management Manifesto

Distinct Approaches to Business Model Innovation

Transforming IT into an Innovation Engine

Qué es un análisis CAME y cómo usarlo en la búsqueda de trabajo

Strategy Map Software Balanced Scorecard Software KPI Software

¿Qué es un Mapa Estratégico y para qué sirve?


Qué es y cómo se hace un Plan Estratégico

Mapas estratégicos. BSC, modelos de aplicación

How does "Design Thinking" fit in Business Architecture?

Effective Agile At Scale Webinar Series

The Failed Vasa: COBIT 5 and the Balanced Scorecard (Part 1)

Managing the Risk Portfolio Using COBIT 5

Modern Workplace

The Periodic table of IoT

PeriodicTable of IoT - final2

Are You an Enterprise Architect? Really?

The Failed Vasa: COBIT 5 and the Balanced Scorecard (Part 1)

Services and Enterprise Canvas review – Summary

Organizations Must Leverage Enterprise Architecture as a Strategic Resource to Advance their Internet of Things Strategies

Webinar: Re-positioning the Value of the Architecture Practice

The ArchiMate Files – 1. Introduction and Theory

Business Architecture Patterns (BPM in Practice conference)

Using Business Architecture to enable customer experience and digital strategy

IT4IT MAnaging the Business of IT

¿Es posible Transformar la TI utilizando Lean e ITIL?

domingo, 2 de noviembre de 2014

Mapas estratégicos . . . fotograma de la Estrategia

Should an Enterprise Architecture code of conduct be introduced at all costs?

why IT alignment is a waste of time

Collaboration between BIAN & TOGAF

Is it Enterprise Architecture or Wall Art?

Enterprise Architecture and COBIT 5

The Value of Architecture and TOGAF as a guiding light

Análisis ISO 21500

Amateur Hour for Enterprise Architecture

Chief Cyber Security Officer skills and competencies

Rethinking Your Innovation System

DNS Document

jueves, 23 de octubre de 2014

Bridging enterprise-architecture and systems-thinking

What CIOs Need to Know About Business Alignment

In It to Win IT: Fantasy Football & Enterprise Architecture

Leading Change: Why Transformation Efforts Fail

The Relative Value of EA Frameworks

What’s a Business Architecture?

What’s a Business Architecture?

Agile Architecture Abstract


miércoles, 22 de octubre de 2014

COBIT 5’s Flexibility Key to Success


Figure 2

Descubre Cloud BPM: BPMteca y Proceedit organizan el 20 de noviembre un seminario sobre la automatización de procesos desde la nube


With Agile, are IT Project managers obsolete?

Enterprise Architecture – Zachman vs TOGAF

None of the methodologies and features of EA are suitable for all the enterprises all the time. EA is continuously evolving and rapidly so in the past few years. The benefits of implementing EA are

  • Improvements in business processes.
  • Improvements in IT infrastructure
  • Improvements in business and IT relationship
  • Improvements in the achievement of business objectives and goals.

On-demand webminars

BiZZdesign in Leaders Quadrant Gartner MQ for EA Tools 2014

Enhancing the Value of ITIL® and TOGAF® (Webinar 09-28-2013)

QRP Resources

IRIS community

Integrating TOGAF and the Banking Industry Architecture Network (BIAN)

QRP International

Il webinar sulla integrazione tra ITIL e TOGAF

Governance Videos

Planificación y organización en Cobit. GOBIERNO DE TI


Cómo determinar la capacidad de los procesos en COBIT 5

Cobit 5 Principles

Agile y los equipos autogestionados

ADOit OnDemand Webinar Series

Open Group launches IT4IT, vendor-neutral reference architecture for IT management

Business Capability Planning in the Enterprise Intelligence Age

IT Planning and Agile

Security Architecture Series Guide

lunes, 20 de octubre de 2014

Successful Innovation needs a common language, context and communicating

Customer Talk: Mapfre se transforma con Lean IT

What IT Gets Wrong in Assessing Talent


The Seven Rs of Knowledge Management

Who raised the change?

What is the reason for the change?

What is the return required from the change?
What are the risks involved in the chance?

What resources are required to deliver the change?

Who is responsable for the build, test and implementation of the change?

What is the relationship between this change and other changes

domingo, 19 de octubre de 2014

Presentación Webinar Gobierno y Gestión de la Información

Conocimiento del modelo de Métricas



Llegar a la causa raíz del significado de lo que hacemos en la Operación del Servicio

¿Dónde se gesta el Conocimiento? Actividad de Mejora Continua del Proceso


Intro to Design Thinking

Digital Innovation and Business Transformation

The CEO's Gap Between Strategy & Execution



IT Planning Methdology

Gobierno y GEstión de la INformación