Recommended
Recommended
More Related Content
Recently uploaded
Recently uploaded (20)
Featured
Featured (20)
PEAF Modelling Overview
- 1. Modelling & Processes – The Basics
- 2. How does Modelling relate to Models and the Tasks involved in dealing with change... From Strategy to Execution...
- 3. The Basics
- 4. The Basics
- 5. The Basics
- 6. The Basics
- 7. The Basics
- 8. The Basics
- 9. The Basics
- 10. The Basics
- 11. The Basics
- 12. The Basics
- 13. The Basics
- 14. The Basics
- 15. The Basics
- 16. The Basics
- 17. The Basics
- 18. The Basics
- 19. The Basics
- 20. The Basics
- 21. The Basics
- 22. 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.
- Modelling change at any level, be it strategy, planning, logical or physical consists of the same general approach to using the models. We start with a process. That process could be strategic planning, physical design or anything in between.
- The Process... ...uses the higher level CONTEXT which defines the scope and context of the thing in question... (the problem)
- The Process... ...needs to determine the TARGET (aka the solution)...
- However, in order to do that, the PROCESS must first consider and understand the CURRENT in order to decide what to change and how. There is one more important level that needs to be considered...
- We must not forget to consider the TARGET in light of the IMPACT on the level of information below the level we are considering. This basic pattern is the pattern for doing architecture at any level.
- Using this basic pattern we can show how we move from the strategic intent to change the physical changed world. From Strategy to Execution First we consider change planning. The Contextual Model contains information about the Organisations Mission, Vision, Goals and Objectives. The Target Contextual Model is an updated Enterprise Strategy based on the Market and the wider Enterprise. However, to determine the Target Strategy we must also consider two things...
- Firstly we must consider the Current Enterprise Strategy.
- Secondly, we need to understand the IMPACT of our new Target Enterprise Strategy. The Conceptual Model is a model of the whole enterprise at the conceptual level. If we do not consider the impact on the Structural Model on the Conceptual Model, we may be defining a strategy that cannot be executed in the time and resources available or cannot be executed at all.
- The next level of Change Planning is to consider what our Target Conceptual Model needs to be in order to support and enable the Enterprise Strategy. In order to do this, we must consider the Current Conceptual Model but also assess the impact on the Current Logical Model.
- In addition, planning also creates the Change Model which consists of the projects and programmes required to move the organisation from the Current Conceptual Model to the Target Conceptual Model over time in a way that achieves the Objectives set in the Contextual (Enterprise Strategy) Model. Let’s look at that change model in a little more detail...
- Hear we can see the Current and Target Structural models. In between them are the Business and Technology Objectives from the Enterprise Strategy Model (Conceptual Model) At each Objective we have an Intermediate Model. And overlaid on those are the programmes and projects that are required to make the transition from one state to the next.
- Each project consists of a proportion of Business change (processes, roles, locations etc) and a proportion of Technology change (Applications, Databases, etc) The wavy line indicates the separation but intimate coupling between the two. In this way we are defining a strategy for change, in terms of Business things and in terms of Technology things.
- We are, in fact, defining a Business change Strategy and a Technology change Strategy. Many organisations use the words “Business Strategy” to refer to what PEAF refers to as the Enterprise Strategy. This is one of the many confusions since if we call the higher level “Business Strategy,” but still refer to the bottom area on the diagram as Technology or IT Strategy, what do we call the upper blue area?
- Now we are in the realm of change projects. The first level of which is to produce a Target Logical Model for the problem domain defined by the Change and Conceptual Models for this project. As before this is done by considering the Current Logical Model and the impact on the Current Physical Model.
- Physical design follows the same pattern... Producing a Target Physical Model for the problem domain defined by the Change and Conceptual Models for this project. While considering the impact on the Current Operational Model.
- Build/Buy, Test & Deploy now make flesh the physical designs and makes the transition into Stuff running live in the real world. Now the project has finished, the Target state domains are fed back into the Current Model to represent the changed current state.
- Of course this repeats for all the other projects in the change portfolio.
- This is another way of seeing the transitions