Architectural patterns for ESA applications
In the past, most partner projects involved the implementation of customer exits of various kinds and the development of additional reports. The focus will now change: more towards the development of applications, which are then integrated into solutions by other parties.
In other words, many partners will have the opportunity to work more like the SAP development departments.
It might be interesting for these partners to learn from the experiences of SAP architects when it comes to the architecture of whole components, applications or LDUs. Many development departments at SAP, including my own, have architects’ meetings where experiences regarding the architecture of components are exchanged, and common architecture guidelines are developed. These architecture guidelines can cover things from naming conventions to layer concepts, communication patterns, package structures and the general implementation of technical application aspects such as transaction control, locks, logging, error messages etc.
My question to you, the readers: would you be interested in reading about some of the experiences we (well, I, in this case) have regarding these subjects? If so, please leave comments below.
Thanks a lot in advance for your feedback!
I've been trying to persuade my organization about the changing role of SAP partner organizations with the introduction of NetWeaver and ESA, and that convential SAP consulting roles will not give organizations a competitive edge anymore. Your blog will certainly assist me in developing a stronger business case. Please do share your experiences with the rest of the community to assist us in making informed decisions regarding NetWeaver-related initiatives.
Regards
regards,
Sujatha
thanks for your response; I will go ahead and post some experiences here.
However, they are of a more general nature regarding issues we face when we build things that are a bit bigger than reports or user exit implementations. My experiences are not necessarily 100% ESA-related, although the architecture I have been responsible for for the last years is certainly very ESA-compatible indeed. So, I leave ESA specifics such as tips and tricks for ESR usage and the like to people who are better qualified than I am in that regard. I will look into how to architecture and design a component (LDU) in order to have a reasonably extensible, understandable, maintainable, robust, performant and scalable solution our customers are expecting from us.
I hope this is fine with you. See you soon on the Weblog!
We would really love to hear your thoughts, read your articles, blogs, forum questions, and insights as they pertain to ESA.
Community content and opinion is something this page
could benefit from.
I am at your service to see that those pages are populated with the content you wish and need to get.
I have been enjoying the intermittent conversations that have been occurring on the
Enterprise Services Architecture Forum
Folks like kamaljeet singh and Joseph Gaus have stepped up to the plate with their concise and excellent thoughts on the subject of ESA.
I know that others have been proposing “challenges” and contests around here lately.
I would love to see the community vocalize in the ESA forum and change the traffic patterns and interest levels there.
Can we get to 500 significant posts and comments by the end of July?
Let’s see.
Cheers,
Marilyn Pratt