ASAP is dead! Long live ASAP!
Due to just remarks made about the previous version of this blog, I would like to clear up some things that I had not made clear so far.
I have been working on the role of architecture in SAP environments for some 4 years now. Gradually it became clear to me that classic SAP implementation approaches, like Accelerated SAP, show some deficiencies when it comes to implementing eSOA type SAP. So, early 2007, when working on the development of SAP EAF together with SAP employees the idea was born to develop a new version of AcceleratedSAP, codenamed ArchitectedSAP. This development is currently running. Not full-time, but steadily. It integrates expertise from a range of areas from my own background and those of my Capgemini colleagues: SAP functionality, business analysis, enterprise and solution architecture, service-orientation, classic ASAP, project management, business change, Netweaver, technology infrastructure and more. Mendel Koerts, a colleague of mine and me, we are leading this effort.
The text below is from the Capgemini CTO blog. A few days ago, it was published to bring the subject to the attention of a larger public:
(http://www.capgemini.com/ctoblog/2008/07/asap_is_dead_long_live_asap.php)
ASAP is dead! Long live ASAP!
Since this title obviously caught your attention you are most likely familiar with AcceleratedSAP, the good old methodology for implementing and upgrading classical SAP solutions. In spite of the title, ASAP Roadmaps, like those for implementing ERP, are still living happily in the SAP Solution Manager 7.0 product. True. But the point is this. Having worked with various clients over recent years on adopting and taking advantage of services-based SAP solutions, it became evident that as-is ASAP is not by far sufficient as a robust approach for services-based SAP projects. With the irreversibly rise of ‘thinking services', it is time to declare ASAP dead and to coronet the new ASAP: ArchitectedSAP.
Pretty self-explanatory name, I guess. ArchitectedSAP is a fusion of the architecture profession and the SAP world. It simply makes a broad range of architecting techniques instrumental to guiding the happy few that master SAP services configuration. Helping you to navigate from strategic intent to delivered SAP solutions, regardless of their nature: be it a classical one, services-based or a mixture of those. ArchitectedSAP encourages deploying the services-aware SAP Enterprise Architecture Framework (SAP EAF) to its full extent to allow addressing both business and IT change in an integrated way (guess what the source for the SAP EAF was...). Another architecting goodie adopted in ArchitectedSAP are the architecting processes from the TOGAF Architecture Development Method (ADM), each process complemented with services-based SAP specific merits.
Etc.
Read the complete story at Capgemini's CTO blog
Obviously people were annoyed because the link to the CTO blog wasn't mentioned in the previous blog. I regret that. For me this felt OK, because I am one of the founding fathers of this initiative. But, point is taken.
The reason for posting the orginal blog is that I am very interested in what the experiences are within the community on this subject. Have organizations adapted their implementation approaches now we have eSOA type SAP implementations? How do we implement hybrid solutions: classic SAP and eSOA SAP combined? What are requirements for such an approach?
I want to invite you to share your experiences and ideas. I will be happy to post parts of the book on this subject (that is currently being written) in this community. In fact I already did. See my previous blogs. At the moment I am only wondering what is the best way to do so. Ideas on this are welcomed as well.
Best regards,
Lucas Osse.
