miércoles, 31 de diciembre de 2014
martes, 30 de diciembre de 2014
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
lunes, 29 de diciembre de 2014
domingo, 28 de diciembre de 2014
sábado, 27 de diciembre de 2014
DevOps Links
jueves, 25 de diciembre de 2014
jueves, 18 de diciembre de 2014
miércoles, 17 de diciembre de 2014
martes, 16 de diciembre de 2014
domingo, 14 de diciembre de 2014
sábado, 13 de diciembre de 2014
jueves, 4 de diciembre de 2014
miércoles, 3 de diciembre de 2014
martes, 2 de diciembre de 2014
lunes, 1 de diciembre de 2014
domingo, 30 de noviembre de 2014
CyberSecurity Program Reference Model
http://www.slideshare.net/markb677/cybersecurity-program-reference-model
CyberSecurity Program Reference Model
Business Model Canvas Links
https://docs.google.com/drawings/d/106IxnHbld6yZ8RsDAfz_Ug7T5xuWAv_dOsYJlUnRyIQ/edit
https://docs.google.com/drawings/d/1zXJsDf3uzAa2HuS5mT001BTLg0CaZod7im0PZ518imU/edit
http://www.ipm.sg/pub/BMcanvas/BM-Canvas_Examples.pdf
http://www.ipm.sg/pub/BMcanvas/index.htm
http://www.alexandercowan.com/business-model-canvas-templates/
sábado, 29 de noviembre de 2014
EA Quick Start Guide (Part 1): How to Set Up an EA Practice
EA Frameworks
Zachman - http://www.opengroup.org/architecture/0210can/togaf8/doc-review/togaf8cr/c/p4/zf/zf_mapping.htm
SABSA - http://www.opengroup.org/news/press/open-group-issues-guide-integrating-togaf®-sabsa®-secure-architecture-methodology
DODAF - http://pubs.opengroup.org/onlinepubs/7699939899/toc.pdf
COBIT - Part 1: https://store.opengroup.org/catalog/product_info.php?products_id=81&osCsid=g5lafh396o3m26l01sdjkf41e0 Part 2: https://store.opengroup.org/catalog/product_info.php?products_id=82
TMForum Framworx - http://blog.opengroup.org/2011/05/06/exploring-synergies-between-togaf®-and-frameworx/
C4ISR Architecture Framework - http://pubs.opengroup.org/architecture/togaf8-doc/arch/chap37.html
CORBA - http://pubs.opengroup.org/architecture/togaf8-doc/arch/chap37.html
Enterprise Architecture Planning (EAP) - http://pubs.opengroup.org/architecture/togaf8-doc/arch/chap37.html
Federal Enterprise Architecture: Practical Guide - http://pubs.opengroup.org/architecture/togaf8-doc/arch/chap37.html
FEAF - http://pubs.opengroup.org/architecture/togaf8-doc/arch/chap37.html
ISO/IEC TR 14252 (IEEE Std 1003.0) - http://pubs.opengroup.org/architecture/togaf8-doc/arch/chap37.html
NCR Enterprise Architecture Framework - http://pubs.opengroup.org/architecture/togaf8-doc/arch/chap37.html
ISO RM-ODP - http://pubs.opengroup.org/architecture/togaf8-doc/arch/chap37.html
SPIRIT Platform Blueprint Issue 3.0 - http://pubs.opengroup.org/architecture/togaf8-doc/arch/chap37.html
TAFIM - http://pubs.opengroup.org/architecture/togaf8-doc/arch/chap37.html
TEAF - http://pubs.opengroup.org/architecture/togaf8-doc/arch/chap37.html - See more at: http://www.mikethearchitect.com/2013/02/togaf-demystification-series-togaf-sucks-incomplete-and-overly-complex-togaf-demystification-series-overview.html#sthash.FxIVMPYq.dpuf
A SOA Journey Using the TOGAF ADM
http://blogs.perficient.com/ibm/2014/02/18/a-soa-journey-using-the-togaf-adm/
https://blogs.perficient.com/ibm/2014/02/18/a-soa-journey-using-the-togaf-adm/
http://blogs.perficient.com/ibm/2014/03/06/a-soa-journey-using-the-togaf-adm-part-2/
https://blogs.perficient.com/ibm/2014/03/13/a-soa-journey-using-the-togaf-adm-part-3/
viernes, 28 de noviembre de 2014
jueves, 27 de noviembre de 2014
HOW TO EXECUTE AN ENTERPRISE ARCHITECTURE TRAINING PROGRAM
http://wa-sample.trasuk.com/training/enterprise_architecture/HowToExecuteEATraining.html
WHERE ARE YOU IN YOUR EA EDUCATION PROCESS?
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.
AND THEN WHAT?
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.
CONCLUSION
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.
martes, 25 de noviembre de 2014
lunes, 24 de noviembre de 2014
domingo, 23 de noviembre de 2014
martes, 18 de noviembre de 2014
domingo, 16 de noviembre de 2014
lunes, 10 de noviembre de 2014
viernes, 7 de noviembre de 2014
10 Tests of Strategy
https://www.linkedin.com/pulse/article/20141106065509-3192694-11-ways-to-avoid-a-broken-strategy
To help avoid falling foul of this common pitfall, consider the 10 tests below from McKinsey.
- Will our strategy beat the market?
- Have we translated our strategy into an action plan?
- Is our strategy granular about where to compete?
- Is our strategy contaminated by bias?
- Does our strategy put us ahead of trends?
- Does our strategy rest on privileged insights?
- Does our strategy embrace uncertainty?
- Does our strategy tap a true source of advantage?
- Does our strategy balance commitment and flexibility?
- Is there conviction to act on our strategy?
martes, 4 de noviembre de 2014
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) .
lunes, 3 de noviembre de 2014
¿Qué es un Mapa Estratégico y para qué sirve?
http://www.blogtrw.com/2011/12/que-es-un-mapa-estrategico-y-para-que-sirve/
Qué es y cómo se hace un Plan Estratégico
http://www.blogtrw.com/2011/12/que-es-y-como-se-hace-un-plan-estrategico/
http://es.m.wikipedia.org/wiki/Mapa_estrat%C3%A9gico
Mapas estratégicos. BSC, modelos de aplicación
domingo, 2 de noviembre de 2014
martes, 28 de octubre de 2014
lunes, 27 de octubre de 2014
jueves, 23 de octubre de 2014
What’s a Business Architecture?
What’s a Business Architecture?
http://www.ronross.info/blog/2014/10/07/what%E2%80%99s-a-business-architecture/
miércoles, 22 de octubre de 2014
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.
Governance Videos
Planificación y organización en Cobit. GOBIERNO DE TI
https://www.youtube.com/watch?v=yQ0IPa79bHo
Cómo determinar la capacidad de los procesos en COBIT 5
https://www.youtube.com/watch?v=fskJELjF3Z4&feature=youtu.be
martes, 21 de octubre de 2014
lunes, 20 de octubre de 2014
The Seven Rs of Knowledge Management
http://gestionconocimientoti.blogspot.com.es/2013/12/the-seven-rs-of-knowledge-management.html
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
miércoles, 15 de octubre de 2014
martes, 14 de octubre de 2014
What’s a Business Architecture?
http://www.ronross.info/blog/2014/10/07/what%E2%80%99s-a-business-architecture/
What’s your definition of business architecture? Here’s ours:
a structural representation of a business solution as it relates to creating business value and achieving business goals
Like most practitioners we mean a blueprint.
Actually, blueprint doesn’t completely align with the dictionary definitions of architecture.[1] You can take your pick from the following alternatives, but not one of them refers to a representation of what is being built.
1. Art and Science: the art or practice of designing and building structures … in accordance with principles determined by aesthetic and practical or material considerations
2. Structure: formation or construction whether the result of conscious act or of growth or of random disposition of the parts … e.g., architecture and function of the cerebral cortex
3. Specific Result: instance of the exercise of the art or science of architecture … architectural product: architectural work … e.g., the mansions which comprise the entire architecture of the Square
4. Method of Style: a method or style of building characterized by certain peculiarities of structure …
The first definition above refers to architecture as an art and science. That’s what architecture students go to universities to learn, and what professional architects practice daily. Who today really thinks of business architecture as an art and science? It should be – and it probably will be eventually – but it’s not yet.
The first definition also highlights principles. Any viable approach to business architecture must enumerate its principles and adhere to them closely. That’s not just so much talk. The approach must provide proper thinking tools so that you can consistently act in accordance with the principles.
Do most current approaches to business architecture provide such thinking tools? I think not. If they did, they would feature:[2]
- Business policies (in the context of business strategy), business rules, and decision engineering. Those things represent the intellect of the organization and the fundamental answer for question why.
- A carefully factored approach whose component models cover each of the facets needed to communicate effectively with all the different audiences engaged with, or affected by, a business solution.
Let’s face it. Many techniques currently offered for ‘business architecture’ frankly aren’t even really about the business. They’re about – what else – IT’s view of the business.
Some related points:
1. We think that business architecture always involves some amount (often pervasive) of organizational transformation, which can be taken to include building a new business solution completely from scratch. Organizational transformation is inevitable, so other than buzzword appeal, there’s really no need to mention it in the definition of business architecture.
2. Architect can be used as a verb (to plan and contrive as an architect). Too bad “architecting” doesn’t roll off the tongue as easily as “designing” or “modeling”. After all, architecting business solutions is exactly what business architects should be doing daily.