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
