Skip to Content
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). image 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.
To report this post you need to login first.

1 Comment

You must be Logged on to comment or reply to a post.

  1. David Halitsky
    Natan –

    Pre-ES(O)A, SAP clients couldn’t do anything about gaps except:

    1) live with them (i.e. do business like SAP wantt them to);

    2) negotiate with SAP for SAP-delivered enhancements;

    3) if SAP is not forthcoming on enhancements, decide what enhancements/mods will be required.

    But post-ES(O)A, it is precisely the “gaps” which may provide important clues to how ES(O)A services can be combined to close gaps.

    In particular, if a client really has a “better” way of doing things that cannot be implemented in the standard set of SAP transactions, then it is quite likely that the client’s process can be implemented using a combo of services made possible via NW/ES(O)A, etc.

    I know that you know this already, but I thought it was important to point this out, in case it hadn’t occurred to some people.



Leave a Reply