In my previous post (What SAP is doing in the enterprise architecture field (Part 2) ?), I depicted how our enterprise architecture is structured and the main components which compose the framework. This post is dedicated to a high level overview on the Architecture Development Cycle (ADC). Our ADC is made out of three main steps: Define, plan and governance. We added to the figure the build and run phases just to show that we support the entire IT cycle and due to the fact that there are some relations between governance and the build and run phases. The first phase is define, which starts with two steps that won’t take place each time you’re doing enterprise architecture work. The first step, which takes place just once, is the preliminary phase. The preliminary phase is all about aligning the framework to the enterprise and existing framework that already being used in the enterprise. The second step is the vision, which takes place every time you’ll have new enterprise architecture work request. This step is about breaking the EA work to smaller chunk of work with predefined business values as outcome and Statement Of Work (SOW) to guide the EA work. Enterprise architecture definition work is split into four main steps: modeling “as-is”, analyzing “as-is”, modeling “to-be” and identify gaps for each one of the four domains. From methodology perspective our framework enables you to start your work from each one of those domains, or to focus your work on one domain. We’ll address this kind of agile way of working latter on (future blog posts). While modeling the domains we actually populate new building blocks and relations to the repository. After having the “as-is” architecture we analyze it to find any kind of problem that needs to be addressed by architects. Equipped with the analysis results we start to model the “to-be” situation, which should solve the identified problems. After having the “as-is” and the “to-be” architectures it’s time to identify what are the gaps between those two architectures. With the gaps we start the plan phase. The first step is to find out what are all the available opportunities to close each one of the identified gaps. After having the available opportunities we use the business principles, constraints to decide which one of those opportunities will be our chosen solution. The second step is to take all the chosen solution and to migrate them into time-lines projects that needed to be done to close the gaps. The last phase is governance, which is split into three main steps. First we want to make sure that our decisions in the define and plan phase are taking place in reality (build and run phase). To govern we have a governance methodology to help you with establishing your enterprise architecture in reality. The second step is monitoring. We want to monitor our build and run phases to make sure that the current and known future business and IT reality (existing and emerging direction and technology) is still been supported by the last version of our architecture. If we find out that the framework is not up-to-date you need to go through a new EA cycle. The third step is management of requirements, risks and security. I hope that I have managed to give a high level overview of the framework development cycle. In my next post I’ll focus on the framework repository component. Natty Gur.