Additional Blogs by Members
cancel
Showing results for 
Search instead for 
Did you mean: 
Former Member
0 Kudos
I already talked about the need for enterprise architecture and why SAP is concerned about enterprise architecture ( Why SAP cares about enterprise architecture ). This post is the first of a series to put some light on what SAP is doing in the enterprise architecture field. To help our customers to use enterprise architecture successfully the first task that we dealt with was creating an enterprise architecture framework. Such a framework should help our customers and partners to adopt enterprise SOA. We have three main principles that we adopt as we start our work A) we don’t want to reinvent the wheel. B) we want our framework to fully support SOA and C) the framework needs to be agile enough to support both long term strategic work as well as short term tactical solving pain point work. The framework agility was very important from my perspective. This is one of the main lessons that I’ve learned while doing enterprise architecture work. If you want to lead successful enterprise architecture you better be more practical and connected to real life reality. You had better lead sets of enterprise architecture work with tangible value every couple of months rather then climbing to the ivory tower for a year, or more, and then coming down with the bible in you hand. I even tend to see successful enterprise architecture as a collection of work that solves tactical pain points, but the work is being done in such a way and using tools that will help the enterprise to get a holistic view. Starting from point A we looked for an existing enterprise architecture framework. We need to be based on a framework that is practical enough, not industry specific and known (and used) as much as possible. Those criteria didn’t leave us too much room for choices and we were left with TOGAF as the optimal opportunity. Moving to point B, we started to define what SOA artifacts and methodologies we expect from enterprise architecture work to deliver. With those conclusions we start to identify gaps in TOGAF and start to deal with those gaps by defining new building blocks, views and methodologies. Point C causes us to make some serious modifications to TOGAF in order to make it a more agile framework. We want our framework to enable enterprise architects to start from each one of the enterprise domains (business, information, application and technology) rather then the traditional layered way. Beside those three principles we also defined dedicated building blocks, views and methodologies to the information domain. We believe that information is the bridge between business and IT. The business uses information and IT manages it, therefore there’s a common language for both of those parties. We are using the information world to identify enterprise level services and their granularity level. As SAP framework, we want to enrich the framework with our knowledge and experience in so many industries. The term that we’re using for this purpose is style. An enterprise architecture style is a collection of building blocks and views that will resemble the current situation of a typical enterprise in industry and the suggested to-be architecture of such an enterprise. Enterprise architecture styles will enable enterprise architects to start their work not from a white paper but with a collection of building blocks and views (or set of blueprints). A style will make the work of enterprise architects easier and faster. In this post I tried to outline on what structure our framework is based on and what are the modifications that we’ve made. Next post will describe a high level overview of the framework. Natty Gur.
2 Comments