I see so many differences during my work on what an SAP blueprint is and what is in it that I decided that I would talk about this and share my thoughts. I am not certain on the history of the term; the only thing I can trace it to, is that back in the 90’s when SAP’s ASAP methodology came about the term “blueprint” was first used. I think this was a little confusing to some of us that were in software development prior to SAP but I think it was partly a terminology. Certainly the term makes sense, but I think the industry as a whole would have been better served if it would have been called a functional spec. So why so much confusion? Part of the problem was that consultants that were coming into the field at that time had no background in software development . So the idea of a blueprint/functional specification, or even in some cases the software development lifecycle may or may not have been meaningful to everyone that was placed on an implementation project. Now, of course SAP put together some decent training classes around ASAP (I took them) but even then the focus on the classes was the use of the tools SAP provided to support the implementation. So here you have resources putting together a blueprint who do not completely understand it’s purpose. All they know is that in case of the Q&A DB, they need to ask the questions and document the answers. Ok, I realize that SAP did not intend it necessarily this way, but trust me this is what happens.
To make the discussion easier let me throw myself out on a limb here and define a SAP blueprint. I already alluded to the fact that a blueprint should be your functional specification.
My definition of a blueprint:
“A software blueprint consists of the documented requirements and anything else that formalizes what the end product should look like from a user (Customer) perspective.” This is the WHAT, not the how (this is an important distinction).
If you want more details on functional specs in general, I would suggest reading Joel on Software’s description of a functional spec here as I think he explains it the best and why rewrite it.
I’ll end today’s post with a suggestion: Blueprints/Functional Specifications are critical, Don’t do a project without one, but understand what it is first and what needs to be in it. Don’t just use the blueprint template that SAP provides (these days from Solution Manager). Use it as a starting point only. It should be developed based on your own needs. The term blueprint explains it all; you normally would not build a house without a blueprint but sometimes software is developed without a software blueprint. Don’t do it. I’ll talk a little bit more about the blueprint and what should be included in it and how to use it in subsequent posts.
Later