http://www.projecttimes.com/templates/project-management-templates.html
domingo, 30 de junio de 2013
lunes, 24 de junio de 2013
What is Business Architecture?
http://blog.opengroup.org/2013/04/30/what-is-business-architecture/
http://ingenia.wordpress.com/2013/06/16/business-capability-based-ea-roadmap/
http://enterprisearchitects.com/bridging-business-analysis-and-business-architecture-australia/
http://ingenia.wordpress.com/?s=business+analyst
http://weblog.tetradian.com/2013/03/20/opengroup-on-bizarch/
domingo, 23 de junio de 2013
How to apply transformational leadership at your company
To be a leader and manager you need to have a solid understanding of things such as project management, organizational skills, managing employees and monitoring their performance, but even masters of these skills aren't necessarily transformational leaders. These skills are simply the foundation on which a transformational leader is most effective.
Some people are just born with leaderships skills and the rest of us have to work at it. You've seen them before--the charismatic leaders who have a way of motivating the people around them. They instill a feeling that we are all accountable and that if one of us fails, we all fail.
These leaders are on a mission to effect positive change for both the organization and the people they work with, and their energy and passion help fuel cohesion among peers and team members, allowing them to larger than the sum of their parts. They challenge long-held assumptions and don't accept answers like, "because this is the way we've always done it."
What Is Transformational Leadership?
Transformational problems are the critical issues a company or organization faces. Most times they relate to attitudes, behaviors and culture. They are rooted in the core and can be difficult to pinpoint without deep analysis.
"Woodrow Wilson called for leaders who, by boldly interpreting the nation's conscience, could lift a people out of their everyday selves. That people can be lifted into their better selves is the secret of transforming leadership," - James MacGregor Burns.
James MacGregor Burns is credited with creating the concept of transformational leadership in 1978. He was a presidential biographer and a leadership expert who focused mainly on the improvement of management principles and procedures.
Burns said that a transformational leader needs to have a solid understanding of the necessary goals to be successful and be articulate in explaining those goals and the method to which they are to be achieved.
"Change doesn't really happen at a company; it happens with people, so in order to lead change you have to know how to lead people," says Pamela Rucker, chairwoman of the CIO Executive Council's Executive Women in IT.
Transformational leaders are described as charismatic, enthusiastic, optimistic, passionate and sometimes visionary, giving them the ability to change long-held perceptions and beliefs. Those traits can spread like a wildfire; when they do, leaders and workers can engage more effectively allowing real transformation to take place.
Leadership Styles
Kevin Ford co-author of the upcoming book, "The Leadership Triangle" and CIO of Tag Consulting says he believes there are three kinds of successful leadership styles and that each one has its own place depending on the challenges you are facing:
- See more at: http://www.cio-asia.com/resource/leadership-and-mgmt/how-to-apply-transformational-leadership-at-your-company/#sthash.Vc0shNeK.dpuf
Applied Enterprise Architecture
How to build better systems – the specification
http://pragmaticarchitect.wordpress.com/2013/06/18/how-to-build-better-systems-the-specification/
viernes, 21 de junio de 2013
jueves, 20 de junio de 2013
Business capability. Definitions
http://en.wikipedia.org/wiki/Capability_management_in_business
Business capability defined [edit]
A business capability is WHAT a company needs to be able to do to execute its business strategy (e.g., Enable ePayments, tailor solutions at point of sale, demonstrate product concepts with customers, combine elastic and non-elastic materials side by side, etc.).
Another way to think about capabilities is they are a collection or container of people, process and technology that is addressable for a specific purpose.[1] Capability management is an approach that uses the organization's customer value proposition to establish performance goals for capabilities based on value contribution. It helps drive out inefficiencies in capabilities that contribute low customer impact and focus efficiencies in areas with high financial leverage; while preserving or investing in capabilities for growth.
Capability management topics [edit]
Capability vs. process [edit]
A process is HOW the capability is executed. Much of the reengineering revolution or Business process reengineering focused on HOW to redesign business processes.
Business vs. organizational capability [edit]
An organization capability refers to the way systems and people in the organization work together to get things done.[2] The way leaders foster shared mindset, orchestrate talent, encourage speed of change, collaboration across boundaries, learn and hold each other accountable – define the company's culture and leadership edge.
Capability vs. competency [edit]
Although often used interchangeably, "capability" and "competency" are quite different.[3] makes a distinction between capabilities and competencies: individuals have competencies while organizations have capabilities. Both competencies and capabilities have technical and social elements.
Individual
Organization
Technical
Functional Competencies
Business Capabilities
Social
Leadership Competencies
Organizational Capabilities
At the individual-technical intersection, employees in the firm bring functional skills and competencies such as programming, cost accounting, electrical engineering, etc. At the individual-social intersection, leaders also have a set of competencies or skills such as setting the strategic agenda, championing change and building relationships. Moving to the intersection of organizational and technical, are business capabilities. In short, they are the technical things or what the firm must know how to do to execute strategy. For example, a financial service firm must know how to manage risk and design innovative products. Finally, we have organization capabilities such a talent management, collaboration, and accountability. According to Ulrich, they are the underlying DNA, culture, and personality of the firm. They integrate all the other parts of the firm and bring it together. When a group of leaders have mastered certain competencies, organization capabilities become visible. For example, when a group of leaders master "turning vision in to action" and "aligning the organization," the organization a whole shows more "accountability."
miércoles, 19 de junio de 2013
lunes, 17 de junio de 2013
on Enterprise Architecture
Business Capability based EA Roadmap
http://ingenia.wordpress.com/2013/06/16/business-capability-based-ea-roadmap/
How to measure Enterprise Architecture
http://ingenia.wordpress.com/2013/06/16/how-to-measure-enterprise-architecture/
domingo, 16 de junio de 2013
viernes, 14 de junio de 2013
Ten Silver Rules for EA
http://futureofcio.blogspot.com.es/2013/06/ten-silver-rules-for-ea.html
“The rules of navigation never navigated a ship. The rules of architecture never built a house.” - Thomas Reid
Part of the (enterprise) architect's role is to explicate the organizations architecture by identifying the components (capabilities, implementations, management structures, etc.) that make up the architecture at a point in time. Here are ten silver rules of EA.
- Enterprise Architecture, as a discipline and a function, should be responsible for the form and expression of enterprise strategy
- Architecting an enterprise has to output an actionable blueprint to build an operating enterprise
- Architectures (enterprise or otherwise) are built from reusable assets; EA frameworks are built to manage reusable assets to avoid reinventing wheels;.
- EA is not about Documentation. It is about Providing Direction, so that decisions can be made, executed, and measured. If EA has been treated as a purely technical exercise consisting of completing documents, then it will not be effective
- EA is not for pursuing Perfect-ness, but for achieving Better-ness; it's the framework to allow asking questions and expect to get answers.
- The most important task of EA (EA as a management function, not as a set of artifacts) is to enable and make the most of organizational change
- EAs should define the target enterprise (not merely the target architecture), and Enterprise architecture is the architecture of the enterprise, not just IT architecture.
- The ultimate value of EA is not in the plan (EA vision, strategy, roadmap) itself, it is in value created by operationalizing the plan.
- EA without BPM would not yield and vice-versa. EA provides the holistic view of process with all relevant elements
- The unique value proposition of enterprise architecture is ensuring the success of human Endeavour.
jueves, 13 de junio de 2013
Ban the Word “Alignment” From Your Architecture
http://dougnewdick.wordpress.com/2013/06/11/ban-the-word-alignment-from-your-architecture/
Something about the typical language of enterprise architecture is starting to bug me. The overuse of the word “alignment”. When people are asked to describe what enterprise architecture is all about, they often answer with the phrase “it’s about the alignment of IT with business strategy”. But is that enough? Should it be something more?Architectures fit into hierarchies of plans. Typically in enterprise architecture we say that our enterprise architectures must align with our business strategy, that our solution architectures must align with our enterprise architecture, our security must align with our enterprise security architecture, that our application architectures must align to our application architecture etc. etc.
Because when we say something aligns with something else, what are we really saying? We are saying that they don’t fundamentally disagree. That they don’t contradict one another. But is that what we really want from different parts of our architectures? Is that what we really want to say about the relationship between our organisation’s strategy and its IT architecture – that they aren’t inconsistent? Is that enough? Isn’t that just a cop-out?
In this case, as in many others, I think that how we talk about architectures (our discourse) reveals something important about our practice of architecture. It reveals how we are thinking about architecture and what we are doing to a certain extent.
Too often when people use the word “alignment” it just means that what they are doing isn’t obviously undermining the higher level objective. If we believe that through architecture we are trying to drive better outcomes for business from our use of IT, then we must demand more than just alignment. What we need, and therefore what we should demand, what we should describe and what we should talk about is:
- Our architecture delivering higher level outcomes.
- Our architecture contributing to higher level outcomes.
- Our architecture supporting higher level outcomes.
- Our architecture enabling higher level outcomes.
If your architecture doesn’t do any of these then you should have a damn good excuse (and there may well be one – tactical, temporary or risk mitigation architectures can often ignore these things for very good reasons). Otherwise, you should be able to demonstrate how it is doing one of these things, because that is how you will be demonstrating the value of your architecture.
Whatever we say (and do) about our architectures, I think we will be better off when we ban the word alignment.
miércoles, 12 de junio de 2013
martes, 11 de junio de 2013
Zachman Framework
http://test.zachmaninternational.com/index.php/ea-articles/25-editions
The Zachman eBook: Editions
There are two versions of The Zachman eBook™: the Basic Edition and the Standard Multimedia Edition. The Basic Edition (order here) only includes the first major content subdivision with all of the related footnotes and figures, whereas the Standard Multimedia Edition (order here)includes the three major subdivisions, all related footnotes, figures, appendices, and about 20 several minute video clips of John Zachman responding to questions being posed by off-camera interviewers on topics linked to the written material.
CIO and C-SUITE
http://www.informationweek.co.uk/global-cio/careers/6-tips-how-to-speak-c-suite/240155344?pgno=2
http://blogs.wsj.com/cio/2013/06/10/the-new-cio-chief-innovation-officer/
http://futureofcio.blogspot.com.es/2012/05/five-c-words-at-c-suite.html
http://www.computerweekly.com/feature/The-changing-role-of-the-CIO-in-the-business
http://www.insurancejournal.com/magazines/features/2013/05/20/292098.htm
http://blogs.gartner.com/mark_mcdonald/2011/05/02/the-cio-and-the-rest-of-the-c-suite/
http://www.ey.com/GL/en/Services/Advisory/The-DNA-of-the-CIO
http://blogs.hbr.org/events/2013/05/change-the-conversation-change.html
http://blogs.hbr.org/cs/2013/05/three_ways_cios_can_connect_with_the_c-suite.html
lunes, 10 de junio de 2013
Enterprise Architect - Togaf, Business Process Management, Strategy, D
Job Title
Enterprise Architect - Togaf, Business Process Management, Strategy, D
Job Details
Job Code
6126109
Minimum Salary
46000
Salary Type
Competitive
Maximum Salary
52000
Job Type
Permanent
Location
Yorkshire
Category
I.T. & Communications
Description
Hours of work: 35 Hours (Monday to Friday 9am - 5pm)
Closing Date: 7th of June 2013
Background:
Yorkshire Building Society has been through a period of substantial growth and mergers over the past few years. We have recently embarked on a major business transformation programme running until 2017. Our Enterprise Architecture function is one of the keys to its success and has an excellent opportunity for experienced Enterprise Architects to define, develop and govern the Enterprise Architecture within the Society.
Purpose of Role:
You will ensure proposed change to the architecture is in line with strategy, and is fully understood and communicated to interested and affected parties. You will also manage and plan activities to develop the required Enterprise Architecture within Group Change and IT and its business users, supporting an EA Governance framework ensuring the effective promotion of these capabilities.
As an Enterprise Architect you will develop and maintain the required current and future state architecture roadmaps which will be used to ensure the architecture framework is aligned to the strategy and business objectives. You will undertake functional & non functional (eg security, error management, application trace-ability) technology based Research & Innovation (R&I) activities to further develop the enterprise reference architecture, managing, defining & coordinating proof of concept activities (POC) as required, with recommendations for ways forward.
If you think you have the ability to stay abreast of internal and external IT developments coupled with desire to provide input into team activities and mentoring less experienced staff on EA you might be the ideal candidate for this role.
If you have:
- Detailed knowledge of the design, development and implementation of complex software solutions using a variety of software tools and methods to meet business and operational requirements
- Excellent communication and influencing skills at all levels, working with both IT business users to analyse problems and produce detailed documentation to articulate existing and proposed software solutions
- Excellent analysis and problem solving skills with the ability to view beyond the obvious using internal & external 3rd party resources
- Experience of Business Process Management (BPM) software and techniques together with their usage to enhance the software development processes Experience of providing detailed enterprise roadmaps to show the current and future state architecture TOGAF 9 accreditation Knowledge of Datamodelling techniques
We offer:
- 27 days holiday plus bank holidays
- Pension Scheme
- Car Allowance
- Private Medical Insurance
- Health Cash Plan
- Staff Restaurant
- Bonus scheme
- On site gym
- Discounted staff investment and mortgage products
Links Frameworks
Links
Enlaces
Balanced Scorecard: Balanced Scorecard is a strategic planning and management system which is used transform strategic plan into “marching orders” and helps provide performance measurements and identifies what need to be done.
http://www.balancedscorecard.org/BSCResources/AbouttheBalancedScorecard/tabid/55/Default.aspx
BCM/BS25999: BS25999 is the standard for business continuity management (BCM) which helps the organizations mainly operating in high risk environment to minimize the risk. BS25999 has two parts: first part is the code of practice for BCM and second is the specification for BCM.
http://www.bsigroup.com/en/Assessment-and-certification-services/management-systems/Standards-and-Schemes/BS-25999/
Business Plans: A business plan is a written document which has an outline of the structure of the business, its objectives, its product/service, market, finance forecast and other plans which provides them with the vision of how they are reaching their goal.
http://www.startups.co.uk/6678842911547985232/what-is-a-business-plan.html
CMMI: Capability Maturity Model Integration is a set of integrated model that addresses product development and maintenance with importance on both system and software engineering. It is a process improvement approach.
http://www.informit.com/articles/article.aspx?p=98146
COBIT: Control Objectives for Information and Related Technology is an IT governance control framework that bridges the gap between control requirement, technical issues and business risk.
http://www.itgi.org/
COSO: Committee of Sponsoring Organizations framework consists of five components which helps organizations to identify the fundamental and essential objective. In 204 COSO issued Enterprise Risk Management (ERM) which provides clear guidance for ERM.
http://www.sox-online.com/coso_cobit_coso_framework.html
Data Protection: Data Protection ensures that the data organization hold, process or use about every individual is managed properly.
http://www.jisclegal.ac.uk/Portals/12/Documents/PDFs/dataprotection.pdf
Green IT: Green IT provides services to make measurable financial and environmental benefits from programs. The natural resources being finite, green IT helps in sustainability. Green It leads not only to corporate social responsibility but also better resource use and technological innovation.
http://www.greenit.net/
ISO 20000: ISO 20000 is an IT service management standard which integrates set of management processes to ensure the effective delivery of IT services to business and its customers.
http://www.isoiec20000certification.com/about/whatis.asp
ISO 27001: ISO 27001 (or ISO/IEC 27001:2005) is the specification for Information Security Management System which helps in establishing and maintaining an effective information management system.
http://www.27000.org/iso-27001.htm
ISO 38500: ISO 38500 is a corporate governance standard for IT. ISO 38500 defines six principles which helps establish responsibilities and plans to support company IT services.
http://searchcio.techtarget.in/news/article/0,289142,sid205_gci1370718,00.html
ITIL: Information Technology Infrastructure Library is a cohesive set of guidance which provides a systematic and professional approach for the best practice for IT service management.
http://www.itil-officialsite.com/AboutITIL/WhatisITIL.asp
ITPO: Information Technology performance optimization is concerned with extracting optimum performance from IT in broadest sense which covers hardware, software and IT infrastructure.
http://www.butlergroup.com/research/reportHomePages/ITPO.asp
Knowledge Management: Knowledge Management is a discipline that promotes organization to generate value from their intellectual and knowledge based assets.
http://www.cio.com/article/40343/Knowledge_Management_Definition_and_Solutions
MoR: Management of Risk offers general framework for the management of risk from different perspective on all part of an organization. All the activities needed to identify and control the risk is included.
http://www.apmgroup.co.uk/M_o_R/MoR_Home.asp
MSP: Managing Successful Programmes is a best practice guide on programme management which consists of set of principles and processes for managing programme. Although it can be used on different programmes, its main aim is for vision led programmes.
http://www.apmgroup.co.uk/MSP/MSPHome.asp
OPM3: Organizational Project Management Maturity Model is the project management maturity model that helps companies understands their project management process.
http://www.pmi.org/BusinessSolutions/Pages/OPM3.aspx
PCI DSS: Payment Card Industry data security standard (PCI DSS) is a security standard for enhancing payment account data security on a global basis. The information security requirement it created governs all the payment channels.
https://www.pcisecuritystandards.org/security_standards/pci_dss.shtml
PMBOK: Project Management Body of Knowledge is published by Project Management Institute which is accepted as best practice for project management. It provides fundamentals of project management applicable to wide range of projects.
http://www.projectsmart.co.uk/pmbok.html
PRINCE2: Projects IN Controlled Environments is a non-proprietary project management method which is used various companies to use it for different businesses, environments and project sizes. It helps drive the company through the fundamentals for running a successful project.
http://www.prince-officialsite.com/home/home.asp
Six Sigma: Six sigma is a data driven method for eliminating defects in any process for process improvement and variation reduction. It is a measure of quality and anything outside customer expectation is a six sigma defect.
http://www.isixsigma.com/sixsigma/six_sigma.asp
SOX: Sarbanes-Oxley guidance derived from COBIT creates controls to mitigate financial reporting risk. SOX is one of the main reason of emergence of the IT Governance concept.
http://www.amper.com/services/amper-risk-aicpa-IT-governance.asp
Strategic Plans: Strategic plans determines where an organization is going and how it is going to get there and helps organization to stay in sight with their ultimate objectives. Strategic plans provide the base for business plan.
http://managementhelp.org/plan_dec/str_plan/basics.htm
TCO/ROI: Total cost of ownership includes just cost whereas Return on investment measures both cost and the expected benefits of a given project over time.
http://www.cio.com/article/331763/TCO_versus_ROI
TOGAF: The Open Group Architecture Framework is a standard architecture framework consisting of detailed method and set of supporting tools which can be used by organization to develop IS architecture within them.
http://www.opengroup.org/togaf/
UCF: When organization starts gathering multiple authority documents of different types, they will need to know more information and organize them in certain way. The Unified Compliance Framework tracks authority documents in a very methodical way so that the information can be shared.
http://www.unifiedcompliance.com/webinars/Introduction%20to%20the%20UCF/player.html
Zachman Framework: Zachman Framework is a structure for describing the enterprise helping them collect, organize and structure their intellectual capital.
http://www.zachmaninternational.com/index.php/the-zachman-framework
The CALDER-MOIR IT Governance Framework
The CALDER-MOIR IT Governance Framework
http://pravab.blogspot.com.es/2010/04/calder-moir-it-governance-framework.html
Plan Estrategico
Ideas para hacer un Plan Estratégico de TI
http://calidadtic.blogspot.fr/
Repasando artículos interesantes en mi bandeja de entrada de Evernote, me he reencontrado con un artículo de Jerry Bishop en su blog blog.thehigheredcio.com. El artículo se titula 5 – S’s to IT Strategic Planning. Las 5 S se refieren a Strategic, Simplification, Service, Sustainability ySavings. La idea del artículo es articular un Plan Estratégico de TI entorno a estos 5 conceptos.
Resumiendo, os aconsejo que leáis el artículo, podemos decir que el Plan Estratégico debe articularse de la siguiente manera:
- Pensar en dos o tres iniciativas para ayudar a vuestra organización a alcanzar sus objetivos estratégicos. Estos pueden ser, entre otros, el crecimiento del negocio y la mejora de los márgenes o, como decía un financiero con el que trabajé, “simplemente” vender, facturar y cobrar.
- Pensar en cómo eliminar la complejidad y, en consecuencia, sus costes y falta de calidad asociados. En tanto que ofrecemos servicios de TI dicha complejidad puede estar presente en la tecnología, los procesos, las personas o incluso la relación con nuestros proveedores. En este punto, por tanto, podemos tener la tentación de disminuir drásticamente la complejidad asociada a la operación y gestión de nuestras TI, pero ojo con hacerlo a costa de perder totalmente el control de las mismas o de casarnos con alguien para luego acordarnos de lo bien que vivíamos solos.
- Pensar en dos o tres servicios a mejorar que, por supuesto, estén directamente relacionados con las iniciativas encaminadas a ayudar a los objetivos estratégicos de la empresa y en los que sea posible y adecuado aplicar medidas de simplificación (eliminación de la complejidad).
- Pensar en términos de sostenibilidad, es decir, en proyectos de continuidad y en proyectos asociados al Green IT.
- Por último, en base a las acciones planificadas de simplificación y sostenibilidad, estimar como pueden disminuir los costes asociados a mantener y operar las TI con el objetivo de asignar estos recursos económicos a los proyectos estratégicos. En este punto, el autor nos aconseja seguir el modelo run, grow and transform de Gartner. Por supuesto esta es la parte más compleja en tanto en cuanto hay departamentos de TI que, a estas alturas, ven comprometido el presupuesto operativo ya más que rebajado durante estos últimos años.
Cuando lo leí me pareció un artículo muy interesante porque establece de una manera clara, concisa y con sentido común el mapa básico sobre el que trabajar. Como se suele decir, si bien el mapa no es la ruta, si usamos un mapa erróneo o incompleto podemos acabar siguiendo el camino – siguiendo una moda, eligiendo el proyecto, implantando la solución, apostando por una tecnología…- equivocado.
domingo, 9 de junio de 2013
TOGAF-reality-check
http://togaf-reality-check.blogspot.dk/2013/06/the-togaf-limitations.html
Fail
Limitations
Let me state first: I am a TOGAF 9.1 practitioner and huge fan. TOGAF is without a doubt a very useful and powerful methodology. Meanwhile, I see an alarming growing tendency to except something from TOGAF 9.1 or trying to apply it in way without being aware of its limitations, hence the increasing amount of TOGAF 9.1 disappointment and project failures.
This article is intend to help practitioner to avoid the most common TOGAF 9.1 pitfalls and project failure, by elaborate on some of the key 24 limitations of TOGAF, as a domain centric approach. The following is an evolving set of limitations inherent in TOGAF 9.1. They are not necessarily reasons not to use TOGAF, but one should be well aware of them if you do.
TOGAF 9.1 limitations:
1. TOGAF is inconsistent within itself and is therefore not able to lead to a business which is consistent.
2. TOGAF is domain oriented, leading to loss of integration across the enterprise design and lacks the tools to demonstrate how the components of the business connect to the strategy to be executed.
3. TOGAF does not make the distinction between components, which are part of its framework, or those which are part of its method. The result is a loss of maturity, which is critical to success of organization in the early stages to adopting EA methods.
4. TOGAF is IT centric. It therefore miss specifies the problem, which is about optimizing the enterprise’s ability to deliver value and control costs in the execution of its strategy and not simply about the applications and processes that execute work.
5. TOGAF does not separate concerns between those that are related to analysis (decomposition) and those that are related to design (composition) resulting in a loss of traceability, within the work and increased expenditure of time and effort.
6. The TOGAF wheel discourages systems thinking needed to holistically address issues related to the total enterprise.
7. TOGAF modelling principles focus on narrow aspects of architecture practice rather than providing guidance to be used for innovation and transformation of the complete enterprise.
8. TOGAF does not demonstrate how the components of the business connect to the strategy to be executed, creating gaps between the strategy and the business model, revenue mode, service model, cost model and so on.
9. TOGAF lacks a coherent method for considering processes and process life cycles, thereby leading to processes being captured out of context, and in an inconsistent, and non-repeatable manner which lacks the tools to either ensure the completeness of processes or to eliminate processes which do not contribute value.
10. TOGAF lacks specifics on platform architecture or infrastructure architecture, leading to a lack of integration both between and across key aspects of application architecture, date architecture, Information Architecture and the specific technology architecture of platform and infrastructure architecture.
11. TOGAF treats service architecture as an isolated phenomena rather than an insight and design that can be applied consistently across the enterprise. Due to this lack key opportunities for improved ability to operate may be overlooked.
12. TOGAF sees the phasing for the development of architecture as being domain based, leading to fragmentation within the analysis and design.
13. TOGAF Change management is not enterprise centric but project centric.
14. TOGAF does not recognize the role of maturity in process, capability or competency and provides no linkage between maturity and organizational factors, limiting is ability to support transformation and innovation of the enterprise.
15. TOGAF governance focuses on the project/cycle perspective, ignoring the broader organizational concerns, hindering the ability for the organization to both mature and optimize itself.
16. TOGAF is lacking the design elements needed for continuous improvement.
17. While TOGAF provides a model for capturing motivation, it is not linked to tools to express the performance measurement aspects of the enterprise, creating gaps in understanding the influence of the area of an enterprises ability to execute.
18. TOGAF does not capture the full scope of business; i.e. value identification, value creation, and value realization, or service delivery; to create an integrated view of this aspect of the enterprise
19. TOGAF does not come with performance measures to demonstrate the business value of enterprise architecture, leaving it up to the each enterprise to reinvent itself and each practitioner to make the case for the value of EA.
20. TOGAF provides no guidance to practitioners on how to think about EA, work with EA concepts, and or tools to represent the results of analysis and design. This lack leads to chaos in its application as practitioners are each required to go through the costly and time consuming process of reinventing the necessary methods, practices and tools.
21. Industry specific patterns cannot be applied to the common TOGAF framework to provide reusable, connectable insight into best practices.
22. TOGAF requires tailoring without providing the tools to ensure the integration of the resulting frameworks, methods, and approaches This limits the ability for the results to be adopted, shared, and used
23. TOGAF does not separate conceptual, logical, and physical views across the viewpoints, leading both to confused thinking and to a requirement to significantly rework architecture descriptions when there are minor changes in the actual enterprise.
24. TOGAF does not treat the enterprise as a system and then use the thinking from this insight as the context for decomposition. This leads to sub optimization of components of the enterprise at the expense of its ability to deliver value and control cost
TOGAF is not based on open standard, but created solely by a closed community comprising only the paying TOGAF platinum members.
TOGAF does not recognize the relationship between business, which is where execution occurs; and applications, which is where execution is enabled, nor does it provide tools to understand how problems in business space can be addressed by a variety of solutions types in the application layer
TOGAF does not recognize that multiple type of enablers are available to strengthen business and therefore may effect business design. Concentrating on IT, TOGAF ignores how other capabilities may enable the business to act.
Cobit Videos
with Gary Hardy from IT Preneurs
http://www.youtube.com/watch?feature=endscreen&v=Ei3-1KgjARA&NR=1
http://www.youtube.com/watch?v=oMMyagRDOXo
Implementattion
viernes, 7 de junio de 2013
jueves, 6 de junio de 2013
Avoid the most common pitfalls in failed TOGAF 9.1 projects.
togaf projects sometimes fail.
http://togaf-reality-check.blogspot.dk/2013/06/the-togaf-limitations.html
Avoid the most common pitfalls in failed TOGAF 9.1 projects.
Research abstract by: Neil Kemp, Mark von Rosing, Arjan Visser and Henrik von Scheel.
Let me state first: I am a TOGAF 9.1 practitioner and huge fan. TOGAF is without a doubt a very useful and powerful methodology. Meanwhile, I see an alarming growing tendency to except something from TOGAF 9.1 or trying to apply it in way without being aware of its limitations, hence the increasing amount of TOGAF 9.1 disappointment and project failures.
This article is intend to help practitioner to avoid the most common TOGAF 9.1 pitfalls and project failure, by elaborate on some of the key 24 limitations of TOGAF, as a domain centric approach. The following is an evolving set of limitations inherent in TOGAF 9.1. They are not necessarily reasons not to use TOGAF, but one should be well aware of them if you do.
TOGAF 9.1 limitations:
1. TOGAF is inconsistent within itself and is therefore not able to lead to a business which is consistent.
2. TOGAF is domain oriented, leading to loss of integration across the enterprise design and lacks the tools to demonstrate how the components of the business connect to the strategy to be executed.
3. TOGAF does not make the distinction between components, which are part of its framework, or those which are part of its method. The result is a loss of maturity, which is critical to success of organization in the early stages to adopting EA methods.
4. TOGAF is IT centric. It therefore miss specifies the problem, which is about optimizing the enterprise’s ability to deliver value and control costs in the execution of its strategy and not simply about the applications and processes that execute work.
5. TOGAF does not separate concerns between those that are related to analysis (decomposition) and those that are related to design (composition) resulting in a loss of traceability, within the work and increased expenditure of time and effort.
6. The TOGAF wheel discourages systems thinking needed to holistically address issues related to the total enterprise.
7. TOGAF modelling principles focus on narrow aspects of architecture practice rather than providing guidance to be used for innovation and transformation of the complete enterprise.
8. TOGAF does not demonstrate how the components of the business connect to the strategy to be executed, creating gaps between the strategy and the business model, revenue mode, service model, cost model and so on.
9. TOGAF lacks a coherent method for considering processes and process life cycles, thereby leading to processes being captured out of context, and in an inconsistent, and non-repeatable manner which lacks the tools to either ensure the completeness of processes or to eliminate processes which do not contribute value.
10. TOGAF lacks specifics on platform architecture or infrastructure architecture, leading to a lack of integration both between and across key aspects of application architecture, date architecture, Information Architecture and the specific technology architecture of platform and infrastructure architecture.
11. TOGAF treats service architecture as an isolated phenomena rather than an insight and design that can be applied consistently across the enterprise. Due to this lack key opportunities for improved ability to operate may be overlooked.
12. TOGAF sees the phasing for the development of architecture as being domain based, leading to fragmentation within the analysis and design.
13. TOGAF Change management is not enterprise centric but project centric.
14. TOGAF does not recognize the role of maturity in process, capability or competency and provides no linkage between maturity and organizational factors, limiting is ability to support transformation and innovation of the enterprise.
15. TOGAF governance focuses on the project/cycle perspective, ignoring the broader organizational concerns, hindering the ability for the organization to both mature and optimize itself.
16. TOGAF is lacking the design elements needed for continuous improvement.
17. While TOGAF provides a model for capturing motivation, it is not linked to tools to express the performance measurement aspects of the enterprise, creating gaps in understanding the influence of the area of an enterprises ability to execute.
18. TOGAF does not capture the full scope of business; i.e. value identification, value creation, and value realization, or service delivery; to create an integrated view of this aspect of the enterprise
19. TOGAF does not come with performance measures to demonstrate the business value of enterprise architecture, leaving it up to the each enterprise to reinvent itself and each practitioner to make the case for the value of EA.
20. TOGAF provides no guidance to practitioners on how to think about EA, work with EA concepts, and or tools to represent the results of analysis and design. This lack leads to chaos in its application as practitioners are each required to go through the costly and time consuming process of reinventing the necessary methods, practices and tools.
21. Industry specific patterns cannot be applied to the common TOGAF framework to provide reusable, connectable insight into best practices.
22. TOGAF requires tailoring without providing the tools to ensure the integration of the resulting frameworks, methods, and approaches This limits the ability for the results to be adopted, shared, and used
23. TOGAF does not separate conceptual, logical, and physical views across the viewpoints, leading both to confused thinking and to a requirement to significantly rework architecture descriptions when there are minor changes in the actual enterprise.
24. TOGAF does not treat the enterprise as a system and then use the thinking from this insight as the context for decomposition. This leads to sub optimization of components of the enterprise at the expense of its ability to deliver value and control cost
TOGAF is not based on open standard, but created solely by a closed community comprising only the paying TOGAF platinum members.
TOGAF does not recognize the relationship between business, which is where execution occurs; and applications, which is where execution is enabled, nor does it provide tools to understand how problems in business space can be addressed by a variety of solutions types in the application layer
TOGAF does not recognize that multiple type of enablers are available to strengthen business and therefore may effect business design. Concentrating on IT, TOGAF ignores how other capabilities may enable the business to act.
miércoles, 5 de junio de 2013
TOGAF and Agile
http://goadingtheitgeek.blogspot.com.es/2012/04/togaf-luuuurvs-agile.html
http://agileea.wikidot.com/agile-ea-to-togaf-mapping
http://tetradianbooks.com/2008/04/silos/
http://tetradianbooks.com/2008/10/silos-method-ref/
http://www.agiledata.org/essays/enterpriseArchitecture.html
http://www.infoq.com/news/2011/06/agile-architecture-conflict
A practical set of EA deliverables
http://blogs.msdn.com/b/nickmalik/archive/2013/05/31/a-practical-set-of-ea-deliverables.aspx
A question on LinkedIn recently reminded me that, as the team leader for Segment Architecture in my former EA team, I was accountable for identifying a core set of deliverables for the team. The idea was that we could focus on defining standard formats and contents for these deliverables and, in doing so, we could start to measure both our output and our quality.
We only created pre-canned templates for a few of them. This is partly because the team was not mature enough in its practices to get consistency, and partly because Enterprise Architecture itself is not mature, or accepted, enough to have stakeholders that would notice if our deliverables meet an objective standard. Also this list is not intended to be comprehensive. The goal was to describe deliverables where it may possibly make sense to go for some level of consistency. Any EA could (and often did) create deliverables that were not on the list.
Perhaps it is time to share what we came up with.
Note that this list is the result of a single team doing its work, and is not representative of any “standards” effort across other EA groups. That said, I stand beside this list. I think it is a useful start. Note that many are technical in nature. I did not, in making this list, differentiate between BA and EITA deliverables. So if you are someone who believes that EA = BA + EITA, then you will see both sets of deliverables, intermixed, in the list below. If you are someone offended by the inclusion of technical architecture deliverables in an EA list… tough. I was working with reality.
Deliverable name
Why create it
Description
Architectural Point of View (or Technical Policy)
Provide clear input to Business or IT leadership on issues relevant to Enterprise Architecture
Short document describing a problem that requires attention and the opinion of EA for solving it.
Architectural Reference Model (or Architectural Pattern)
Provide clear input to IT project SMEs on optimal or preferable design options
Short document describing a set of concerns and a proven approach for addressing them
<Segment> Current State Model and Analysis
To demonstrate and communicate challenges inherent in current processes / systems / information
A collection of architectural models, including a context model, process models, and information models, as understood to currently exist , plus an analysis of issues and risks
<segment> Future State Vision and Model
To demonstrate the design of the future processes / systems / information needed by strategic intent.
A collection of architectural models that reflect a specific set of engineered changes
Governance Model and Analysis
Clarify roles and responsibilities and decision making processes for planning and oversight of initiatives
Process model, description of roles and responsibilities, and description of deliverables needed for planning, oversight and governance, along with implementation ROI and plans
M&A Business Case & Analysis
To provide a rationale for the acquisition of a company for the purpose of improving operational effectiveness. (M&A)
The document contains rationale including Competitive Analysis, SWOT / Twos analysis, and Strategic Alternatives Analysis
System Integration Recommendations Document
To set a vision for how key processes and systems shall be integrated into enterprise infrastructure (primarily M&A)
End to End business scenarios, Process and System Integration points, Risks and Issues for each integration concern, and an analysis of alternatives and recommendations
Value chain and operating model analysis
To clearly address gaps and strategic requirements for integrating or divesting a set of processes and/or systems (primarily M&A)
Target value chain and operating model for post-M&A future state. Mappings of key processes to or from the enterprise core diagram, and analysis of changes with the intent of composing key initiatives.
Enterprise Core Diagram
To clearly declare the processes and systems that are NOT core to the operations of the enterprise
A list of systems and processes mapped grouped into “ecosystems” that are clearly indicated as “core” and “edge” with analysis of governance
EARB Engagement Package
To demonstrate project level architectural quality to the EA Review Board
A pre-defined collection of project architectural models and artifacts.
Capability Model and Assessment
Provide clear basis for data collection for a segment
List of capabilities for a segment with assessment of capability maturity, etc.
Capability Gap Analysis
Highlight underperforming capabilities to focus investment
Map of capabilities needed by strategies, highlighting those needed investment, and listing relative and absolute program spend against each
<segment> Roadmap (a.k.a. Transition Plan)
To clarify the scope, timing, and dependencies between initiatives needed to deliver on a strategy
List of proposed initiatives and dependencies between them to deliver on strategic intent
Strategy Map and/or Balanced Scorecard
To clarify the strategies, goals, and objectives of a segment and allow for measurement and alignment
Categorized strategies, measures, and metrics for a specific timeframe and business scope
<segment> Process Model and Analysis
To clarify and build consensus on the business processes (as-is or to-be), and as input to process improvement / measurement
Models of processes, activities, information assets and system interaction points , and an analysis of opportunities to improve.
Enterprise Scenario and Analysis
To get clarity on the experience of a key stakeholder (often a customer or partner)
Textual and diagrammatic description of an experience, often with analysis to indicate opportunities
<segment> Information Model and Analysis
To improve understanding of requirements and the rationalization of design
Well-constructed information model, at one or more well-defined levels of abstraction, covering all aspects of a segment, aligned with EDM, along with an analysis of risks and issues
Platform Assessment
Capture ability of an app or platform to meet strategic needs
Collection of measurements, attributes, and mappings to an app or platform
Proof of Concept (POC) delivery
To create a design that demonstrates, and proves, an approach for solving difficult issues
A software deliverable and an architectural reference model (see above)
Record of Architectural Tradeoffs
To clearly communicate the tradeoffs made by architects on the customer’s behalf
Textual description of architectural decisions and the implications for the owner of the process / tool
TOGAF Case Studies
http://www.anywhere.cz/us/education/courses/enterprise-architecture/togaf-case-studies_aj.html
TOGAF Case Studies – EA Modeling
This advanced training follows the basic Enterprise Architecture training – TOGAF methodology and is aimed at those who want to broaden their knowledge even more.
You can try the TOGAF methodology ADM (Architecture Development Method), mainly the design phase, including all necessities as well as TOGAF inputs and analyses on the practical example simulating real architectonic project.
Topics:
- Initial ADM methodology revision
- Introduction of all phases with the detailed analysis of the recommended outputs including their prioritization and reusability
- Practical exercises involving modeling principles in individual areas of the enterprise architecture according to the ADM methodology:
- Business
- Business Footprint Diagrams
- Event Diagrams
- Functional Decomposition Diagrams
- Goal / Objective / Service Diagrams
- Organization Decomposition Diagrams
- Process Flows Diagrams
- Service / Information Diagrams
- Application
- Application & User Location Diagrams
- Application Communication Diagrams
- Application Migration Diagrams
- Enterprise Manageability Diagrams
- Process / System Realization Diagrams
- System UseCase Diagrams
- Information (Data)
- Class Diagrams
- Data Dissemination Diagrams
- Data Lifecycle Diagrams
- Data Migration Diagrams
- Data Security Diagrams
- Technology
- Environments & Locations Diagrams
- Network Computing Hardware Diagrams
- Processing Diagrams
- Business
Standardized outcomes in detail:
- Stakeholder map
- Capability Assessment
- Architecture Vision Design
- Solution Concept Diagrams
- Value Chain Diagrams
- Opportunities & Solutions --> Project Context Diagrams
- Architecture principles design
- Architecture artifact model examples
Requirements:
- TOGAF 9 basic methodology knowledge
- Advanced knowledge of English (training materials are in English)
Who Should Take Part:
- Enterprise Architect
- Solution Architect (Business, IT nebo Security Architect)
- Analysts, Designers
- Enterprise Architecture – TOGAF methodology training graduates
martes, 4 de junio de 2013
8 Reasons Enterprise Architecture Programs Fail
If you want to build a ship, don’t drum up people to collect wood and don’t assign them tasks and work, but rather teach them to long for the endless immensity of the sea." -- Antoine de Saint-Exupery
Enterprise architecture was conceived some 25 years ago to address the increasing complexity of IT systems and their poor alignment with business goals. The same problems still exist today, amplified by the accelerating pace of technology change.
MORE GLOBAL CIO INSIGHTS
Webcasts
- The Untapped Potential of Mobile Apps for Commercial Customers
- The Intelligent WAN: How to Keep Your Network from Becoming the New Weak Link
White Papers
- Effectively Controlling IT Change
- CA Interactive IT Executive Series: Application Lifecycle Management Part 2
Reports
More >>Why is it that EA programs are more likely to fail than succeed? Here are eight typical failure modes, followed by recommendations on how to avoid them.
1. Lack Of Sponsorship.
Your architects need three tools to do a good job: access, leverage and goodies.
[ Change your life or career or both with better decisions. Read 7 Ways To Improve Your Decision Making. ]
Access means the ability to interact with the appropriate stakeholders, often at the C-level.
Leverage includes the right place in the reporting chain, involvement in governance, ability to influence the technology budget, and authority to stop inappropriate technology implementations. Sometimes even the seemingly small change of a title from technical architect to chief enterprise architect can make a significant difference.
Goodies include the ability to give out new technologies for testing, "lend" technology experts to struggling projects, and get access to exclusive information that can be traded for favors.
Global CIOs: A Site Just For You
Visit InformationWeek's Global CIO -- our online community and information resource for CIOs operating in the global economy.
Well-sponsored architects will be able to build trust by consistently delivering meaningful results. Lack of sponsorship will destine even the best architects to fail.
2. Hiring Or Promoting The Wrong Person.
The skills that earn someone the EA position don't necessarily make the person a strong EA. Often the most technical people get promoted when they lack other important skills. These include interest in the business, the ability to translate technology into simple business outcomes, and the ability to listen, communicate, present and market infectious enthusiasm for new technologies.
3. Building An Ivory Tower.
Some EA programs hire a bunch of brilliant architects who retreat for a long time and return with sophisticated frameworks. They then present them to key members of the leadership and the organization, most of whom will have no clue what the architects are talking about, so their complex reference architectures will be ignored.
Ivory towers tend to increase the complexity and upset the stakeholders. The new CIO will gain immediate recognition among his business partners by firing the EA team, with the result that enterprise architecture becomes a "bad word" deeply embedded in the institutional memory. Roger Sessions wrote a great white paper on driving simplicity through connected enterprise architecture.
4. Policing And Insensitivity To Culture.
I have seen a project manager burst into tears in the crossfire of enterprise architects' questions during a technical design review. I have been on a 2 a.m. call struggling to comply with unreasonable and obsolete technology standards just to get the chief architect's signature and meet the budget deadline.
In that particular case, the turning of enterprise architecture into a policing function resulted in its failure. It takes a lot of effort to convince, and regularly re-convince, your business and IT partners of the value of enterprise architecture. A gentle approach makes the function more likely to succeed. The best architects I've known spoke softly and carried a really big carrot. They followed Exupery's advice.
5. Maintaining The EA Artifact Factory.
Some EA teams keep busy documenting as-is states. They have an incredible array of diagrams at their disposal to represent the various aspects of everything. The world of diagrams is addictive, and perfect is the enemy of good when it comes to diagrams.
Instead, these teams should focus on producing frequent, meaningful and measureable business outcomes.
It isn't easy to come up with good KPIs to measure enterprise architecture. This GAO report clearly shows the challenges of defining good EA metrics in the government sector.
6. Clinging To A Particular Framework Or Tool.
There are more than 80 EA frameworks, and you'll find no silver bullets among them. The best approach is to read all of the major frameworks, discard most of what you have learned, and blend the remaining 10% in a way that fits your organization's culture, maturity and business goals. As an example, here's alightweight, blended approach for tree huggers. When it comes to tools, go fancy if you have the money. But most of the time fancy isn't necessary. Visio, Excel, Word, FreeMind, Prezi and a collaboration team site works well. Limit the time spent on selecting tools and frameworks and instead focus on using them.
7. Thinking Enterprise Architecture Equals Technology Architecture.
Most EA programs are initiated by IT and never progress beyond the technology domain. Although technology standards, technology roadmaps and solid engineering practices will produce simpler, cheaper, portable, reusable and more supportable solutions, they don't align your IT investments with business goals and won't power your business with technology innovation.
8. Taking The "Enterprise" Word Literally.
"Enterprise" does notnecessarily mean the entire enterprise. It means stepping back and taking a look at the higher-level context before making a decision. Moving architecture to the real enterprise level requires a mature and committed organization. If you try to push the enterprise aspect too far too early, you'll crash and burn. Mike Rollings of the Burton Group has a great article on this subject
Recommendations:
-- For the sponsor of the EA function: Make sure that your organization is ready for an architecture-driven approach and that the EA function is well sponsored. When you interview EA candidates, ask about the failure modes of the function. Keep looking if the person doesn't know the usual failure modes by heart.
--For the EA: When you interview for a new position, make sure you have what it takes to do a good job. Take into account your own abilities, the company culture, the level of organizational maturity and the level of sponsorship. If you're uncertain, walk away. Life is too short to spend years making no difference.
Two tech experts square off. A CIO compares working without IT standards to anarchy, while a CTO claims that standardization stalls creativity. Also in the new, all-digital The Standardization Debate issue of Network Computing: Next-gen data centers and the politics of standards. (Free registration required.)
Suscribirse a:
Entradas (Atom)