AE Rio 2011 - PEAF - Pragmatic Enterprise Architecture Framework - Kevin Smith
•Download as PPT, PDF•
3 likes•1,286 views
Framework PEAF e Enterprise Debt
![Agenda ,[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommended
Recommended
More Related Content
What's hot
What's hot (11)
Viewers also liked
Similar to AE Rio 2011 - PEAF - Pragmatic Enterprise Architecture Framework - Kevin Smith
Similar to AE Rio 2011 - PEAF - Pragmatic Enterprise Architecture Framework - Kevin Smith (20)
More from Fernando Botafogo
More from Fernando Botafogo (20)
Recently uploaded
Recently uploaded (20)
AE Rio 2011 - PEAF - Pragmatic Enterprise Architecture Framework - Kevin Smith
- 3. Context How does PEAF relate to other frameworks?
- 8. Composition What is the structure of PEAF? What is it composed of and what are the parts for?
- 9. PEAF - Composition
- 10. PEAF - Products
- 11. PEAF – Processes - Phases
- 12. PEAF - Products
- 13. PEAF – Products - Foundation
- 14. PEAF – Products - Culture
- 15. PEAF – Products - Model
- 16. PEAF – Products - Governance
- 17. PEAF - Processes
- 18. PEAF – Processes – Prepare Phase
- 19. PEAF – Processes - Prepare
- 20. PEAF – Processes – Implement Phase
- 21. PEAF – Processes - Implement
- 22. PEAF – Processes - Implement
- 23. PEAF – Processes - Implement
- 24. PEAF – Processes - Implement
- 25. PEAF – Processes - Implement
- 26. PEAF – Processes - Implement
- 27. PEAF – Processes – Operate Phase
- 28. PEAF – Processes - Operate
- 29. PEAF – Processes - Operate
- 30. PEAF – Processes - Operate
- 31. PEAF – Processes - Operate
- 32. PEAF – Processes - Operate
- 34. Licensing What types of licenses are available to use PEAF?
- 36. Certification What types are available? What are the benefits?
- 38. PEAF – Certification – Individuals - Roadmap
- 40. PEAF – Certification – Organisations - Roadmap
- 42. Training What Training is available? How is Training provided?
- 44. PEAF – Training - Courses
- 45. EA Express
- 46. EA Essentials
- 49. To find out more, please visit us at www.PragmaticEA.com Cutting EA to the bone © Pragmatic EA Ltd
- 50. EA – Enterprise Debt
- 51. What is Technical Debt?
- 53. What is Enterprise Debt?
- 54. Enterprise Debt – Perfect World vs Real World
- 55. Enterprise Debt – The Pragmatic World
- 56. Enterprise Debt – The Pragmatic World
- 57. Enterprise Debt – The Pragmatic World
- 58. Enterprise Debt – The Pragmatic World
- 59. Enterprise Debt – The Pragmatic World
- 60. Enterprise Debt – The Pragmatic World
- 62. What is the Enterprise Debt and investment profile of organisations that do not utilise Enterprise Architecture?
- 64. What is the Enterprise Debt and investment profile of organisations that do successfully utilise Enterprise Architecture?
- 75. To find out more, please visit us at www.PragmaticEA.com Cutting EA to the bone © Pragmatic EA Ltd
Editor's Notes
- Enterprise Architecture is probably one of, if not he the most, misunderstood terms in the business and IT world today. Most people have a definition for it - The problem is, a lot of those definitions are either incomplete or just plain wrong. I know because I used to be one of those people. It has become clear to me that Enterprise Architecture is not complicated, is not difficult, is not expensive. Of course there are elements out there who would prefer boards and organisations to think that it is complicated, is difficult and therefore is expensive. That is not to say that Enterprise Architecture does not have its issues problems and risks. However, so long as the key tenet’s are understood and the issues, problems and risks are managed, any organisation can instigate and reap the benefits of Enterprise Architecture.
- The framework splits into 5 main areas: - Foundation The foundation provides the starting point for initiating all other EA work. Communication Communication is the key to EA. Without it, everything else is superfluous. Model The main artefact of EA are the models which allow information to be gathered, viewed and analysed. Governance Providing an environment to guide change as it happens throughout the organisation. Management Providing the process to manage the work and measure success
- The framework splits into 5 main areas: - Foundation The foundation provides the starting point for initiating all other EA work. Communication Communication is the key to EA. Without it, everything else is superfluous. Model The main artefact of EA are the models which allow information to be gathered, viewed and analysed. Governance Providing an environment to guide change as it happens throughout the organisation. Management Providing the process to manage the work and measure success
- The Foundation section of PEAF covers the artifacts that are required to instigate and gain approval for an EA programme of work. Using these as a starting point allows a rapid definition and proposal to be formulated. Once formulated, the board can quickly decide whether to pursue an EA initiative or not.
- The Culture section of PEAF covers the people aspects of Enterprise Architecture. These products, coupled with the preparation work in the “Implementation” phase and the provision of training and education in the “Operate” phase, are the most important of all the products. It is also the hardest to get right and the easiest to overlook, which is why so many EA initiatives fail.
- The Model section of PEAF covers the main artefact of an EA initiative - the EA Model. The EA Model is the bedrock of EA. While people are the key to its success, the EA Model forms the backbone of an EA imitative as it is the main repository of information about the organisation, its objectives, Goals, Targets and Strategies. The model is not meant to be used by an elite group of individuals. The more people use it, and the more people contribute to it the more benefit the organisation will attain.
- The Governance section of PEAF covers the quality control which makes sure that either agreed principles, policies and standards are being followed, or, if not, that the impacts, risks and implications of not doing so are costed, understood, accepted and managed. A key point regarding governance is that it should not be viewed as a policing environment where things are rejected and accepted or that penalties are incurred for breaking the rules. The approach must be culture based, with the organisation (business and IS) understanding the reasons behind the principles, policies and standards existing and how they contribute to move the organisation from where it is to where it want s to be.
- Provides your current and future employers with the confidence that you have reached a certifiable standard of understanding and the ability to be able to fully utilise PEAF. The process of achieving and maintaining Certification also helps ensure that you are continually improving and refining your skills. Advocate - Issued to individuals who have demonstrated a broad understanding of Enterprise Architecture. Practitioner - Issued to individuals who have demonstrated a broad knowledge of Enterprise Architecture and a high level understanding of how PEAF enables and supports its adoption. Professional - Issued to individuals who have demonstrated a detailed knowledge of PEAF and how to apply it within their organisation Consultant - Issued to individuals who have attended a PEAF Certified Consultant training course and have demonstrated their ability to apply and utilise PEAF for the benefit of End-User Organisations and Government Bodies. Trainer - Issued to individuals who have attended a PEAF Certified Trainer training course and have demonstrated their ability to provide training to individuals and organisations.
- Provides you with competitive advantage and widens market opportunities. It demonstrates to your customers that you can be trusted to deliver products and services based on PEAF. Enterprise - Issued to End-User Companies, Government Bodies and Academic Institutions who have demonstrated their commitment to and use of PEAF within their enterprise. Consultancy - Issued to companies who have demonstrated their ability to provide PEAF consulting services. Training Provider - Issued to companies who have demonstrated their ability to provide PEAF training services. Tool Vendor - Issued to companies who have demonstrated that their tool conforms to, and supports the Pragmatic EA Framework and the PEAF Metamodel out of the box.
- All answers are written, there is no multiple choice. Certification questions do not seek to find out if the delegate can remember the whole of PEAF, but more to see if they understand the culture, ethos and thinking behind a Pragmatic approach to Enterprise Architecture Certification examinations are normally held with the trainer at the end of a designated course, although exams can be taking by individuals at a certified testing centre. If an exam is taken as part of a training course and a delegate does not pass an exam, the delegate is entitled to re-sit the test without paying another examination fee to Pragmatic EA Ltd. However, the Certified Training Provider or Certified Testing Centre may charge a small fee for administration.
- Enterprise Architecture is probably one of, if not he the most, misunderstood terms in the business and IT world today. Most people have a definition for it - The problem is, a lot of those definitions are either incomplete or just plain wrong. I know because I used to be one of those people. It has become clear to me that Enterprise Architecture is not complicated, is not difficult, is not expensive. Of course there are elements out there who would prefer boards and organisations to think that it is complicated, is difficult and therefore is expensive. That is not to say that Enterprise Architecture does not have its issues problems and risks. However, so long as the key tenet’s are understood and the issues, problems and risks are managed, any organisation can instigate and reap the benefits of Enterprise Architecture.
- The concept of Enterprise Debt is based on a concept called Technical Debt. Whereas Technical Debt only applies to IT and technology, Enterprise Debt applies to everything in the Enterprise not just IT.
- Has anyone heard of the term “Technical Debt”? Electing to implement a quick solution with dirty code can sometimes be the right thing to do. What's important is to realise that it incurs debt which, like financial debt, requires repayment by returning at a later date to refactor the dirty code. Until it is repaid, interest is due and must be paid in the form of: - increased cost to maintain it. increased cost because what could have been reusable, is not reusable.
- THE PERFECT WORLD Costs here refer to money,, time and people combined. The “Required Budget” represents the budget that is required to do the project/change properly. In the perfect world, the ”Assigned Budget” equals the Required Budget. But that never happens right? THE REAL WORLD Again, the “Required Budget” represents the cost that is required to do the project/change properly. But in the real world the ”Assigned Budget” (don’t forget costs here are time, people and money) is restricted. This restriction may be valid but in a lot of organisations its really just arbitrary. In a lot of companies this restriction is imposed by the business on the project manager who’s job it is not to break it. In the real world, that’s the end of the story the restriction is imposed the project “finishes” the PM gets a big green tick. But that’s not the end of the story ….
- In the pragmatic world, things start off the same as in the real world. Again, The ”Required Budget” represents the cost that is required to do the project/change properly. The ”Assigned Budget” (don’t forget costs here are time, people and money) is restricted.
- However, in the pragmatic world we recognise that this creates project Debt This project debt, is what it would cost, to do the work required to bring the solution up to the same standard as would have been produced if the Assigned Budget had been the same as the Required Budget. Notice how this debt is bigger than the difference between the Project Cost, and the Project Spend. This is because it will always cost more to do something one way and then change it to another than it would have cost to just do it right the first time….. “ There is never time to do it right, but there is always time to do it over ”…and over…and over…
- This project debt add’s to any existing Enterprise Debt. Enterprise Debt is measured in the money, people, and time that would be required to pay off the debt.
- This Enterprise Debt, like financial debt, it has to be serviced in the form of interest payments. This interest payment can be expressed as increased support costs. Like interest payments on a loan, this is a recurring cost and will continue for as long as the Enterprise Debt it is servicing exists.
- If the solution (Business and/or Technical) now needs to be changed, enhanced or upgraded, there will likely be an increased cost to effect that change. Because this change is based on an original less than optimal solution (because the Assigned Budget did not match the Required Budget) this change is likely to introduce more Enterprise Debt into the organisation which in turn will required even more cost to support - notice it has got bigger But things could get even worse…. This change requires a budget. If the Assigned Budget for this change does not equal the Required Budget for this change we are introducing even more Enterprise Debt into the organisation. A double whammy!
- However, if, either it is recognised that we need to do some remedial work, or, more likely things just get so bad the organisation has no choice but to do some remedial work, this effectively reduced Enterprise Debt in the Organisation
- Enterprise Debt takes this concept and applies it to the entire organisation including the business. For example Enterprise Debt is also being incurred when a Business Manager changes a business process in a less than elegant way in order to solve an immediate problem because he doesn’t have time to go a proper analysis of the problem and consider the different solutions – certainly not if it involves IT!!!!! This Debt is easily hidden but can surface in many ways as shown here. This doesn’t mean that we should eradicate all debt. As in finance, debt can be a good thing. For example 99% of us are in debt to some degree or other, Mortgage, Car loans, credit cards, etc. Debt allows us, and business to achieve things they wouldn’t normally be able to achieve usually in a shorter timeframe than would otherwise be possible Debt is only a bad thing when a) you don’t even realise you are incurring it, b) you don’t know how you will pay off the debt, c) you don’t know the interest rate, d) you don’t know how long you will have to pay interest for, or e) all of the above.
- This diagram illustrates the investment/cost profile of an organisation that does not utilise Enterprise Architecture. The level of investment rises, but very slowly, while everyone pats themselves on the back. During this time hidden Enterprise Debt is slowly building up… When then debt reaches a critical point, a very large investment over a short timeframe is required to move the organisation forward. Often this is called “getting the car out of the ditch”. It’s focus is usually very short term. Having spent a large amount of money over a very short timeframe the focus then is to reduce costs and expenditure and therefore we return to the low level of investment we saw before and the whole process repeats its self. These points in the graph can often be aligned to when CIO’s arrive and depart!.... Does anyone recognise this trait?
- This diagram illustrates the investment/cost profile of an organisation that does utilise Enterprise Architecture. The level of investment rises more steeply than before. Enterprise debt does build up but this debt is identified and managed and does not get as large as before. When then debt reaches a critical point (lower than before), an increased investment is required (but not as large as before) but this investment is also aligned to longer term goals. The again, we return to a more moderate level of investment (higher than before) and the whole process repeats its self. These points in the graph can often be aligned to when CIO’s make strategic decisions.
- Utilising Enterprise Architecture relieves the boom and bust investment cycle. The downside is that it requires an increased initial investment. However, this increased initial investment in Enterprise Architecture allows lower investment over time and prevents Enterprise Debt from spiraling out of control. Frightening isn’t it? But, unfortunately there is something that is even more frightening…..Where will it all end?.........
- Enterprise Debt is actually a strategic tool that can be used to effectively manage an organisation. Enterprise Debt can literally save an organisation from possible collapse.
- 1. Enterprise Debt Value (EDV) The current overall Enterprise Debt currently existing in the Enterprise 2. Enterprise Debt Ratio (EDR) The ratio of work in the currently executing project portfolio that will either increase or decrease EDV when those projects complete.
- Actually, it is already hitting many company's balance sheets in the form of increased maintenance costs. It’s just that at the moment, this cost is hidden. Most companies are already dividing IT into base and initiative budgets. The annual gain in base budget is, in effect, the interest due on the current debt.
- A is where we are. B is where the organisation has decidedly strategically it wants to go. c is a short term objective All work/change carried out on projects can be categorized as a ratio between :- Strategic: A change that takes you directly from where you are to where you want to be, that may or may not also satisfy a short term need. Interim: A change that satisfies a short term need, but does not take you from where you are to where you want to be in the best way. Remedial: A change that corrects previous Interim change. This remedial change will also consist of Strategic and Interim change.
- All projects have a Business and a Technical change component. The Enterprise Debt Ratio for each can be very different. e.g. The BEDR of a project may be 90:10:0, whereas the TEDR of the same project may be 10:30:60.