My colleague Mendel Koerts has been publishing guest blog-items on SAP BMP / eSOA and the SAP TechEd before and it is with great pleasure that I give him the stage again. Yep, you guessed it, it’s about SAP. But not the SAP as we know it. I happen to watch Mendel working on an important book about ‘Architected SAP’. Consider the following item by Mendel as a prelude, and follow this blog for more news soon.
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.

But ArchitectedSAP goes way beyond the abstraction level traditional enterprise architects tend to stop at. It outlines directives-driven SAP solution architecting, or high-level solution designing if you wish, and tells you what SAP-specific set of input material to hand to the solution delivery teams. This leaves the actual hands-on development and effectuation of the (services-based) SAP solution itself and yes: ArchitectedSAP elaborates on this as well. Want more? A 2012 outlook on the 7 major IT trends, adequate attention for non-functional requirements (finally), and the services granularity discussion put to bed… you can find it all in there.
ASAP Roadmaps will certainly be around for a few more years. But in case you want to adopt and take advantage of services-based SAP solutions successfully you will need to decide for yourself when to declare ASAP dead and proclaim the successor, ArchitectedSAP. When will you?