http://ittz.ittraininggzonel.netdna-cdn.com/images/pdfs/COBIT_on_a_page_2013.pdf
martes, 30 de septiembre de 2014
lunes, 29 de septiembre de 2014
domingo, 28 de septiembre de 2014
TOGAF el framework para desarrollar SOA, BPM, ITIL, y COBIT
TOGAF el framework para desarrollar SOA, BPM, ITIL, y COBIT
https://www.youtube.com/watch?v=eZMoUM1_Qsc&feature=youtu.be
viernes, 26 de septiembre de 2014
miércoles, 24 de septiembre de 2014
martes, 23 de septiembre de 2014
lunes, 22 de septiembre de 2014
Lean Links
http://toyoutome.es/blog/lean-it-menos-es-mas/22687
http://www.gestiondeproyectosit.es/blogit/2014/05/primer-congreso-lean-it/
http://www.lean-it-summit.com/
http://es.slideshare.net/netmindit/techtuesday-introduccin-a-lean-it
http://comunidadleanit.com/celebracion-del-i-congreso-anual-aelit/#.VCBLcfl_s1J
Buenas prácticas en la gestión de requisitos
Buenas prácticas en la gestión de requisitos
http://www.habilissoftware.com/Blogs/index.php/es/articulos/1-buenas-practicas-requisitos
jueves, 18 de septiembre de 2014
miércoles, 17 de septiembre de 2014
martes, 16 de septiembre de 2014
lunes, 15 de septiembre de 2014
ITPM = APM + PPM + RPM + ???
IT portfolio management surely means different things to different people.
I notice Wikipedia defines IT portfolio management as comprising three
strands:
APM: applications portfolio management. (My main interest.)
PPM: projects portfolio management.
RPM: resources portfolio management.
.
My question is this: Why doesn't it include technology portfolio management?
Supposing technology includes desk tops, servers and infrastructure that
runs on them?
domingo, 14 de septiembre de 2014
viernes, 12 de septiembre de 2014
jueves, 11 de septiembre de 2014
The emerging role of IT governance
http://www.ibm.com/developerworks/rational/library/dec07/mueller_phillipson/
What is IT governance?
In order to discuss IT governance and its relevance to your business, we need to define governance. One informal definition of the verb govern is "to enact and control the policies and standards of a group, organization, or country." Because governance is an enacting force, it must be further refined using operational terms -- i.e., governance is a process. And we can define "process" as "a series of actions, changes, or functions bringing about a result."1 We'll cover the results of IT governance in a moment. First, let's assemble the pieces of this definition: "Governance enacts and controls the policies and standards of a group in a series of actions, changes, or functions which bring about a result." Now, let's extend this definition of governance in an operational context. Governance:
- Establishes chains of responsibility, authority, and communication (decision rights)
- Establishes measurement, policy, standards, and control mechanisms to enable people to carry out their roles and responsibilities2
In terms of IT governance, Item 1 above provides a static view of governance, bringing the structure of the enterprise into view, including how it functions and the roles and responsibilities for each member of the enterprise. As you may know, specification of the flow of decision rights is most often stated in a Responsible Accountable Consulted Informed (RACI) matrix. The RACI matrix is one of the artifacts of a governance solution.
Item 2 above provides a dynamic view of governance focused on business performance. The enterprise defines and institutes corporate policies (identifying the standards the business is going to follow and specifying a set of measures and controls) and, in turn, these policies are enforced by their business processes. Artifacts produced to define the dynamic view of governance include a policies library and governance effectiveness measures.
At its heart, governance in any form is about leadership. And IT governance is about the way in which leadership accomplishes the delivery of mission-critical business capability using Information Technology strategy, goals, and objectives. IT governance is concerned with the strategic alignment between the goals and objectives of the business and the utilization of its IT resources to effectively achieve the desired results.
IT governance disseminates authority to the various layers in the organizational structures within your business, while ensuring appropriate and prudent use of that authority. This doesn't refer simply to hierarchical structures; experience has taught us that network structures allow for specialization, teaming, and building infrastructure to support those teams. Specialization allows the sum of the parts of the organization to be greater than the whole.
However, structuring ourselves into networks can be counter-intuitive, and assembly of teams and sub-teams can often be a daunting task. Furthermore, experience has taught us that as teams grow in size and as the mission of the organization grows larger and more complex, the ability of individuals to communicate effectively and share a consistent vision decreases significantly.3 The addition of each new individual to a given project increases the potential communications traffic exponentially. Consequently, the need to implement a deliberate approach for the assembly of well-governed structures, processes, and tools requires deliberate planning, tactics, and methods.
Governance is not only for large organizations. Small organizations have a need for good governance as well. However, there are obviously a smaller number of control points to be deployed in a smaller operation.
IT Strategy and Governance
http://www.enaxisconsulting.com/p-it-strategy-governance
Is your strategy on solid ground?
Our approach draws from our experience in working with Energy clients, knowledge of technology trends, and understanding of organizational structures and talent management in IT, as well as a methodology that is based on equal parts external and internal drivers. Our deep technology credentials gives us distinctive insight across all levels in establishing a successful IT Strategy.
IT Strategy
We work at multiple levels based on our clients’ needs to define the enterprise IT Strategy or for a specific function or area. Our consultants bring an experience based understanding of the Energy business (upstream, midstream, downstream and utilities), technology trends, and business needs to help develop an IT strategy that will support and enable the broader business goals. We work with clients to define application strategies, ERP strategies, Infrastructure strategies, collaboration strategies, outsourcing strategies and others. We also have industry-specific experience around IT strategies for Upstream Application Portfolio or Pipeline Connectivity strategies or IT Infrastructure to support Smart-Grids for utilities.
IT Governance
Successfully implementing an IT strategy requires an organization and governance model tailored to the specific organization and the defined IT strategy. We help support IT strategy execution by designing the right organizational structure, governance model, decision-making processes and KPIs. We perform client workshops and team-building exercises to implement the right structures to achieve a successful strategy.
Business-driven IT Strategy
http://stevegeorghakis.blogspot.com.es/p/business-driven-it-strategy.html
Overview
Companies with well-conceived business and IT strategies and plans (BDITS) operate more effectively than those without. It is necessary for these strategies and plans to span a 3-5 year horizon in most cases due to the magnitude of work required to fully implement necessary solutions. The benefits of creating and sustaining a well defined BDITS include:
- Effective alignment among key senior executives regarding business strategy – resulting in coordinated decision-making and synchronized efforts across many functions.
- Improved organization morale and motivation through common understanding of the connection of their daily work to an end state that’s beneficial to the entire company.
- A massive reduction in wasted time and money on projects and other spending within the business and IT which is not aligned with the important capabilities needed by the company.
- Dramatically increased “speed to market” with regard to new solutions for external customers and faster internal project execution by the business and IT.
- Ability to “stay the course” while still being able to support periodic plan deviations through a more effective perspective on how these deviations fit within the context of major necessary improvements over the long haul.
- All of the above can yield to improved ability to innovate and execute in critical “business capability” areas allowing the organization to improve efficiency and operating effectiveness … driving better top-line and bottom-line financial results and improved shareholder returns.
BDITS Activities and Deliverables
Activities that need to be performed during an initial BDITS will require substantial time and effort on the part of the organization, and usually will require assistance from a third-party consulting firm with experience performing work of this nature for companies in similar industries. It is both the assistance from a time and effort standpoint, and the expertise that drives the need for external assistance. The activities described below can be performed anywhere from 7-10 months by most organizations (and accomplished in a more compressed time for some companies depending on the scope pursued).
(1) Develop Strategic Enterprise Framework and Conduct Background EA Work
This set of activities involves defining the strategic aspects of the future-state that the company intends to put in place, and performing the background work on the current-state business operation to prepare for the next stage of work. Effective current-state work products will help to focus subsequent BDITS activities and reduce the time and cost of external consulting assistance to help analyze and document the current-state.
(2) Form Teams and Create Functional Roadmaps
This set of activities involves applying the strategic inputs defined in Phase 1 – above, and applying them broadly to the enterprise across functions AND in an in-depth manner in priority functional areas of focus. For all functional areas, high-level pain points and improvement opportunities are gathered from existing data and information (e.g. desired projects, open IT enhancement requests, recently conducted analyses, etc.) and several work sessions are conducted with business and IT leaders in these areas. For priority areas of focus, more detailed work is performed involving an extensive analysis of the current-state business and technology operation, definition of functional business objectives, creation of a vision of how the company wants to operate in this functional area in the future (using strategic inputs defined in Phase 1), definition of detailed business capabilities which must be put in place to meet functional objectives, a gap analysis of where the company stands today versus the future desired vision, and a plan (which will address people, process and technology) for achieving the desired future vision over the next 3-5 years. Functional roadmaps defined in Phase 2 are a key input to the Integrated Strategic Roadmap (IRS) developed in Phase 3.
(3) Develop Integrated Strategic Roadmap
The integrated strategic roadmap is Phase 3 of the BDITS initiative and involves synthesizing the functional roadmaps created in Phase 2 and creating an overall solution architecture for implementing appropriate initiatives defined in the functional roadmaps. It is important to note that it is highly likely that not all of the initiatives defined by the functional teams during Phase 2 will “make the cut” in the Integrated Strategic Roadmap (for reasons which involve potential overlap and redundancies with initiatives created by other functional teams, overall capacity of the organization to implement solutions and other sequencing issues related to the nature of the underlying foundational technology which must be put in place to support all of the functions in aggregate).
(4) Gain Approval and Manage Portfolio Execution
This final major phase refers to the approval gained from the Board and Executive Committee to move forward with the implementation of initiatives defined in the BDITS, and then the subsequent adjustments to the existing portfolio and formation and launch of specific BDITS projects.
With the above being said, in order to effectively execute on a BDITS, a well-implementedframework is absolutely necessary.
A Framework for Strategy, Governance & Delivery
http://stevegeorghakis.blogspot.com.es/p/framework-for-strategy-governance.html
Many organizations struggle with the combination of strategic and tactical activities necessary to maximize the value of IT investments. There are literally dozens of activities that need to be executed in an integrated fashion in order to fully leverage the power of Information Technology to power the enterprise.
The following graphic describes four critical areas of focus, which have many points of integration with each other ... all tied together by effective IT governance (both strategic and tactical):
miércoles, 10 de septiembre de 2014
martes, 9 de septiembre de 2014
Too many Framewoks?
http://www.pragmaticea.com/frameworks.asp
To answer one question that a collegue asked me today
https://www.linkedin.com/groups/list-ALL-ENTERPRISE-FRAMEWORKS-36781.S.203811127
viernes, 5 de septiembre de 2014
FIT3136 IT governance and strategy for business - Semester 1, 2014
http://www.infotech.monash.edu.au/units/archive/2014/s1/fit3136.html
Unit Schedule
Week
Activities
Assessment
0
No formal assessment or activities are undertaken in week 0
1
Strategic contexts of organisations
Tutorials begin in Week 1
2
IT strategy and business strategy
3
IT strategy alignment
4
IT governance
5
IT governance (continued from Week 4)
6
IT processes
7
IT systems success and failure
Assignment 1 is Due
8
Funding IT function
9
IT outsourcing
10
Legal issues with IT
11
Legal issues with IT and Green IT
12
Unit review and exam discussion
Assignment 2 is Due
SWOT VAC
No formal assessment is undertaken in SWOT VAC
Examination period
LINK to Assessment Policy:http://policy.monash.edu.au/policy-bank/
academic/education/assessment/
assessment-in-coursework-policy.html
*Unit Schedule details will be maintained and communicated to you via your learning system.
IT Strategy and Governance
http://www.pwc.com/ca/en/technology-consulting/technology-advisory/it-strategy-governance.jhtml
Developing business-focused plans and governance structures
PricewaterhouseCoopers can help you develop a technology strategy aligned to your business objectives. Our team of seasoned advisors have helped clients in many industries using their experience in IT architecture, IT management, IT governance, compliance, risk, IT sourcing and service delivery.
If your business needs a strategy or governance structure to improve the effectiveness of your IT operations, our team can provide a tailor-made solution to get your IT function on track.
How PwC can help
Leveraging PricewaterhouseCoopers’ leading methodology and frameworks including our TRANSFORM™ IT framework, we help you develop:
- IT Strategic Plan: We identify gaps between your IT function (strategy, structure, people, process, technology) and your current and future anticipated organizational direction. We then collaboratively work with you to design a “blueprint” of your future operating model as well as a roadmap outlining the short, medium and long term initiatives required to get you there.
- IT Governance Program: We help you design and implement the organizational, reporting and risk management changes necessary to execute your strategy. Typical drivers include a desire to better align IT with the business, a desire to reduce cost and complexity, a need to better manage risk and compliance or a need to remediate service quality issues.
Contact us to find out how we can help you with your IT strategy.
jueves, 4 de septiembre de 2014
miércoles, 3 de septiembre de 2014
martes, 2 de septiembre de 2014
lunes, 1 de septiembre de 2014
COBIT 5 y el concepto de alineamiento
http://www.ittrendsinstitute.org/perspectives/item/cobit-5-y-alineamiento
http://www.magazcitum.com.mx/?p=2593
Las conversaciones mantenidas en cierta red social profesional siguen ofreciendo un rico escenario para el intercambio de ideas. Lo afirmé en mi primera intervención en este medio[i] y aún lo sigo manteniendo.
Hace tan sólo unos días, un buen amigo, Óscar, advertía sobre la desaparición del término “alineamiento” en COBIT 5. Mis reflexiones sobre el particular quedan resumidas en la siguiente radiografía del modelo.
1. COBIT y el alineamiento: enfoque filosófico básico
Si algo ha sido COBIT en los últimos años, particularmente a partir de 2005 con la publicación de la versión 4.0, es un modelo para el alineamiento entre TI y el resto_del_negocio[ii]. Más allá de ofrecer un árbol de dominios, procesos y actividades - aún hoy, muchos no han avanzado más en su conocimiento de COBIT-, incorporó en sus apéndices algo totalmente revolucionario: las matrices de relación Metas para el resto_del_negocio-Metas para TI-Procesos para TI, siendo esta aportación diferencial, frente a otros conocidos marcos y normas basados en procesos, lo que convirtió a COBIT en “EL” marco de referencia para el alineamiento de TI con el resto_del_negocio.
Tan relevante fue dicha aportación hecha por la Universidad de Amberes a través de su IT Governance & Alignment Research Institute[iii], que se mantuvo y se revisó para la siguiente versión del modelo, COBIT 4.1 (2007) y se ha constituido en pieza central de la versión en vigor, COBIT 5 (2012).
Podría pensarse, incluso, que la pronta revisión realizada en 2007 de un, todavía, joven COBIT 4.0, tuvo bastante que ver con esos apéndices.
A pesar de la supresión del objetivo de control detallado ME4.2 Strategic Alignment (alineamiento estratégico) que existía en COBIT 4.1, la nueva versión declara al respecto que “In COBIT 5, alignment is considered to be the result of all governance and management activities” (en COBIT 5, se considera el alineamiento como el resultado de todas las actividades de gobernanza y gestión).
Dicha declaración no hace sino subrayar lo señalado arriba, esto es, la consideración de todo el marco COBIT como un modelo para el alineamiento.
Sin embargo, en contra de lo que el propio COBIT 5 declara, resulta oportuno indicar que el antiguo proceso ME4.Provide IT Governance (proporcionar gobierno corporativo de TI) y, con él, su subproceso ME4.2 no han desaparecido realmente, sino que subyacen en COBIT 5 a las prácticas y actividades de procesos como EDM01.Ensure Governance Framework Setting and Maintenance (garantizar el establecimiento y el mantenimiento de un marco de gobernanza) y EDM02. Ensure Benefits Delivery (Garantizar la materialización de beneficios).
La conclusión de todo ello es que el alineamiento está absolutamente presente dentro de COBIT 5, hasta el punto de constituir una de sus partes más nucleares, si no la más.
2. COBIT y el alineamiento: los objetivos genéricos
Una rápida observación de las citadas matrices de objetivos genéricos, para el resto_del_negocio y para TI, permite identificar fácilmente un claro aroma a alineamiento en algunos de ellos. Sirvan como ejemplo los tres siguientes:
- La meta para el resto_del_negocio número 1: Stakeholder value of business investments (valor de las inversiones de negocio -incluidas las de trasfondo tecnológico- para los diferentes grupos de interés).
- La meta para TI número 1: Alignment of IT and Business strategy (alineamiento de las estrategias del resto_del_negocio y de TI).
- La meta para TI número 7: Delivery of IT services in line with Business requirements (entrega de servicios de TI en línea con las demandas del resto_del_negocio).
Por cierto, las llamadas “metas para TI”, al final, son también objetivos del resto_del_negocio, puesto que son los objetivos que espera de TI.
3. COBIT y el alineamiento: los procesos
- APO02. Manage strategy (gestionar la estrategia), cuyo fin no es otro que “Align strategic IT plans with Business objectives“(alinear los planes estratégicos de TI con los objetivos del resto_del_negocio).
- APO03. Manage Enterprise Architecture (gestionar la arquitectura de empresa), en cuya definición aparece una nítida referencia a “Improve alignment” (mejorar el alineamiento).
4. COBIT y el alineamiento: referencias adicionales
En 2003, ISACA decía[iv] que “Fundamentally, IT governance is concerned about two things: IT’s delivery of value to the Business and mitigation of IT risks. The first is driven by strategic alignment of IT with the Business. The second is driven by embedding accountability into the enterprise” (básicamente, el gobierno corporativo de TI se refiere a dos cosas: la entrega de valor para el negocio, por parte de TI, y la mitigación de los riesgos vinculados a TI. Lo primero se logra mediante el alineamiento estratégico de las TI con el negocio. Lo segundo, integrando la rendición de cuentas dentro de la empresa).
La frase resulta demoledora porque pone de relieve dos pilares básicos del gobierno corporativo de TI: la rendición de cuentas (imputabilidad) y el alineamiento (sincronización); los cuales, no pocas veces, están en la génesis de todos los problemas a los que se enfrentan las áreas de TI, y, por ende, las organizaciones.
Por otra parte, bajo el referido mensaje de COBIT 5 -”alignment is considered to be the result of all governance and management activities“- se advierte de nuevo la mano del IT Alignment & Governance Research Institute, cuyos responsables, los profesores Van Grembergen y De Haes, decían en 2008[v] que “the ultimate goal of IT governance is the alignment of information technology with the business, often referred to as strategic alignment” (el objetivo último del gobierno corporativo de TI es el alineamiento de las tecnologías de la información con el negocio, a menudo denominado alineamiento estratégico).
Los mismos autores publicaban en 2009 una obra de título igualmente revelador: “Enterprise Governance of IT: Achieving Alignment and Value“[vi], insistiendo en su idea del logro del alineamiento como una meta, más que como un motor.
Lo anterior recuerda el cuento de quién fue primero, ¿el huevo o la gallina? Dicho de otro modo, cabe pensar que:
1. El alineamiento resto_del_negocio y TI es resultado de la puesta en marcha, dentro de la organización, de un adecuado sistema de gobierno corporativo [de TI] y,
2. Al mismo tiempo, la existencia de un correcto engranaje (alineamiento) entre el resto_del_negocio y TI contribuye a que el sistema de gobierno corporativo [de TI] de la organización funcione óptimamente.
Por último cabe reseñar un párrafo -lamentablemente suprimido en la edición final de COBIT 5, pero que aparecía en un borrador[vii] y que decía así (pág. 63): “Alignment is not a specific (process) activity, but is achieved through successful execution of the processes in the governance and management areas. The combination of the ‘evaluate’ and ‘direct’ governance practices in the governance area and the resulting direction given to management constitutes alignment” (El alineamiento no es una actividad (proceso) específica, sino que se alcanza mediante la exitosa ejecución de los procesos que conforman las áreas de gobernanza y gestión. La combinación de las prácticas ‘evaluar’ y ‘establecer la dirección’ del área de gobierno corporativo y la propia dirección resultante indicada a los ejecutivos constituyen el alineamiento).
En conclusión y, sin duda, una buena sincronización estratégica hará que las cosas funcionen bien; pero este último párrafo no parece que suene del todo mal ¡Si hace las cosas “bien”, al final, TI estará actuando con y para el resto_del_negocio (del que, naturalmente, forma parte)!
* * *
This article was originally released by Mexican magazine "Magazcitum", on July, 11th, 2014.
The Role of Solution Architect
The role of an architect is often loosely or ill defined so I'm not surprised when people ask me what I think an architect's role should be, and how one type of architect relates to another. In reality, this is to be expected given the range of needs, projects, processes, and organizational structures at different companies. Just today, two different clients asked about the role of a solutions architect, particularly in relation to an enterprise architect.
The table below summarizes the main differences that I typically see.
Table 1 -- Comparison of Solution and Enterprise Architects
Topic
Solution Architecture
Enterprise Architecture
Scope
Single solution or set of related solutions
All current and future solutions and COTS
Primary Goals
Ensure that the solution fits within the enterprise context
Define the enterprise context including business, information, application, and technology
Responsibility
Translates nonfunctional and functional requirements into design, within enterprise context
Translates strategies into target architectures and roadmaps
Tradeoffs
Enterprise strategy and goals vs. solution tactical and delivery requirements
Prioritization and rationalization of conflicting business, information, and technology requirements
Primary Artifacts
Solutions architectures and designs
Enterprise reference architectures, patterns and standards
Primary Stakeholders
Solutions owners, EA, development team, technology
Executive leadership, business leaders, CIO, solutions
Characteristics
Credibility with solutions teams and owners
Broad knowledge and experience, vision
Skills
Conceptualization, patterns, modeling, design, communications
Contextualization, conceptualization, abstraction, modeling, communications
Reporting Structure
Assigned to and functions as part of solution team; may report to solution owner or line of business, development, or EA
Reports to EA team, typically part of CIO organization
Regardless of their role and title, architects apply architecture skills, principles, and best practices. Both architects want to establish a few fundamental concepts:
- What things need to be the same to achieve goals, efficiency, and effectiveness?
- What things need to be different to achieve competitive, geographical, and other requirements?
- How do the similarities and differences fit together in context?
The most obvious difference is the scope to which these are applied. An enterprise architect has an enterprise-wide scope, while a solution architect has a narrower scope. The difference in scope leads to perhaps the most important distinction between these two roles, which is the primary goal of the architect. An enterprise architect wants to answer these questions at the enterprise level and define the enterprise context of what things need to be the same (such as common customer information), what should be differentiated (such as partner relationships and policies), and how they fit together. In coming up with the enterprise context, the EA must consider business, information, application, technology, and security concerns.
Given that context, the primary goal of the solution architect is to ensure that the solution fits within the enterprise context. This means that the solution aligns with business goals and processes, uses and provides enterprise information consistently, integrates effectively with other applications, supports a common application environment and user interaction model, uses the common technology platform, and achieves enterprise level security, QoS and scale. However, the solution team in general is focused on the specific solution and may not have a very good understanding of the enterprise context. Therefore, the solution architect acts as a bridge between the Enterprise Architecture and the solution to make sure that the solution fits within that enterprise context.
In achieving these goals, each architect has different responsibilities, makes different tradeoffs, has different stakeholders, and creates different artifacts. And while the skill sets are similar, there are a few important priorities. Perhaps the most important quality that the solution architect can have is credibility with their stakeholders. If the architect is trying to influence business process design, then they better have some knowledge and experience with BPM. If they're trying to influence software design, then some foundation in software engineering will be important. While credibility is obviously important for an EA, we also require the EA to have an understanding of a broad range of topics and widely varied experience. In addition, it is critical for the EA to be able to envision the future state of the enterprise and translate that vision into a target architecture.
A less important distinction is the actual reporting structure. I have seen solution architects report to the development team, a line of business, a solution owner, or even be part of the EA group. (Actually, I often recommend that EA provide a solution architecture team whose members are assigned to solution projects.) Rather, what is more important is that the solution architect acts as the bridge between the solution and the enterprise context and architecture so that both sets of goals are achieved.
I welcome your comments about this Advisor and encourage you to send your insights tomrosen@cutter.com.
-- Mike Rosen
While Enterprise Architecture is dead, TOGAF is alive, according to Forbes
Following on "Enterprise Architecture: Don't Be a Fool with a Tool" and "Is Enterprise Architecture Completely Broken?" published on Forbes, we may ask ourselves, what does TOGAF deliver if practitioners report that EA is broken while TOGAFers state that EA is alive and prospering? Whatever it is, it may not be EA then.
In fact, in my TOGAF course, I have not even been given the EA definition.
See also previous post for part i.
According to Viswanathan, "there’s a revolution taking place, particularly among the Indian System Integrators (SIs)... Everyone is trying to jump on the TOGAF bandwagon.”
Revolution is not, let' s reserve the word for things that matter, but true, many board the TOGAF train.
The paradox is that, while EA delivers "paltry" results, TOGAF training, certification and consulting services accelerate. "Weird" as Jason noted. Perhaps because there is profit in teaching it while there is less in employing it.
Still, TOGAF has trampled the competition.
TOGAF fails, according to Brown and Viswanathan, only because:
"TOGAF initiatives are still bound to fail when the people involved apply it improperly... take it too literally..., when people assume you have to do all of TOGAF from end to end" and... because "there is also clearly a shortage of deep TOGAF expertise on the market" as Viswanathan states.
And "...they’re not adapting it for their organization, or they’re not getting people who’ve ‘been there, done that, got the T-shirt, have the scratch marks’ to help with the initiative" as Brown explains.
Perhaps then, since most acquire TOGAF from training, this reasoning indicates a systematic failure of TOGAF and associated training and consultancy in conveying to architects how to "adapt" and use it, rather than a failure of the practitioners alone, that are ultimately blamed in the above.
Still, most, including consultancies, failed to deliver EA using TOGAF given its overall poor results.
Consultancies have though the typical excuse: they guide you but you are ultimately responsible for the results. And trainers don't usually do EA, have never done one, they train.
Taking into account the results, it also looks like there are plenty of "people who've been there and done that" in TOGAF but... with equal lack of success, never mind that training and certification.
It is rather surprising to state that there is a "shortage of deep TOGAF expertise". After all, there has been plenty of training and certification done so far. What is the certification good for then? It surely does not guarantee the EA delivery. How do ypu recognize these deep TOGAF experts?
TOGAF is not a cookbook but it should be. After all, that is what people expect from an EA framework. Put your parts in, in some established format and proportions, and have the result at the other end, edible.
That's what we do and expect when we cook from a cookbook. We are not expected to chose and play with the ingredients and quantities, because we would not be inventing then our own recipe and experimental dish.
TOGAF should be as predictable as a recipe and consumable as its outcome. But is is neither.
Still, TOGAF, as a collection of practices alone does not guarantee the EA result, indeed. We may use it as an aid, choose bits or dispense with it altogether to go for the original sources for such "tools" as requirements or risk management, but solely if we need them.
“"Without EA, companies muddle through, where business managers have to ask for information for decision making all the time,” explains Viswanathan".
The most important deliverable of EA is components in interconnections, that is diagrams linked in a the big picture, rather than information on isolated components. For information alone, there already are systems support and inventory tools in the enterprise.
"Without a framework, how do you connect corporate strategy to projects downstream?" Viswanathan says.
EA, rather than determining the projects, helps one scope the strategic transformation projects to the enterprise components and dependencies they impact.
That is, in case EA is more than IT, which TOGAF is not.
There are a few natural steps, well known and always the same, rather than three "approaches" as Viswanathan explains, in achieving EA.
Do the current architecture, establish target state according to business vision, strategy and architecture criteria, and assess gaps and execute themas a transformation program.
But nonetheless, this simple cycle from As-Is to To-Be does not even appear explicitly in the TOGAF ADM.
Least but not last, is there such a best practice in Open Group to have a formal "speaker" nominated to communicate on behalf of TOGAF, a representative that can sanction, or not, such a view as "TOGAF is not a cookbook"... so that it cannot be ignored, discarded or denied later?
PS: I still can't post my comments on this last Forbes post.
Suscribirse a:
Entradas (Atom)